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

Sun May 15 10:17:23 CEST 2011

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 <mailto: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...

>
>     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.

OK, no problem. The build instructions as they are seem simple enough
(for a programmers eye, anyway ;)), and they wouldn't get that much
easier with a homebrew formula.

>>     Direct git access:
>>
>>         git://github.com/Sharpie/TeXworks.git
>>     <http://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.

Yeah, so I heard. Anyway, for the time, the script I wrote for producing
Debian packages is working well, and actually only has to prepare source
packages as the binaries are built online at Launchpad. But maybe others
like to have a stab at this.

BTW: I tested your CMake build environment, and it seems to work without
problems on Ubuntu (I'm not sure what the exact dependencies are, as I
already had them installed, but I'd assume those posted on GC + cmake,
git should pretty much do the trick). In case you want to update that
warning message.

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

Yeah, I've heard about that branching policy. Personally, I don't like
creating dozens of branches with one or two lines changed in each, but
then again I haven't been doing much with git thus far.

>     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?
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).

Cheers,
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/texworks/attachments/20110515/29b34f08/attachment.html>