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