[texworks] Another TeXworks mac build (with a buildsystem!)

[Charlie Sharpsteen]

On Thu, May 12, 2011 at 12:24 PM, Stefan Löffler <st.loeffler at gmail.com>wrote:

>  Hi,
>
> this is looking awesome, thanks! If you agree, I'd like to write something
> up (well, actually, copy from you ;)) for the Tw wiki.
>
> WARNING (for non-developers): The rest of this message is very technical.
>
>
> A few questions:
> 1) is it possible to use the upstream svn repo instead of cloning a git
> version of it? That would have the benefit that people don't have to
> rely/wait on you pulling changes, as long as nothing dramatic changes.
>

My Git repo was cloned from the offical TeXworks SVN repository, the
texworks-svn branch is currently tracking your trunk.  If I disappear and
someone wants to use my CMake patches on top of the newest version of the
SVN repo, the following workflow should do the trick:

# Clone the Git repository:
git clone git://github.com/Sharpie/TeXworks.git
cd TeXworks

# Add the TeXworks svn repository, remove the `trunk` part and
add --stdlayout if you want to bring in branches and tags from SVN.
git svn init http://texworks.googlecode.com/svn/trunk/

# Bring in SVN history (this will take a while)
git svn fetch

# Checkout the SVN trunk as a git branch
git checkout -b texworks-upstream remotes/git-svn

# Checkout the CMake branch
git checkout cmake-only

# Forward-port all changes in cmake-only onto the the SVN trunk:
git rebase texworks-upstream

# If new changes occur in SVN:
git checkout texworks-upstream
git svn rebase
git checkout cmake-only
git rebase texworks-upstream


 2) Can you add support for stable releases? They are in /tags in the svn
> repo (if the answer to 1) is yes, this is trivial)
>

Sure, I'll just have to import the tags directory into the Git repository.



>  3) I noticed you mention homebrew; can your cmake system be incorporated
> into homebrew?
>

Yes, Homebrew builds quite a few projects that use CMake. However, it does
have a policy that frowns on including Applications unless they have a lot
of dependencies or are otherwise difficult to obtain.



>
> On 2011-05-12 07:23, Charlie Sharpsteen wrote:
>
> If someone wants to play with the build system, the code is available at:
>
>      https://github.com/downloads/Sharpie/TeXworks
>
>
> This didn't work for me.
>

Gah. Bad copy and paste job, the correct url is:

    https://github.com/Sharpie/TeXworks




>
>  Direct git access:
>
>      git://github.com/Sharpie/TeXworks.git
>
>  If anyone has any improvements/corrections, feel free to fork the repo
> and send a pull request.
>
>
> Done. I wanted to send separate pull requests for different sets of
> changes, but didn't succeed (is it possible at all? I have practically no
> experience with git/github).
>

Looks great! I'll pull your changes over, when I get the chance. One thing
you may be interested in is that CPack can be set to build Debian packages
and RPMs on Linux.


To generate separate pull requests, you have to adopt the "branching
mindset" that git is famous (infamous?) for. Basically, it works like this:

# If there is another upstream repo you want to get updates from
get remote add upstream git://github.com/Sharpie/TeXworks.git

# Check out the master branch and sync it with "upstream"
 git checkout master
git pull upstream master

# If any conflicts happen:
git mergetool


# Create a new branch for a feature that will start out as a copy of the
master branch:
git branch feature-x master

# Switch to the feature-x branch
git checkout feature-x
# Hack Hack Hack

# Push some feature brances to GitHub
git push origin feature-x feature-y

Now to open a pull request, go to your project page on GitHub.com, select
the desired branch from the "Switch Branches" menu and then hit the "Pull
Request" button. The resulting request will only contain commits from the
branch you selected.

Or, to do it the ol' fashioned way:

# Create patchfiles containing all the commits that happened on the
feature-x branch relative to your master branch
git format-patch master...feature-x

# Or a given remote master branch
git fetch upstream  # Make sure git has an up-to-date picture of the
upstream repo
git format-patch upstream/master...feature-x


Quick 'n dirty Git Reference:

    http://gitref.org

More in-depth:

    http://progit.org
    http://gitready.com


 If the core developers are interested in bringing this new build system
> into the SVN repository, the following patch should apply cleanly against
> revision 813:
>
>      https://github.com/Sharpie/TeXworks/compare/texworks-svn...cmake-only
>
>  There is only one teenie-tiny change to src/TWApp.h to guard against
> D-Bus that affects the existing code code.
>
>
> Bringing the whole CMake system in will need some thinking and discussion,
> so please be patient.
>

No problem, I will try to keep the cmake-only branch limited to changes
that concern the build system--i.e. by excluding things like the README swap
I did for the GitHub project page.  That way a GitHub comparison between
texworks-svn and cmake-only should always generate a nice patch if you
decide to bring it into the main repo.



> Regarding the patch: it seems trivial, but the way I read the Qt docs,
> Q_WS_X11 and Q_WS_MAC should be mutually exclusive. See, e.g., main.cpp,
> which also uses dbus, but only guards against Q_WS_X11 - why doesn't that
> cause problems for you? The only thing I can think of is that your
> workaround "ADD_DEFINITIONS( -DQ_WS_MAC )" is not really resolving the issue
> (note that there is TwApp.h, but no main.h, to be processed by moc). I could
> imagine that QT4_WRAP_CPP actually mistakes the system and defines Q_WS_X11
> _instead of_ DQ_WS_MAC. Can this be overridden by "REMOVE_DEFINITIONS(
> -DQ_WS_X11 )"?
> All in all, I'd rather have a proper solution if possible rather than
> hacking the svn code...
>

The problem that is occurring for me is that when QT4_WRAP_CPP processes
TWApp.h to generate moc_TWApp.cxx, it runs the following command:

cd /Users/sharpie/code/TeX/texworks/build/src &&
/usr/local/Cellar/qt/4.7.3/bin/moc -I/usr/local/Cellar/qt/4.7.3/include
-F/usr/local/Cellar/qt/4.7.3/lib
-I/usr/local/Cellar/qt/4.7.3/lib/QtScript.framework/Headers
-I/usr/local/Cellar/qt/4.7.3/include/QtUiTools
-I/usr/local/Cellar/qt/4.7.3/lib/QtScriptTools.framework/Headers
-I/usr/local/Cellar/qt/4.7.3/lib/QtGui.framework/Headers
-I/usr/local/Cellar/qt/4.7.3/lib/QtXml.framework/Headers
-I/usr/local/Cellar/qt/4.7.3/lib/QtCore.framework/Headers
-I/Users/sharpie/code/TeX/texworks/src
-I/Users/sharpie/code/TeX/texworks/build/src -I/usr/local/include/hunspell
-I/usr/local/include/poppler
-I/usr/local/Cellar/poppler/0.16.5/include/poppler/qt4 -I/usr/X11R6/include
-I/usr/include -DQT_SCRIPT_LIB -DQT_UITOOLS_LIB -DQT_SCRIPTTOOLS_LIB
-DQT_GUI_LIB -DQT_XML_LIB -DQT_CORE_LIB -o
/Users/sharpie/code/TeX/texworks/build/src/moc_TWApp.cxx
/Users/sharpie/code/TeX/texworks/src/TWApp.h

Somehow, that command apparently processes TWApp with Q_WS_X11 defined which
causes the D-Bus dependencies to show up.  I don't think REMOVE_DEFINITIONS(
-DQ_WS_X11 ) would be a solution because CMake is not passing -DQ_WS_X11. It
seems likely that one of the Qt header files is setting the definition.  I'm
by no means an expert on Qt, but it seems likely that Q_WS_X11 could be
defined for Mac since X11 is present on my machine.

One thing that I may try is running QT4_AUTOMOC on the `*.cpp` files instead
of QT4_WRAP_CPP on the headers to see if it makes a difference.


 Hope this is useful to someone!
>
>
> I think it will be tremendously useful! Thanks very much again!
>
> -Stefan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/texworks/attachments/20110512/f1e8b4cd/attachment-0001.html>