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

[Charlie Sharpsteen]

On Sun, May 15, 2011 at 1:17 AM, Stefan Löffler <st.loeffler at gmail.com> wrote:
> Hi,
>
> On 2011-05-12 22:33, Charlie Sharpsteen wrote:
>
> On Thu, May 12, 2011 at 12:24 PM, Stefan Löffler <st.loeffler at gmail.com>
> wrote:
>>
>> 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:
>
> [snip]
>
> Thanks for the guide.
>
> 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.
>
> Great! Maybe you could even do that before all the packaging-related
> questions are resolved, so people can build their own 0.4 stable release?
> But then again, there is a new one (0.4.1) coming up soon (hopefully), so
> maybe there isn't too much sense into building oneselve an 0.4.0 now...

There is one dilemma that I did not forsee as this is the first time I
have published a repository that was cloned using git-svn.  The
problem is that when I started this project, I was only interested in
the TeXworks trunk, so I only cloned the trunk:

    git svn clone http://texworks.googlecode.com/svn/trunk/

If I now clone the rest of the SVN tree from:

    http://texworks.googlecode.com/svn

Git sees it as a completely separate repository since there is a
different "root path". So, what I have published on GitHub is not a
suitable mirror of the SVN repository for someone who is interested in
working with branches or tags.

There are two choices:

    1. Use `git rebase` to graft the release-0.4.0 tag onto my clone
of the trunk. This will create a Git branch that people can pull and
build from, but the result will still be unsatisfactory for anyone
looking for a true mirror of the SVN repo.

    2. Re-clone the SVN repo using `svn` as the root path instead of
`svn/trunk`---this will create a full mirror. Then I would move my
master branch over to this new clone. The problem with this choice is
that anyone who has already cloned my git repository would have to
deal with an "upstream rebase" (this means the history of a repository
you pulled from got re-written). This means that they have to stash
any changes that I haven't accepted in a pull request and then
re-synch with my master branch:

    # Save a copy of your current master branch
    git checkout master
    git branch old-master

    # Re-synch your master branch with the rebased remote branch
    git remote add sharpie://github.com/Sharpie/TeXworks.git  # If you
don't already have my repository as a remote
    git fetch sharpie
    git reset --hard sharpie/master

    # Pull over any commits you made that weren't in my branch
    git log --oneline old-master  # To browse the change log for commits
    git cherry-pick <commit>    # Repeat for each commit that needs to be copied
    git branch -D old-master     # Remove old master branch

   Which is a bit of an ugly operation, but one that will only have to
be done once.


<snip>

>> 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.
>
> I just noticed that during the initial configuration (`cmake ..` in a clean
> directory), CMake prints out which of those Q_WS_* are defined. What does
> that say for you?

CMake says that Q_WS_X11 is not found. But still, moc processes
TWApp.h in such a way that moc_TWApp.cxx contains the section
protected by Q_WS_X11. When the app is compiled, Q_WS_X11 is not
defined and so the compiler throws an error. Very strange behavior.

> In addition, does the file build/src/moc_TWApp.cxx contain any reference to
> dbus? For me on Linux (with dbus), it contains no #include's or anything,
> only some type names and function calls related to TWAdaptor.
> And finally, you can easily check the compile-time settings by simply adding
> some lines like
> #ifdef Q_WS_X11
>     #warning Q_WS_X11
> #endif
> #ifdef Q_WS_MAC
>     #warning Q_WS_MAC
> #endif
>
> in some prominent location (e.g., the TWApp.h) and recompile.
>
>
> On 2011-05-13 00:00, Charlie Sharpsteen wrote:
>
> Something that just occurred to me after looking at the -D switches CMake
> passes to moc is that substituting:
>     #ifdef Q_WS_X11
> For:
>     #ifdef QT_DBUS_LIB
> In TWApp.h may work if it doesn't break the qmake build.
>
> Excellent point. I did just that in r817. I didn't find any mentioning of
> QT_DBUS_LIB in the documentation, yet, but it appears to be set on Linux and
> to not be set on Windows. From Qt 4.4 upwards, anyway (for 4.3, it's not
> set, but then again I don't think many people use that anymore; besides,
> it's easy to #def when invoking qmake).

This works with CMake as well and seems to be the cleanest resolution
to the problem---I removed my change to TWApp.h.  The total patch
against TeXworks SVN trunk:

    https://github.com/Sharpie/TeXworks/compare/texworks-svn...cmake-only

No longer affects any existing TeXworks code.


> Cheers,
> Stefan
>

-Charlie