Am 13.05.2013 um 11:20 schrieb Benjamin Piwowarski <benjamin.piwowar...@lip6.fr>:
> On May 13, 2013, at 10:35 , Stephan Witt <st.w...@gmx.net> wrote: > >> Am 13.05.2013 um 09:08 schrieb Benjamin Piwowarski >> <benjamin.piwowar...@lip6.fr>: >> >>> On May 12, 2013, at 17:51 , Stephan Witt <st.w...@gmx.net> wrote: >>> >>>> Am 12.05.2013 um 17:04 schrieb Benjamin Piwowarski >>>> <benjamin.piwowar...@lip6.fr>: >>>> >>>>> Hi, >>>>> >>>>> I would be happy to participate (in July/August) to make the cmake >>>>> building process complete and more fool-proof on mac (a few months ago I >>>>> was able to build successfully a working bundle). >>>> >>>> What do you call a working bundle? It has to contain the frameworks it >>>> depends on. >>>> Anyway, I have no preference for one build system or the other. And of >>>> course your >>>> support would be greatly appreciated. >>> >>> A working bundle would be the full LyX application (i.e. the LyX.app folder >>> currently constructed correctly only by auto-tools). >> >> This would be a regression for the user. She has to download and install Qt >> frameworks >> herself and the remaining spell checker would be the "Native" one. >> Currently the Qt and >> spell checker frameworks are added to the bundle as private frameworks. The >> resulting >> bundle I'd call the "full LyX application". > They are (or at least were) included in the bundle with cmake builds, so I > guess this is OK. I see it now. There are missing pieces: * Qt frameworks: Qt depends dynamically on QtSvg, QtXml, QtNetwork * Qt plugins: libqgif.dylib, libqsvg.dylib, libqico.dylib, libqjpeg.dylib, libqtga.dylib, libqmng.dylib, libqtiff.dylib * Qt translations * Spotlight library > What was remaining was to include all the other resources (I did not check > that all files included by the shell script were included in the LyX.app > bundle constructed via cmake) The target "make install" produces a (nearly) valid LyX.app. (Without the missing pieces mentioned above.) BTW, I see tons of messages like this for "make install": src/CMakeFiles/LyX.dir/build.make:120: warning: overriding commands for target `bin/LyX.app/Contents/Resources/bind/menus.bind' src/CMakeFiles/LyX.dir/build.make:104: warning: ignoring old commands for target `bin/LyX.app/Contents/Resources/bind/menus.bind' The result of "make package" is not usable, IMHO. E.g. the copied LyX.app has no Frameworks folder. >> As I said already, this is done by a shell script and not by the auto-tools >> make install. > OK - I did not get this point. With CMake this shell script would not be > necessary. > >> >> When make install from CMake produces an useful result like the auto-tools >> make install >> we have a good starting point. Then one can change the mentioned shell >> script or add its >> functionality to the CMake package build. >> >>> I don't have a strong preference towards any build system, but the only >>> point is that having to take care of updating both each time is cumbersome >>> and error-prone. So that's why I am ready to work on it - but only if cmake >>> is chosen as the only build system (otherwise, it does not make sense to >>> put so much effort in maintaining both working build systems). >> >> Yes, and I have to admit I never had a problem with multiple build systems. >> Surely because auto-tools and CMake both are working fine for me most of the >> time. > OK, then maybe this is not worth investing time in it. Let's wait what others say. Stephan
