Re: CMake for Apple?

2014-03-22 Thread Benjamin Piwowarski
This is an old thread, but I think it was the last message on cmake.

In the 2.2-staging, with the provided patch (and provided I did not break 
anything for windows, but I tried to triple check everything), OS X compilation 
is (unless I am missing things) nearly feature complete. On OS X, it generates 
a full LyX and working bundle, with all the necessary dependencies - I checked 
with diffs on the autotools version.

So from what I understand, there is not much missing in order to have cmake 
working on all platforms; would it be wise to pursue a bit the effort in order 
to leave autotools behind and focus only on cmake? This would avoid, e.g. for 
the transition to QT5, to have to check that everything works with the two 
build systems. If going in this direction, maybe creating a meta bug on trac 
would make it easier to track down what is missing.
 
benjamin

On 22 Mar 2014 at 11:14:41 , Jean-Marc Lasgouttes (lasgout...@lyx.org) wrote:
Le 13/05/13 19:21, Abdelrazak Younes a écrit :  
> I think it is worth investing time in it. At the meeting everybody  
> agreed that we should have one build system in the long run. But to make  
> cmake official we need to achieve the following:  

Translation: at the meeting we had a rather heated discussion where Abdel tried 
to make us think that all binary maintainer were eagerly waiting for the day 
where autotools will be dead and that if would be cruel from us to delay this 
moment. Or something.  

So we agreed that indeed one build system is better than two, and since windows 
people are kind of not adaptable (as in "I'll give you my visual studio project 
file when you pry it from my cold, dead hands"), only autotools could go.  

However, the point is that cmake is not ready for that now, so that the 
discussion is purely rhetoric (and believe me we had a lot of that in Milano 
:).  

Did I correctly translated Abdel? :p  

JMarc  


Re: CMake for Apple?

2013-05-13 Thread Jean-Marc Lasgouttes

Le 13/05/13 19:21, Abdelrazak Younes a écrit :

I think it is worth investing time in it. At the meeting everybody
agreed that we should have one build system in the long run. But to make
cmake official we need to achieve the following:


Translation: at the meeting we had a rather heated discussion where 
Abdel tried to make us think that all binary maintainer were eagerly 
waiting for the day where autotools will be dead and that if would be 
cruel from us to delay this moment. Or something.


So we agreed that indeed one build system is better than two, and since 
windows people are kind of not adaptable (as in "I'll give you my visual 
studio project file when you pry it from my cold, dead hands"), only 
autotools could go.


However, the point is that cmake is not ready for that now, so that the 
discussion is purely rhetoric (and believe me we had a lot of that in 
Milano :).


Did I correctly translated Abdel? :p

JMarc


Re: CMake for Apple?

2013-05-13 Thread Vincent van Ravesteijn
Op 13 mei 2013 20:58 schreef "Georg Baum" 
het volgende:
>
> Abdelrazak Younes wrote:
>
> > I think it is worth investing time in it. At the meeting everybody
> > agreed that we should have one build system in the long run. But to make
> > cmake official we need to achieve the following:
> > 1) implement the missing feature of autotools in cmake, especially for
> > MAC as I believe that Linux/Unix is complete thanks to the hard work of
> > Peter first and then Kornel.
> > 2) Deprecate autotools
> > 3) update the documentation (Readme/Wiki/etc)
> > 4) allow some time for developers to fully switch to cmake
> > 5) remove autotools when we are done, hopefully before 2.1, if not for
> > 2.2.
> >
> > The one point that still needs discussion is GLOB versus explicit file
> > listing. While GLOB is IMO a very nice feature I know and understand
> > others dislike it. So I guess we also need to do this in cmake.
>
> The usage of GLOB in cmake is the only reason why I still use autotools.
It
> interferes with my style of working (where it can happen that some play
.cpp
> files lie around), and it is also dangerous for making official builds:
> These should only compile stuff which is explicitly listed, otherwise you
> could easily end up with unreproducable compilations. Therefore I'd add
one
> item to the top of the list:

Just a wild idea: Only add cpp-files that are version tracked by git.

Vincent


Re: CMake for Apple?

2013-05-13 Thread Georg Baum
Abdelrazak Younes wrote:

> I think it is worth investing time in it. At the meeting everybody
> agreed that we should have one build system in the long run. But to make
> cmake official we need to achieve the following:
> 1) implement the missing feature of autotools in cmake, especially for
> MAC as I believe that Linux/Unix is complete thanks to the hard work of
> Peter first and then Kornel.
> 2) Deprecate autotools
> 3) update the documentation (Readme/Wiki/etc)
> 4) allow some time for developers to fully switch to cmake
> 5) remove autotools when we are done, hopefully before 2.1, if not for
> 2.2.
> 
> The one point that still needs discussion is GLOB versus explicit file
> listing. While GLOB is IMO a very nice feature I know and understand
> others dislike it. So I guess we also need to do this in cmake.

The usage of GLOB in cmake is the only reason why I still use autotools. It 
interferes with my style of working (where it can happen that some play .cpp 
files lie around), and it is also dangerous for making official builds: 
These should only compile stuff which is explicitly listed, otherwise you 
could easily end up with unreproducable compilations. Therefore I'd add one 
item to the top of the list:

0) Implement explicit file lists and introduce a switch which you can use to 
choose between GLOB and explicit file lists. The default should be not to 
use GLOB.

I agree that GLOB is a nice feature and has its use cases, but it is not a 
one fits all solution.
 
> Final point: This is just a proposal based on the feedback I received
> during the meeting. Other developers might disagree of course and in
> this case we should discuss more :-)

No, I think this is a pretty good summary (I can't tell about the meeting, 
but about the many messages that have already been written about this 
topic).


Georg



Re: CMake for Apple?

2013-05-13 Thread Pavel Sanda
Abdelrazak Younes wrote:
> I think it is worth investing time in it. At the meeting everybody agreed 
> that we should have one build system in the long run. But to make cmake 
> official we need to achieve the following:
> 1) implement the missing feature of autotools in cmake, especially for MAC 
> as I believe that Linux/Unix is complete thanks to the hard work of Peter 
> first and then Kornel.

How about making correct tarballs, does it currently work in the same way as 
with autotools?
(I mean producing approximately the same set of files.)


Pavel


Re: CMake for Apple?

2013-05-13 Thread Abdelrazak Younes

On 13/05/2013 14:54, Stephan Witt wrote:

Am 13.05.2013 um 11:20 schrieb Benjamin Piwowarski 
:

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.


I think it is worth investing time in it. At the meeting everybody 
agreed that we should have one build system in the long run. But to make 
cmake official we need to achieve the following:
1) implement the missing feature of autotools in cmake, especially for 
MAC as I believe that Linux/Unix is complete thanks to the hard work of 
Peter first and then Kornel.

2) Deprecate autotools
3) update the documentation (Readme/Wiki/etc)
4) allow some time for developers to fully switch to cmake
5) remove autotools when we are done, hopefully before 2.1, if not for 2.2.

The one point that still needs discussion is GLOB versus explicit file 
listing. While GLOB is IMO a very nice feature I know and understand 
others dislike it. So I guess we also need to do this in cmake.


So Benjamin, if you are willing to help it will be very good for the 
project.


Final point: This is just a proposal based on the feedback I received 
during the meeting. Other developers might disagree of course and in 
this case we should discuss more :-)


Cheers,
Abdel.




Re: CMake for Apple?

2013-05-13 Thread Stephan Witt
Am 13.05.2013 um 11:20 schrieb Benjamin Piwowarski 
:

> On May 13, 2013, at 10:35 , Stephan Witt  wrote:
> 
>> Am 13.05.2013 um 09:08 schrieb Benjamin Piwowarski 
>> :
>> 
>>> On May 12, 2013, at 17:51 , Stephan Witt  wrote:
>>> 
 Am 12.05.2013 um 17:04 schrieb Benjamin Piwowarski 
 :
 
> 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

Re: CMake for Apple?

2013-05-13 Thread Benjamin Piwowarski

On May 13, 2013, at 10:35 , Stephan Witt  wrote:

> Am 13.05.2013 um 09:08 schrieb Benjamin Piwowarski 
> :
> 
>> On May 12, 2013, at 17:51 , Stephan Witt  wrote:
>> 
>>> Am 12.05.2013 um 17:04 schrieb Benjamin Piwowarski 
>>> :
>>> 
 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.



Re: CMake for Apple?

2013-05-13 Thread Stephan Witt
Am 13.05.2013 um 09:08 schrieb Benjamin Piwowarski 
:

> On May 12, 2013, at 17:51 , Stephan Witt  wrote:
> 
>> Am 12.05.2013 um 17:04 schrieb Benjamin Piwowarski 
>> :
>> 
>>> 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".

As I said already, this is done by a shell script and not by the auto-tools 
make install.

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.

Stephan

Re: CMake for Apple?

2013-05-13 Thread Benjamin Piwowarski

On May 12, 2013, at 17:51 , Stephan Witt  wrote:

> Am 12.05.2013 um 17:04 schrieb Benjamin Piwowarski 
> :
> 
>> 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). 

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

Benjamin

Re: CMake for Apple?

2013-05-12 Thread Stephan Witt
Am 12.05.2013 um 17:04 schrieb Benjamin Piwowarski 
:

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

Stephan

> If some are interested to do the same effort for the linux platform, then it 
> could be an occasion to get rid of the old auto-tools chain since windows is 
> already not using it. Maintaining two build systems is cumbersome and may 
> introduce lots of compilation errors when switching from one tool to the 
> other (this happened when I submitted patches to LyX).
> 
> benjamin
> 
> On May 12, 2013, at 13:41 , Stephan Witt  wrote:
> 
>> Am 12.05.2013 um 11:18 schrieb Abdelrazak Younes :
>> 
>>> On Sat, May 11, 2013 at 11:02 PM, Stephan Witt  wrote:
 Am 11.05.2013 um 17:50 schrieb Abdelrazak Younes :
 
> Hi Stephan,
> 
> At LyX meeting we are wondering why you are still using autotools for Mac 
> packaging. Do you miss anything from CMake that is not implemented yet?
 
 Hi all at the LyX meeting,
 
 I hope you're well and someone is drinking wine too… :)
 
>>> I had some ;-)
>>> 
>>> 
 Regarding the CMake question - I never tried it for a long time.
 
>>> Ah? I got the impression you were developping using cmake and xcode... But 
>>> I see in your other email that this does not work anymore...
>>> 
 
 So I cannot answer the question. Isn't the autotools build the official 
 one?
 
>>> Up to now yes, except for Windows.
>>> 
>>> I was trying to advocate yesterday that we should really move to cmake on 
>>> all platforms. I guess this is already a lost battle…
>> 
>> I'm using CMake to generate the Xcode-project for debugging purposes.
>> 
>> The packaging is done by a shell script to wrap all needed resources into 
>> one bundle.
>> The first step is making the pure LyX.app bundle (make install).
>> Then the additional parts are copied into this app bundle. The used 
>> frameworks
>> (spell checker libraries, gettext and Qt4) needs to be adjusted to make them 
>> relocatable.
>> The dictionaries and thesauri are simply copied into it too.
>> 
>> Of course one can do these steps with CMake but I never got a friend of it's 
>> language
>> and I'm loosing to much time to find my mistakes when using it. If it had 
>> the ability to
>> tell me what it's doing and why… sorry, the verbose option of it is not 
>> enough for me.
>> 
>> Stephan
> 
> 
> 



Re: CMake for Apple?

2013-05-12 Thread Benjamin Piwowarski
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). If some are interested to do the same 
effort for the linux platform, then it could be an occasion to get rid of the 
old auto-tools chain since windows is already not using it. Maintaining two 
build systems is cumbersome and may introduce lots of compilation errors when 
switching from one tool to the other (this happened when I submitted patches to 
LyX).

benjamin

On May 12, 2013, at 13:41 , Stephan Witt  wrote:

> Am 12.05.2013 um 11:18 schrieb Abdelrazak Younes :
> 
>> On Sat, May 11, 2013 at 11:02 PM, Stephan Witt  wrote:
>>> Am 11.05.2013 um 17:50 schrieb Abdelrazak Younes :
>>> 
 Hi Stephan,
 
 At LyX meeting we are wondering why you are still using autotools for Mac 
 packaging. Do you miss anything from CMake that is not implemented yet?
>>> 
>>> Hi all at the LyX meeting,
>>> 
>>> I hope you're well and someone is drinking wine too… :)
>>> 
>> I had some ;-)
>> 
>> 
>>> Regarding the CMake question - I never tried it for a long time.
>>> 
>> Ah? I got the impression you were developping using cmake and xcode... But I 
>> see in your other email that this does not work anymore...
>> 
>>> 
>>> So I cannot answer the question. Isn't the autotools build the official one?
>>> 
>> Up to now yes, except for Windows.
>> 
>> I was trying to advocate yesterday that we should really move to cmake on 
>> all platforms. I guess this is already a lost battle…
> 
> I'm using CMake to generate the Xcode-project for debugging purposes.
> 
> The packaging is done by a shell script to wrap all needed resources into one 
> bundle.
> The first step is making the pure LyX.app bundle (make install).
> Then the additional parts are copied into this app bundle. The used frameworks
> (spell checker libraries, gettext and Qt4) needs to be adjusted to make them 
> relocatable.
> The dictionaries and thesauri are simply copied into it too.
> 
> Of course one can do these steps with CMake but I never got a friend of it's 
> language
> and I'm loosing to much time to find my mistakes when using it. If it had the 
> ability to
> tell me what it's doing and why… sorry, the verbose option of it is not 
> enough for me.
> 
> Stephan





Re: CMake for Apple?

2013-05-12 Thread Stephan Witt
Am 12.05.2013 um 11:18 schrieb Abdelrazak Younes :

> On Sat, May 11, 2013 at 11:02 PM, Stephan Witt  wrote:
>> Am 11.05.2013 um 17:50 schrieb Abdelrazak Younes :
>> 
>> > Hi Stephan,
>> >
>> > At LyX meeting we are wondering why you are still using autotools for Mac 
>> > packaging. Do you miss anything from CMake that is not implemented yet?
>> 
>> Hi all at the LyX meeting,
>> 
>> I hope you're well and someone is drinking wine too… :)
>> 
> I had some ;-)
>  
> 
>> Regarding the CMake question - I never tried it for a long time.
>> 
> Ah? I got the impression you were developping using cmake and xcode... But I 
> see in your other email that this does not work anymore...
> 
>>  
>> So I cannot answer the question. Isn't the autotools build the official one?
>> 
> Up to now yes, except for Windows.
> 
> I was trying to advocate yesterday that we should really move to cmake on all 
> platforms. I guess this is already a lost battle…

I'm using CMake to generate the Xcode-project for debugging purposes.

The packaging is done by a shell script to wrap all needed resources into one 
bundle.
The first step is making the pure LyX.app bundle (make install).
Then the additional parts are copied into this app bundle. The used frameworks
(spell checker libraries, gettext and Qt4) needs to be adjusted to make them 
relocatable.
The dictionaries and thesauri are simply copied into it too.

Of course one can do these steps with CMake but I never got a friend of it's 
language
and I'm loosing to much time to find my mistakes when using it. If it had the 
ability to
tell me what it's doing and why… sorry, the verbose option of it is not enough 
for me.

Stephan

Re: CMake for Apple?

2013-05-12 Thread Vincent van Ravesteijn



So I cannot answer the question. Isn't the autotools build the
official one?


Up to now yes, except for Windows.

I was trying to advocate yesterday that we should really move to cmake 
on all platforms. I guess this is already a lost battle...


Hmm.. your chances are not that bad really.

Vincent


Re: CMake for Apple?

2013-05-12 Thread Abdelrazak Younes
On Sat, May 11, 2013 at 11:02 PM, Stephan Witt  wrote:

> Am 11.05.2013 um 17:50 schrieb Abdelrazak Younes :
>
> > Hi Stephan,
> >
> > At LyX meeting we are wondering why you are still using autotools for
> Mac packaging. Do you miss anything from CMake that is not implemented yet?
>
> Hi all at the LyX meeting,
>
> I hope you're well and someone is drinking wine too… :)
>

I had some ;-)


>
> Regarding the CMake question - I never tried it for a long time.
>

Ah? I got the impression you were developping using cmake and xcode... But
I see in your other email that this does not work anymore...



> So I cannot answer the question. Isn't the autotools build the official
> one?
>

Up to now yes, except for Windows.

I was trying to advocate yesterday that we should really move to cmake on
all platforms. I guess this is already a lost battle...

Cheers,
Abdel


Re: CMake for Apple?

2013-05-11 Thread Stephan Witt
Am 11.05.2013 um 17:50 schrieb Abdelrazak Younes :

> Hi Stephan,
> 
> At LyX meeting we are wondering why you are still using autotools for Mac 
> packaging. Do you miss anything from CMake that is not implemented yet?

Hi all at the LyX meeting,

I hope you're well and someone is drinking wine too… :)

Regarding the CMake question - I never tried it for a long time.
So I cannot answer the question. Isn't the autotools build the official one?

The final package consists of
* the LyX.app with
  - the Qt framework and
  - the spell checker libraries
* the special finder view with
  - the background image

Stephan