Re: One official build system?

[Kornel Benko]

Am Donnerstag, 16. Juni 2016 um 21:37:03, schrieb Georg Baum 

> Georg Baum wrote:
> 
> > Kornel Benko wrote:
> > 
> >> So it is a built and removed source. Should it be ditributed?
> > 
> > I don't think so. But I do not understand how to implement that. It seems
> > that automake evalutes all if-branches when adding file to the *_DIST
> > targets.
> 
> Actually I found it out and fixed it.
> 

So, as an outcome of this thread, using GLOB in cmake _may_ sometimes help 
automake :)
In a clean tree, the GLOB is not problematic IMHO.
That means, to create a tar file from cmake build, we have to clean first. I 
too see, that
it is not very comfortable.
Or omit globbing-expressions of course. This has its own inconveniences.

> Georg

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Georg Baum]

Georg Baum wrote:

> Kornel Benko wrote:
> 
>> So it is a built and removed source. Should it be ditributed?
> 
> I don't think so. But I do not understand how to implement that. It seems
> that automake evalutes all if-branches when adding file to the *_DIST
> targets.

Actually I found it out and fixed it.


Georg

Re: One official build system?

[Georg Baum]

Kornel Benko wrote:

> I see, but this one is from automake, not from cmake (where one would
> expect it). I don't have it local. The question mark is there, because I
> didn't knew, where it came from). Searching now...

A sorry, I was confused. This file is for the monolithic build, and we have 
more of these, e.g. src/lyxcore.cpp.

> # find . -name Makefile.am | xargs egrep lyxclient.cpp
> -->
> ./src/client/Makefile.am:lyxclient.cpp:
> ./src/client/Makefile.am:BUILT_SOURCES = lyxclient.cpp
> ./src/client/Makefile.am:CLEANFILES += lyxclient.cpp
> ./src/client/Makefile.am:lyxclient_SOURCES = lyxclient.cpp $(HEADERFILES)
> 
> So it is a built and removed source. Should it be ditributed?

I don't think so. But I do not understand how to implement that. It seems 
that automake evalutes all if-branches when adding file to the *_DIST 
targets.


Georg

Re: One official build system?

[Kornel Benko]

Am Mittwoch, 15. Juni 2016 um 22:29:17, schrieb Georg Baum 

> Kornel Benko wrote:
> 
> > Am Dienstag, 14. Juni 2016 um 22:37:58, schrieb Georg Baum
> > 
> >> The icons and the regex files are indeed a serious problem. The icons
> >> should be fixed now, this was simply a wrong style of using variables.
> > 
> > It does not look like that. Even after ./autogen.sh and configure.
> 
> For me the oxygen stuff was missing completely, but now I saw that you added 
> some missing icons. Thanks.
> 
> >> I'll take
> >> care for the regex files later, but what I do not understand is how the
> >> official windows build could succeed without these files (because of
> >> http://www.lyx.org/trac/ticket/9373). I fear that (again) the official
> >> installers were produced from git and not from an unpacked .tar.gz. Or
> >> bug 9373 is magically fixed and nobody noticed.
> >> 
> > 
> > I do not understand either.
> 
> I fixed the boost packaging. Maybe the windows build did work depsite the 
> missing files, at least one was definitely not used.

OK

> > Some files are distributed in automake, which we do not want I suppose
> > development/lyxserver/perl/LyX-Client-0.01.tar.gz
> > development/lyxserver/perl/LyX-Polite-0.01.tar.gz
> > src/client/lyxclient.cpp (what is this?)
> 
> The last one must be a local file (not in git). You see why I want explicit 
> lists? ;-)
> 

I see, but this one is from automake, not from cmake (where one would expect 
it). I don't have it local.
The question mark is there, because I didn't knew, where it came from).
Searching now...
# find . -name Makefile.am | xargs egrep lyxclient.cpp
-->
./src/client/Makefile.am:lyxclient.cpp:
./src/client/Makefile.am:BUILT_SOURCES = lyxclient.cpp
./src/client/Makefile.am:CLEANFILES += lyxclient.cpp
./src/client/Makefile.am:lyxclient_SOURCES = lyxclient.cpp 
$(HEADERFILES)

So it is a built and removed source. Should it be ditributed?

> Georg

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Georg Baum]

Kornel Benko wrote:

> Am Dienstag, 14. Juni 2016 um 22:37:58, schrieb Georg Baum
> 
>> The icons and the regex files are indeed a serious problem. The icons
>> should be fixed now, this was simply a wrong style of using variables.
> 
> It does not look like that. Even after ./autogen.sh and configure.

For me the oxygen stuff was missing completely, but now I saw that you added 
some missing icons. Thanks.

>> I'll take
>> care for the regex files later, but what I do not understand is how the
>> official windows build could succeed without these files (because of
>> http://www.lyx.org/trac/ticket/9373). I fear that (again) the official
>> installers were produced from git and not from an unpacked .tar.gz. Or
>> bug 9373 is magically fixed and nobody noticed.
>> 
> 
> I do not understand either.

I fixed the boost packaging. Maybe the windows build did work depsite the 
missing files, at least one was definitely not used.

> Some files are distributed in automake, which we do not want I suppose
> development/lyxserver/perl/LyX-Client-0.01.tar.gz
> development/lyxserver/perl/LyX-Polite-0.01.tar.gz
> src/client/lyxclient.cpp (what is this?)

The last one must be a local file (not in git). You see why I want explicit 
lists? ;-)


Georg

Re: One official build system?

[Kornel Benko]

Am Dienstag, 14. Juni 2016 um 22:37:58, schrieb Georg Baum 

> Kornel Benko wrote:
> 
> > The result is that cmake part misses
> > Makefile.in
> > automake misses
> > lib/fonts/*.sfd (11 files)
> > lib/images/ipa/*.svgz (30 files)
> > lib/images/oxygen/*.svgz (88 files)
> > src/mathed/InsetMathXYArrow.{cpp,h}
> > 3rdparty/boost/libs/regex/src/{icu,usinstances,wc_regex_traits}.cpp
> > 
> > There are also many files in cmake-tar which are only for tests and not
> > important. But the automake missed files are more than serious IMHO.
> 
> Not all missing files are a problem. InsetMathXYArrow is dead code and the 
> .sfd files are left out on purpose as well (only usable by font experts).
> 
> The icons and the regex files are indeed a serious problem. The icons should 
> be fixed now, this was simply a wrong style of using variables.

It does not look like that. Even after ./autogen.sh and configure.

> I'll take 
> care for the regex files later, but what I do not understand is how the 
> official windows build could succeed without these files (because of 
> http://www.lyx.org/trac/ticket/9373). I fear that (again) the official 
> installers were produced from git and not from an unpacked .tar.gz. Or bug 
> 9373 is magically fixed and nobody noticed.
> 

I do not understand either.

Extra missing in automake (apart from already mentioned)
development/cmake/modules/LyXDestinations.cmake
development/cmake/scripts/xmingw

development/Win32/packaging/installer/{Console.dll,FindProcDLL.dll,InetLoad.dll,include/EnvVarUpdate.nsh,
 \

information,Encodings.txt,TranslatedLanguages.nsh,Packages.txt,Readme.txt}
src/frontends/qt4/GuiGraphicsUi.h (dead code?)
src/frontends/qt4/liblyxqt4.cpp
src/{lyxcore,lyxinsets,lyxmathed}.cpp

Some files are distributed in automake, which we do not want I suppose
development/lyxserver/perl/LyX-Client-0.01.tar.gz
development/lyxserver/perl/LyX-Polite-0.01.tar.gz
src/client/lyxclient.cpp (what is this?)

> Georg

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Scott Kostyshak]

On Tue, Jun 14, 2016 at 10:03:15PM +0200, Kornel Benko wrote:
> Am Dienstag, 14. Juni 2016 um 14:56:21, schrieb Scott Kostyshak 
> 
> > On Tue, Jun 14, 2016 at 10:02:23AM +0200, Kornel Benko wrote:
> > > Am Montag, 13. Juni 2016 um 19:09:04, schrieb Scott Kostyshak 
> > > 
> > > > Note also that for me make package_source produces a tar.gz, not a
> > > > tar.xz as you suggested above.
> > > 
> > > It depends on how you configure, so that 'make package' knows what to 
> > > produce.
> > > 1.)  -DCPACK_SOURCE_TGZ:BOOL=ON
> > >   -> .tar.gz
> > > 2.)  -DCPACK_SOURCE_TBZ2:BOOL=ON
> > >   -> .bz2
> > > 3.) -DCPACK_SOURCE_TZ:BOOL=ON
> > >   -> .tar.Z
> > > or
> > > 4.)  -DCPACK_SOURCE_ZIP:BOOL=ON
> > >   -> nothing on linux
> > > 
> > > (Select only one of them)
> > > But, yes, .tar.xz is not created :(
> > 
> > OK
> > 
> > > For the differences:
> > >   'make git-archive' and 'make package_source' create different files.
> > > Which one have you used for comparison?
> > 
> > I used make package_source.
> > 
> > > Here, 'make package_source' creates
> > >   LyX-2.3.tar.gz
> > >   LyX-2.3.tar.xz
> > >   LyX-2.3.tar.Z
> > 
> > Ah so xz is created? I must have missed that.
> > 
> > If you have time and want to take a look, compare the tar.gz you get
> > from CMake to the 2.2.0 tar from the following command:
> > yourself: ./autogen.sh && ./configure && make lyxdist
> 
> I made it. But I do not see many differences.
> To test:
>   # cd  /usr/BUILD/BuildLyxGitQt5.6mainAutomake
>   # make lyxdist
>   # cd /usr/BUILD/BuildLyxGitQt5.6main-gcc5.3
>   # make package_source
>   # cd ~/tmp
>   # mkdir -p compare/automake
>   # cd compare/automake
>   # tar axvf /usr/BUILD/BuildLyxGitQt5.6mainAutomake/lyx-2.3.0dev.tar.gz
>   # cd ~/tmp
>   # mkdir -p compare/cmake
>   # cd compare/cmake
>   # tar axvf /usr/BUILD/BuildLyxGitQt5.6main-gcc5.3/LyX-2.3.tar.gz
>   # cd LyX-2.3
>   # diff -r .  ~/tmp/compare/automake/lyx-2.3.0dev/.
> 
> The result is that cmake part misses
>   Makefile.in
> automake misses
>   lib/fonts/*.sfd (11 files)
>   lib/images/ipa/*.svgz (30 files)
>   lib/images/oxygen/*.svgz (88 files)
>   src/mathed/InsetMathXYArrow.{cpp,h}
>   3rdparty/boost/libs/regex/src/{icu,usinstances,wc_regex_traits}.cpp
> 
> There are also many files in cmake-tar which are only for tests and not 
> important.
> But the automake missed files are more than serious IMHO.

Thanks for doing that. I guess I just saw a large diff and did not look
closely enough to categorize the items. Looks like there is not any
major problem then.

Good news.

Scott


signature.asc
Description: PGP signature

Re: One official build system?

[Georg Baum]

Kornel Benko wrote:

> The result is that cmake part misses
> Makefile.in
> automake misses
> lib/fonts/*.sfd (11 files)
> lib/images/ipa/*.svgz (30 files)
> lib/images/oxygen/*.svgz (88 files)
> src/mathed/InsetMathXYArrow.{cpp,h}
> 3rdparty/boost/libs/regex/src/{icu,usinstances,wc_regex_traits}.cpp
> 
> There are also many files in cmake-tar which are only for tests and not
> important. But the automake missed files are more than serious IMHO.

Not all missing files are a problem. InsetMathXYArrow is dead code and the 
.sfd files are left out on purpose as well (only usable by font experts).

The icons and the regex files are indeed a serious problem. The icons should 
be fixed now, this was simply a wrong style of using variables. I'll take 
care for the regex files later, but what I do not understand is how the 
official windows build could succeed without these files (because of 
http://www.lyx.org/trac/ticket/9373). I fear that (again) the official 
installers were produced from git and not from an unpacked .tar.gz. Or bug 
9373 is magically fixed and nobody noticed.


Georg

Re: One official build system?

[Kornel Benko]

Am Dienstag, 14. Juni 2016 um 14:56:21, schrieb Scott Kostyshak 

> On Tue, Jun 14, 2016 at 10:02:23AM +0200, Kornel Benko wrote:
> > Am Montag, 13. Juni 2016 um 19:09:04, schrieb Scott Kostyshak 
> > 
> > > Note also that for me make package_source produces a tar.gz, not a
> > > tar.xz as you suggested above.
> > 
> > It depends on how you configure, so that 'make package' knows what to 
> > produce.
> > 1.)  -DCPACK_SOURCE_TGZ:BOOL=ON
> > -> .tar.gz
> > 2.)  -DCPACK_SOURCE_TBZ2:BOOL=ON
> > -> .bz2
> > 3.) -DCPACK_SOURCE_TZ:BOOL=ON
> > -> .tar.Z
> > or
> > 4.)  -DCPACK_SOURCE_ZIP:BOOL=ON
> > -> nothing on linux
> > 
> > (Select only one of them)
> > But, yes, .tar.xz is not created :(
> 
> OK
> 
> > For the differences:
> > 'make git-archive' and 'make package_source' create different files.
> > Which one have you used for comparison?
> 
> I used make package_source.
> 
> > Here, 'make package_source' creates
> > LyX-2.3.tar.gz
> > LyX-2.3.tar.xz
> > LyX-2.3.tar.Z
> 
> Ah so xz is created? I must have missed that.
> 
> If you have time and want to take a look, compare the tar.gz you get
> from CMake to the 2.2.0 tar from the following command:
> yourself: ./autogen.sh && ./configure && make lyxdist

I made it. But I do not see many differences.
To test:
# cd  /usr/BUILD/BuildLyxGitQt5.6mainAutomake
# make lyxdist
# cd /usr/BUILD/BuildLyxGitQt5.6main-gcc5.3
# make package_source
# cd ~/tmp
# mkdir -p compare/automake
# cd compare/automake
# tar axvf /usr/BUILD/BuildLyxGitQt5.6mainAutomake/lyx-2.3.0dev.tar.gz
# cd ~/tmp
# mkdir -p compare/cmake
# cd compare/cmake
# tar axvf /usr/BUILD/BuildLyxGitQt5.6main-gcc5.3/LyX-2.3.tar.gz
# cd LyX-2.3
# diff -r .  ~/tmp/compare/automake/lyx-2.3.0dev/.

The result is that cmake part misses
Makefile.in
automake misses
lib/fonts/*.sfd (11 files)
lib/images/ipa/*.svgz (30 files)
lib/images/oxygen/*.svgz (88 files)
src/mathed/InsetMathXYArrow.{cpp,h}
3rdparty/boost/libs/regex/src/{icu,usinstances,wc_regex_traits}.cpp

There are also many files in cmake-tar which are only for tests and not 
important.
But the automake missed files are more than serious IMHO.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Scott Kostyshak]

On Tue, Jun 14, 2016 at 10:02:23AM +0200, Kornel Benko wrote:
> Am Montag, 13. Juni 2016 um 19:09:04, schrieb Scott Kostyshak 
> 
> > Note also that for me make package_source produces a tar.gz, not a
> > tar.xz as you suggested above.
> 
> It depends on how you configure, so that 'make package' knows what to produce.
> 1.)  -DCPACK_SOURCE_TGZ:BOOL=ON
>   -> .tar.gz
> 2.)  -DCPACK_SOURCE_TBZ2:BOOL=ON
>   -> .bz2
> 3.) -DCPACK_SOURCE_TZ:BOOL=ON
>   -> .tar.Z
> or
> 4.)  -DCPACK_SOURCE_ZIP:BOOL=ON
>   -> nothing on linux
> 
> (Select only one of them)
> But, yes, .tar.xz is not created :(

OK

> For the differences:
>   'make git-archive' and 'make package_source' create different files.
> Which one have you used for comparison?

I used make package_source.

> Here, 'make package_source' creates
>   LyX-2.3.tar.gz
>   LyX-2.3.tar.xz
>   LyX-2.3.tar.Z

Ah so xz is created? I must have missed that.

If you have time and want to take a look, compare the tar.gz you get
from CMake to the 2.2.0 tar from the following command:
yourself: ./autogen.sh && ./configure && make lyxdist

Alternatively, we can wait until we figure out other CMake issues if you
prefer.

Scott

> 
> and 'make git-archive' creates
>   LyX-2.3.0-47802git-Linux.tgz
> 
>   Kornel




signature.asc
Description: PGP signature

Re: One official build system?

[Pavel Sanda]

Kornel Benko wrote:
> (Select only one of them)
> But, yes, .tar.xz is not created :(

I know nothing of cmake, but we really want .xz. 
Not only it gets better compression ratio but it's
standard already:
http://henrich-on-debian.blogspot.cz/2016/06/which-compression-do-debian-packages-use.html

I guess you can easily code it like we do in autotools.
Pavel

Re: One official build system?

[Kornel Benko]

Am Montag, 13. Juni 2016 um 19:09:04, schrieb Scott Kostyshak 
> Note also that for me make package_source produces a tar.gz, not a
> tar.xz as you suggested above.

It depends on how you configure, so that 'make package' knows what to produce.
1.)  -DCPACK_SOURCE_TGZ:BOOL=ON
-> .tar.gz
2.)  -DCPACK_SOURCE_TBZ2:BOOL=ON
-> .bz2
3.) -DCPACK_SOURCE_TZ:BOOL=ON
-> .tar.Z
or
4.)  -DCPACK_SOURCE_ZIP:BOOL=ON
-> nothing on linux

(Select only one of them)
But, yes, .tar.xz is not created :(

For the differences:
'make git-archive' and 'make package_source' create different files.
Which one have you used for comparison?

Here, 'make package_source' creates
LyX-2.3.tar.gz
LyX-2.3.tar.xz
LyX-2.3.tar.Z

and 'make git-archive' creates
LyX-2.3.0-47802git-Linux.tgz

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Scott Kostyshak]

On Wed, Jun 08, 2016 at 07:29:34PM -0700, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > By the way, I saw your comment just above the definition of the lyxdist
> > target, which you introduced in 2010 (d407a15c):
> > 
> > 
> > #Wait some time for bumping automake 1.11, which can use dist-xz
> > #directly without this code, which is to be removed.
> > #xz has low compression by default, but can be affected via
> > #export XZ_OPT=-9ev put somewhere in the makefile.
> > lyxdist: dist
> > bunzip2 $(PACKAGE)-$(VERSION).tar.bz2
> > xz -9 $(PACKAGE)-$(VERSION).tar
> > ls -hl $(PACKAGE)-$(VERSION).tar.*
> > 
> > 
> > Should we use dist-xz directly now?
> 
> That would make sense provided -9 level can be maintained.
> I don't have time for the patch though.

OK. I'm not planning to look at this now. Maybe we should come back to
it once we make a decision on whether to move to CMake or not.

Scott


signature.asc
Description: PGP signature

Re: One official build system?

[Scott Kostyshak]

On Sat, Jun 04, 2016 at 09:48:28PM +0200, Kornel Benko wrote:
> Am Samstag, 4. Juni 2016 um 15:36:37, schrieb Scott Kostyshak 
> 
> > On Fri, Jun 03, 2016 at 03:40:59PM -0700, Pavel Sanda wrote:
> > > Scott Kostyshak wrote:
> > > > I'm still not sure what the implications of moving to CMake as our
> > > > official build system are (I should have made this more clear in my
> > > 
> > > To start with: If you make tarball with autotools and cmake is there
> > > difference between those two, do we get the same files/and their contets?
> > 
> > Good question. I don't know. There is no 'lyxdist' target for CMake and
> > no 'dist' target so I stopped there.
> 
>   # make package_source
>   --> LyX-2.3.tar.xz
> or
>   # make git_archive
>   --> LyX-2.3.0-47674git-Linux.tgz

Thanks. There are many differences compared to the .tar from autotools.
I can list the difference if you want, but since there are so many it
might be easier for you to take a look yourself.

You can make the tar with autotools as follows:
./autogen.sh && ./configure && make lyxdist

I did the comparison with a git checkout of 2.2.0, partly because make
lyxdist does not work for me now (I'll send a separate email about
this).

Note also that for me make package_source produces a tar.gz, not a
tar.xz as you suggested above. I don't think this difference is
important but I mention it in case it signals a fundamental difference
between our systems that explains why I get such a different tar from
the autotools tar.

Scott

> 
> > By the way, I saw your comment just above the definition of the lyxdist
> > target, which you introduced in 2010 (d407a15c):
> > 
> > 
> > #Wait some time for bumping automake 1.11, which can use dist-xz
> > #directly without this code, which is to be removed.
> > #xz has low compression by default, but can be affected via
> > #export XZ_OPT=-9ev put somewhere in the makefile.
> > lyxdist: dist
> > bunzip2 $(PACKAGE)-$(VERSION).tar.bz2
> > xz -9 $(PACKAGE)-$(VERSION).tar
> > ls -hl $(PACKAGE)-$(VERSION).tar.*
> > 
> > 
> > Should we use dist-xz directly now?
> > 
> > Scott
> 
>   Kornel




signature.asc
Description: PGP signature

Re: One official build system?

[Pavel Sanda]

Scott Kostyshak wrote:
> By the way, I saw your comment just above the definition of the lyxdist
> target, which you introduced in 2010 (d407a15c):
> 
> 
> #Wait some time for bumping automake 1.11, which can use dist-xz
> #directly without this code, which is to be removed.
> #xz has low compression by default, but can be affected via
> #export XZ_OPT=-9ev put somewhere in the makefile.
> lyxdist: dist
>   bunzip2 $(PACKAGE)-$(VERSION).tar.bz2
>   xz -9 $(PACKAGE)-$(VERSION).tar
>   ls -hl $(PACKAGE)-$(VERSION).tar.*
> 
> 
> Should we use dist-xz directly now?

That would make sense provided -9 level can be maintained.
I don't have time for the patch though.

Pavel

Re: One official build system?

[Stephan Witt]

Am 07.06.2016 um 14:36 schrieb Kornel Benko :
> 
> Am Dienstag, 7. Juni 2016 um 13:57:30, schrieb Stephan Witt 
>> Am 07.06.2016 um 13:46 schrieb Stephan Witt :
>>> 
>>> Am 07.06.2016 um 12:39 schrieb Kornel Benko :
> 
> The complete list of the files the final LyX.app contains is attached as 
> text file.
 
 Looks like there are many more files in the list. Probably not from LyX?
>>> 
>>> Yes, that’s why I’ve added comments to the list to mark them.
>>> 
 E.g.
/Applications/LyX.app/Contents/Frameworks/
/Applications/LyX.app/Contents/Library/
/Applications/LyX.app/Contents/PlugIns/
/Applications/LyX.app/Contents/Resources/dicts/
/Applications/LyX.app/Contents/Resources/thes/
/Applications/LyX.app/Contents/translations/
>> 
>> Perhaps I misunderstood.
>> 
>> These files are required to run LyX but not part of the install target.
>> Basically the files are private frameworks (aka shared libraries) with
>> Qt5.6, hunspell, libmagic and aspell, the translations and plugins
>> from Qt and the dictionaries and thesauri used at runtime.
> 
> Shouldn't they be at a location where other programs could access them too?
> That is: outside of ${prefix}?

No. Because other programs don’t need to access them.

The concept of the application bundle on Mac makes it completely
relocatable. One may try LyX as application before „installing“
it. All the essential parts of LyX except the OS libraries are
located inside the bundle.

To have multiple versions of LyX on my system I only have to give
them different names like LyX.app or LyX-2.3.0dev.app.

Stephan

Re: One official build system?

[Kornel Benko]

Am Dienstag, 7. Juni 2016 um 13:57:30, schrieb Stephan Witt 
> Am 07.06.2016 um 13:46 schrieb Stephan Witt :
> > 
> > Am 07.06.2016 um 12:39 schrieb Kornel Benko :
> >>> 
> >>> The complete list of the files the final LyX.app contains is attached as 
> >>> text file.
> >> 
> >> Looks like there are many more files in the list. Probably not from LyX?
> > 
> > Yes, that’s why I’ve added comments to the list to mark them.
> > 
> >> E.g.
> >>/Applications/LyX.app/Contents/Frameworks/
> >>/Applications/LyX.app/Contents/Library/
> >>/Applications/LyX.app/Contents/PlugIns/
> >>/Applications/LyX.app/Contents/Resources/dicts/
> >>/Applications/LyX.app/Contents/Resources/thes/
> >>/Applications/LyX.app/Contents/translations/
> 
> Perhaps I misunderstood.
> 
> These files are required to run LyX but not part of the install target.
> Basically the files are private frameworks (aka shared libraries) with
> Qt5.6, hunspell, libmagic and aspell, the translations and plugins
> from Qt and the dictionaries and thesauri used at runtime.

Shouldn't they be at a location where other programs could access them too?
That is: outside of ${prefix}?

> In Library is a tool to support meta-data-management of OSX for
> LyX files. This is not required but ATM installed by autotools.

OK
 
> Stephan

Kornel



signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Kornel Benko]

Am Dienstag, 7. Juni 2016 um 13:38:51, schrieb Stephan Witt 
> Am 07.06.2016 um 13:22 schrieb Kornel Benko :
> > 
> > Am Dienstag, 7. Juni 2016 um 12:39:12, schrieb Kornel Benko 
> >>> The complete list of the files the final LyX.app contains is attached as 
> >>> text file.
> > 
> > Can I get also a suffixed version of the list?
> 
> What is this?

Executables, manuals get the version suffix too.
So, under unix, I have
/usr/local/bin/lyx2.3
/usr/local/share/man/man1/lyxclient2.3.1
and so on.

> The LyX.app was built with „-with-version-suffix=-2.2“ - 
> probably this list is already what you’re want.

> Stephan

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Stephan Witt]

Am 07.06.2016 um 13:46 schrieb Stephan Witt :
> 
> Am 07.06.2016 um 12:39 schrieb Kornel Benko :
>>> 
>>> The complete list of the files the final LyX.app contains is attached as 
>>> text file.
>> 
>> Looks like there are many more files in the list. Probably not from LyX?
> 
> Yes, that’s why I’ve added comments to the list to mark them.
> 
>> E.g.
>>  /Applications/LyX.app/Contents/Frameworks/
>>  /Applications/LyX.app/Contents/Library/
>>  /Applications/LyX.app/Contents/PlugIns/
>>  /Applications/LyX.app/Contents/Resources/dicts/
>>  /Applications/LyX.app/Contents/Resources/thes/
>>  /Applications/LyX.app/Contents/translations/

Perhaps I misunderstood.

These files are required to run LyX but not part of the install target.
Basically the files are private frameworks (aka shared libraries) with
Qt5.6, hunspell, libmagic and aspell, the translations and plugins
from Qt and the dictionaries and thesauri used at runtime.

In Library is a tool to support meta-data-management of OSX for
LyX files. This is not required but ATM installed by autotools.

Stephan

Re: One official build system?

[Stephan Witt]

Am 07.06.2016 um 12:39 schrieb Kornel Benko :
> 
> Am Dienstag, 7. Juni 2016 um 08:31:53, schrieb Stephan Witt 
>> Am 06.06.2016 um 18:41 schrieb Kornel Benko :
>>> 
> ...
>>> Yes. Stephan could you send me the list of installed files if you install 
>>> with automake?
>>> I can try to use the same directories.
>> 
>> The same as with autotools :)
>> 
>> Some concrete values are:
>> 
>> bindir = ${prefix}/Contents/MacOS
> 
> Should lyx  (and tex2lyx etc) be installed there too?

Yes.

> If yes, shouldn’t be the the install command in src/CMakeLists.txt:158 be
> install(TARGETS ${_lyx} 
>BUNDLE DESTINATION . COMPONENT Runtime
>RUNTIME DESTINATION ${LYX_UTILITIES_INSTALL_PATH} COMPONENT Runtime)
> 
>> datadir = ${datarootdir}
>> datarootdir = ${prefix}/Contents/Resources
>> docdir = ${datarootdir}/doc/${PACKAGE_TARNAME}
>> infodir = ${datarootdir}/info
>> libdir = ${prefix}/Contents/Resources
>> localedir = ${datarootdir}/locale
>> mandir = ${datadir}/man
> 
> OK
> 
>> pkgpyexecdir = ${pyexecdir}/LyX-2.3
>> pkgpythondir = ${pythondir}/LyX-2.3
> 
> ???, missing in listing

Ignore it - it’s defined in Makefile and not used.

> 
>> prefix = /Users/stephan/git/lyx-build/LyX-2.3.0dev.app
> 
> Is this the same 'prefix' as used above, e.g. ${CMAKE_INSTALL_PREFIX}?

This is the directory where all parts should end up.

> 
>> real_pkgdatadir = 
>> /Users/stephan/git/lyx-build/LyX-2.3.0dev.app/Contents/Resources
>> 
>> The complete list of the files the final LyX.app contains is attached as 
>> text file.
> 
> Looks like there are many more files in the list. Probably not from LyX?

Yes, that’s why I’ve added comments to the list to mark them.

> E.g.
>   /Applications/LyX.app/Contents/Frameworks/
>   /Applications/LyX.app/Contents/Library/
>   /Applications/LyX.app/Contents/PlugIns/
>   /Applications/LyX.app/Contents/Resources/dicts/
>   /Applications/LyX.app/Contents/Resources/thes/
>   /Applications/LyX.app/Contents/translations/
> ...
> 
>>> 
>>> You mean from cmake? Have you tried "--debug-output" as cmake parameter?
>> 
>> I meant the output from build.
> 
> Don't know. What is the command to compile?

I’ve used
$ xcodebuild -project lyx-build/cmake/2.3.0dev/LyX.xcodeproj -target install

But that’s not important. I only wanted to say because of the missing log file
I copied the last lines of terminal output into the mail.

Stephan

Re: One official build system?

[Stephan Witt]

Am 07.06.2016 um 13:22 schrieb Kornel Benko :
> 
> Am Dienstag, 7. Juni 2016 um 12:39:12, schrieb Kornel Benko 
>>> The complete list of the files the final LyX.app contains is attached as 
>>> text file.
> 
> Can I get also a suffixed version of the list?

What is this?

The LyX.app was built with „-with-version-suffix=-2.2“ - 
probably this list is already what you’re want.

Stephan

Re: One official build system?

[Kornel Benko]

Am Dienstag, 7. Juni 2016 um 12:39:12, schrieb Kornel Benko 
> > The complete list of the files the final LyX.app contains is attached as 
> > text file.

Can I get also a suffixed version of the list?

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Kornel Benko]

Am Dienstag, 7. Juni 2016 um 08:31:53, schrieb Stephan Witt 
> Am 06.06.2016 um 18:41 schrieb Kornel Benko :
> > 
...
> > Yes. Stephan could you send me the list of installed files if you install 
> > with automake?
> > I can try to use the same directories.
> 
> The same as with autotools :)
> 
> Some concrete values are:
> 
> bindir = ${prefix}/Contents/MacOS

Should lyx  (and tex2lyx etc) be installed there too?
If yes, shouldn’t be the the install command in src/CMakeLists.txt:158 be
install(TARGETS ${_lyx} 
BUNDLE DESTINATION . COMPONENT Runtime
RUNTIME DESTINATION ${LYX_UTILITIES_INSTALL_PATH} COMPONENT Runtime)

> datadir = ${datarootdir}
> datarootdir = ${prefix}/Contents/Resources
> docdir = ${datarootdir}/doc/${PACKAGE_TARNAME}
> infodir = ${datarootdir}/info
> libdir = ${prefix}/Contents/Resources
> localedir = ${datarootdir}/locale
> mandir = ${datadir}/man

OK

> pkgpyexecdir = ${pyexecdir}/LyX-2.3
> pkgpythondir = ${pythondir}/LyX-2.3

???, missing in listing

> prefix = /Users/stephan/git/lyx-build/LyX-2.3.0dev.app

Is this the same 'prefix' as used above, e.g. ${CMAKE_INSTALL_PREFIX}?

> real_pkgdatadir = 
> /Users/stephan/git/lyx-build/LyX-2.3.0dev.app/Contents/Resources
> 
> The complete list of the files the final LyX.app contains is attached as text 
> file.

Looks like there are many more files in the list. Probably not from LyX?
E.g.
/Applications/LyX.app/Contents/Frameworks/
/Applications/LyX.app/Contents/Library/
/Applications/LyX.app/Contents/PlugIns/
/Applications/LyX.app/Contents/Resources/dicts/
/Applications/LyX.app/Contents/Resources/thes/
/Applications/LyX.app/Contents/translations/
...

> > 
> > You mean from cmake? Have you tried "--debug-output" as cmake parameter?
> 
> I meant the output from build.

Don't know. What is the command to compile? Is there a manual?
For instance for 'make' it should be:
# make VERBOSE=1 ...

> Stephan

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Kornel Benko]

Am Montag, 6. Juni 2016 um 20:53:47, schrieb Georg Baum 

> Kornel Benko wrote:
> 
> > Version suffix for bin and locales is already used as expected.
> 
> Very good.
> 
> > I think, there is nothing to do for windows yet, because it uses already
> > cmake.
> 
> OK (I was not sure whether the changes for linux would imply changews for 
> windows as well).
> 

I am not sure either. Have tried to not change anything for windows. But, as I 
know myself,
some bugs may well find their way ...

> Georg

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Kornel Benko]

Am Montag, 6. Juni 2016 um 21:03:05, schrieb Georg Baum 

> Kornel Benko wrote:
> 
> > Don't know if this helps, but I never use relative path with cmake.
> > #mkdir some_build_path
> > # cd some_build_path
> > # cmake abs_path_to_lyx_sources ...
> 
> I use relative paths, and it works fine.
> 
> 
> Georg

I meant it as a possibility for MAC.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Georg Baum]

Kornel Benko wrote:

> Am Sonntag, 5. Juni 2016 um 20:34:38, schrieb Liviu Andronic
> 
>> On Sun, Jun 5, 2016 at 7:43 PM, Kornel Benko  wrote:
> 
> Unfortunately cmake is not able yet to produce more than one debian
> package. Recently started discussions to support components for .rpm, but
> .deb is not that far. And we have more platforms.

The .deb packages created by cmake are really simple. They lack proper 
dependencies and interfere with the distro packages (a cmake generated 
package named "lyx" is different than the official one, so other packages 
depending on lyx might not work). I would not recommend to use these 
packages.

IMHO it does not make sense to recreate all debian/ubuntu tools for .deb or 
redhat tools for .rpm in cmake. cmake should build the stuff, and packaging 
is better done by the more advanced distro specific packaging tools. If you 
look at the debian packaging it will be very simple to replace autotools by 
cmake: Simply replace the dh_auto_configure call in 
http://anonscm.debian.org/cgit/pkg-lyx/lyx.git/tree/debian/rules by a 
corresponding cmake call.

>> >> > locale: $datarootdir/locale
>> >> > tex:$datarootdir/texmf/tex/latex/$package
>> >
>> > Same here.
>> >
>> Not sure what happens in this case, though.
>> 
> 
> If we could suffix them too ...

That was my suggestion. Otherwise packages will clash.


Georg

Re: One official build system?

[Georg Baum]

Scott Kostyshak wrote:

> On Sun, Jun 05, 2016 at 01:59:53PM +0200, Kornel Benko wrote:
>> 
>> OK, starting on the list first. I can only comment on the cmake part.
>> 
>> [A] detection of  external  dependencies
>> cmake does full detection IMHO
>> [B] create .rpm
>> cmake creates rpm, deb,
>> [E] create window package
>> don't know, we should ask Peter
> 
> CC'ing Peter then.

This table is old stuff and not important IMHO (maybe I should have deleted 
it before adding the new one). Any opinion on continuing in the wiki or in 
Development.lyx? If we continue in the wiki we should delete the old tables.


Georg

Re: One official build system?

[Georg Baum]

Kornel Benko wrote:

> Don't know if this helps, but I never use relative path with cmake.
> #mkdir some_build_path
> # cd some_build_path
> # cmake abs_path_to_lyx_sources ...

I use relative paths, and it works fine.


Georg

Re: One official build system?

[Georg Baum]

Kornel Benko wrote:

> Am Sonntag, 5. Juni 2016 um 19:03:51, schrieb Kornel Benko
> 
>> Am Sonntag, 5. Juni 2016 um 18:43:03, schrieb Georg Baum
>> 
>> > Kornel Benko wrote:
>> > 
> ...
>> > The remaining directories from the second list would be located as
>> > follows:
>> > 
>> > bin:$prefix/bin
>> > fonts:  $datarootdir/fonts/truetype/$package
> 
> I am not sure about this one. Are there clashes with
> the same files installed by different lyx-version?

If the fonts would always be in a subdirectory with version suffix then you 
could not install a versioned LyX in parallel to the distro package, for 
example. Using versioned directories ensures that packages can be installed 
in parallel. Which fonts are selected at runtime is a different story (and 
IMHO not important, they do not change often).

> How should latex select the correct data?

The fonts are picked up automatically by fontconfig if they are in any 
subdirectory of $datarootdir/fonts/truetype/.

>> > locale: $datarootdir/locale
>> > tex:$datarootdir/texmf/tex/latex/$package
> 
> Same here.

Same explanation as well;-)


Georg

Re: One official build system?

[Georg Baum]

Kornel Benko wrote:

> Version suffix for bin and locales is already used as expected.

Very good.

> I think, there is nothing to do for windows yet, because it uses already
> cmake.

OK (I was not sure whether the changes for linux would imply changews for 
windows as well).


Georg

Re: One official build system?

[Kornel Benko]

Am Montag, 6. Juni 2016 um 19:26:24, schrieb Liviu Andronic 
> On Mon, Jun 6, 2016 at 6:56 PM, Kornel Benko  wrote:
> > Am Sonntag, 5. Juni 2016 um 20:34:38, schrieb Liviu Andronic 
> > 
> >> On Sun, Jun 5, 2016 at 7:43 PM, Kornel Benko  wrote:
> >> > Am Sonntag, 5. Juni 2016 um 19:03:51, schrieb Kornel Benko 
> >> > 
> >> >> Am Sonntag, 5. Juni 2016 um 18:43:03, schrieb Georg Baum 
> >> >> 
> >> >> > Kornel Benko wrote:
> >> >> >
> >> > ...
> >> >> > The remaining directories from the second list would be located as 
> >> >> > follows:
> >> >> >
> >> >> > bin:$prefix/bin
> >> >> > fonts:  $datarootdir/fonts/truetype/$package
> >> >
> >> > I am not sure about this one. Are there clashes with
> >> > the same files installed by different lyx-version?
> >> > How should latex select the correct data?
> >> >
> >> On Ubuntu for the fonts-lyx packages I simply make them conflict with
> >> each other, meaning that the user can install only one on the same
> >> system (e.g. fonts-lyx or fonts-lyx2.2).
> >>
> >
> 
> 
> > Unfortunately cmake is not able yet to produce more than one debian 
> > package. Recently started
> > discussions to support components for .rpm, but .deb is not that far.
> > And we have more platforms.
> >
> As far as my requirements go, I do not need cmake to output debian
> packages --- Launchpad and Debian tools take care of that. I only need
> cmake to install packages in expected directories with customizable
> paths (as we discussed earlier). So I don't think this is an issue.

This is easy. 'make package' is able to create a tar file. All files are
at the correct locations.

I for one _disable_ this creation with
# cmake ... -DCPACK_BINARY_TGZ:BOOL=OFF ...
but of course we can set ' -DCPACK_BINARY_TGZ:BOOL=ON'

> Liviu
> 
 Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Liviu Andronic]

On Mon, Jun 6, 2016 at 6:56 PM, Kornel Benko  wrote:
> Am Sonntag, 5. Juni 2016 um 20:34:38, schrieb Liviu Andronic 
> 
>> On Sun, Jun 5, 2016 at 7:43 PM, Kornel Benko  wrote:
>> > Am Sonntag, 5. Juni 2016 um 19:03:51, schrieb Kornel Benko 
>> >> Am Sonntag, 5. Juni 2016 um 18:43:03, schrieb Georg Baum 
>> >> 
>> >> > Kornel Benko wrote:
>> >> >
>> > ...
>> >> > The remaining directories from the second list would be located as 
>> >> > follows:
>> >> >
>> >> > bin:$prefix/bin
>> >> > fonts:  $datarootdir/fonts/truetype/$package
>> >
>> > I am not sure about this one. Are there clashes with
>> > the same files installed by different lyx-version?
>> > How should latex select the correct data?
>> >
>> On Ubuntu for the fonts-lyx packages I simply make them conflict with
>> each other, meaning that the user can install only one on the same
>> system (e.g. fonts-lyx or fonts-lyx2.2).
>>
>


> Unfortunately cmake is not able yet to produce more than one debian package. 
> Recently started
> discussions to support components for .rpm, but .deb is not that far.
> And we have more platforms.
>
As far as my requirements go, I do not need cmake to output debian
packages --- Launchpad and Debian tools take care of that. I only need
cmake to install packages in expected directories with customizable
paths (as we discussed earlier). So I don't think this is an issue.

Liviu


>>
>> >> > locale: $datarootdir/locale
>> >> > tex:$datarootdir/texmf/tex/latex/$package
>> >
>> > Same here.
>> >
>> Not sure what happens in this case, though.
>>
>
> If we could suffix them too ...
>
>> Liviu
>>
>>
>
> Kornel

Re: One official build system?

[Kornel Benko]

Am Sonntag, 5. Juni 2016 um 20:34:38, schrieb Liviu Andronic 

> On Sun, Jun 5, 2016 at 7:43 PM, Kornel Benko  wrote:
> > Am Sonntag, 5. Juni 2016 um 19:03:51, schrieb Kornel Benko 
> >> Am Sonntag, 5. Juni 2016 um 18:43:03, schrieb Georg Baum 
> >> 
> >> > Kornel Benko wrote:
> >> >
> > ...
> >> > The remaining directories from the second list would be located as 
> >> > follows:
> >> >
> >> > bin:$prefix/bin
> >> > fonts:  $datarootdir/fonts/truetype/$package
> >
> > I am not sure about this one. Are there clashes with
> > the same files installed by different lyx-version?
> > How should latex select the correct data?
> >
> On Ubuntu for the fonts-lyx packages I simply make them conflict with
> each other, meaning that the user can install only one on the same
> system (e.g. fonts-lyx or fonts-lyx2.2).
> 

Unfortunately cmake is not able yet to produce more than one debian package. 
Recently started
discussions to support components for .rpm, but .deb is not that far.
And we have more platforms.

> 
> >> > locale: $datarootdir/locale
> >> > tex:$datarootdir/texmf/tex/latex/$package
> >
> > Same here.
> >
> Not sure what happens in this case, though.
> 

If we could suffix them too ...

> Liviu
> 
> 

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Kornel Benko]

Am Sonntag, 5. Juni 2016 um 12:27:52, schrieb Stephan Witt 
> Am 05.06.2016 um 11:13 schrieb Georg Baum :
> > 
> > Scott Kostyshak wrote:
> > 
> >> On Sat, Jun 04, 2016 at 07:55:28PM +0200, Stephan Witt wrote:
> >>> 
>  Am 04.06.2016 um 10:15 schrieb Liviu Andronic :
>  
>  If moving to cmake definitively would imply losing version suffix
>  functionality, this would be a big issue for my packaging arrangements
>  for Ubuntu builds.
> >>> 
> >>> +1
> >>> 
> >>> On Mac the version suffix is essential too.
> >> 
> >> I just want to make sure you saw Kornel's reply to that. I don't know if
> >> it addresses your needs or not.
> > 
> > IMHO it does. Livius builds could be done using their current names if the 
> > boolean switch is replaced by a string version, which is easy to do as 
> > Kornel wrote.
> 
> Yes. I think so.
> 
> > 
> >>> I just tried to build a Mac application with cmake and failed.
> >> 
> >> What was the error?
> >> 
> >>> It looks like a lot of work or to learn to make this working.

Yes. Stephan could you send me the list of installed files if you install with 
automake?
I can try to use the same directories.

> >> This might be a reason to stop this discussion here. You already do a
> >> huge favor by taking care of the Mac builds. It would not make sense to
> >> make it more difficult. I was hoping that in the long-run it would
> >> actually be easier for you, but perhaps the transition would be too
> >> frustrating and time-consuming.
> > 
> > We should not yet stop the discussion. We need more information about the 
> > problems.
> 
> I didn’t want to put the discussion on hold. I hadn’t the time to write
> a mail with enough details at the moment.
> 
> I use cmake to create Xcode projects for debugging purpose. So, it’s possible
> to create a working binary with cmake. To do the packaging with cmake is 
> another
> story and - at least on Mac - not done with LyX yet. No surprise it’s not
> working though.
> 
> The packaging is done in three steps with autotools + scripts:
> 1. make install with the appropriate directory structure for Mac
> 2. adding the 3rd party components required to run LyX
> 3. create a mountable disk image and put the LyX app and some
> decorative stuff there and compress the final result.
> 
> To get the first impression how difficult it is with cmake I tried two ways:
> 1. standard cmake install (the naive way) results in a Linux like directory
> structure without an usable application.
> 2. LYX_DMG=ON cmake install (marked as experimental) is better as it copies
> the components of LyX to the appropriate directory structure for Mac.
> Therefore the 2nd one should be the default on Mac.
> 
> Nevertheless it doesn’t work ATM because of the type of the dependency on Qt.
> This is not easy to explain - but I’ll try it.
> 
> The runtime linker knows of the usual LD_LIBRARY_PATH mechanism like Unix.
> An more secure and more advanced approach is the modified RPATH mechanism.
> For system libraries one uses hard coded library references.
> 
> The problem is the RPATH mechanism. Qt frameworks (a collection of header
> files, shared libraries and documentation) are build with these. To distribute
> these frameworks they have to be placed on a fixed location for system wide 
> use
> or inside the LyX application as so called private frameworks. LyX is using
> the latter and I cannot see why this should be changed. The cmake build
> for LyX needs to be extended to copy the Qt libraries into the LyX application
> in or before the „fixup_bundle“ phase of the packaging step. I’m almost sure
> this can be done in a reliable and clean way with cmake. That’s why I said
> there is something to learn and to spend some time with.

Sorry, you are on your own here I suppose. For me the MAC is a mystery.

> Finally I want to add the concrete error log - it ends with:
> ===
> -- fixup_bundle: preparing…
> ...
> -- warning: gp_resolved_file_type non-absolute file 
> '@rpath/QtCore.framework/Versions/5/QtCore' returning type 'other' -- 
> possibly incorrect
> 
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
> 
> warning: target '@rpath/QtGui.framework/Versions/5/QtGui' is not absolute...
> warning: target '@rpath/QtGui.framework/Versions/5/QtGui' does not exist...

Don't know if this helps, but I never use relative path with cmake.
#mkdir some_build_path
# cd some_build_path
# cmake abs_path_to_lyx_sources ...

> CMake Error at /opt/local/share/cmake-3.4/Modules/GetPrerequisites.cmake:800 
> (message):
>   /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolc
>   hain/usr/bin/otool failed: 1
>   
>   error:
>   /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolc
>   hain/usr/bin/otool: can't open file:
>   

Re: One official build system?

[Scott Kostyshak]

On Sun, Jun 05, 2016 at 01:59:53PM +0200, Kornel Benko wrote:
> Am Sonntag, 5. Juni 2016 um 12:13:51, schrieb Georg Baum 
> 
> > Kornel Benko wrote:
> > 
> > > Am Samstag, 4. Juni 2016 um 09:55:10, schrieb Georg Baum
> > >> 
> > >> However, this is not so important. With autotools we have only very few
> > >> people who understand the macro stuff in m4/, config/ and configure.ac,
> > >> but everybody is able to do his modifications to the various Makefile.am.
> > >> I am pretty sure that cmake can be setup in a similar way, so that we
> > >> have the complicated parts that need expert knowledge and are not changed
> > >> often, and the easy ones that can be changed by everybody.
> > > 
> > > Sort of. The comparable ones are m4 macros and macros in the
> > > development/cmake/modules directory. But I do not see cmake-analogy to
> > > Makefile.am files.
> > 
> > I thought those were the CMakeLists.txt files in the individual 
> > directories? 
> > The purpose of Makefile.am is to define what gets built, packaged and 
> > installed in that directory in a way as simple as possible. I had the 
> > impression that the purpose of CMakeLists.txt is the same. If it is not 
> > possible to set up cmake in a way that the average developer needs to know 
> > as little cmake stuff as he currently needs to know from autotools, then 
> > this would be a big disadvantage.
> 
> Yes, you are right. Sometimes I cannot see the forest. Too many trees.
> 
> > >> I would suggest to make a comparison table of build system features
> > >> in the wiki, and everybody adds the ones he needs. Then we can see which
> > >> build system supports which feature, and how much work it would be to
> > >> implement the mising ones in cmake.
> > > 
> > > +1
> > 
> > I started a quite incomplete table at 
> > http://wiki.lyx.org/Devel/BuildSystems 
> > with some options I used. I would invite everybody to contribute to make it 
> > complete. The only question is whether we should continue it in the wiki or 
> > in Development.lyx. I would prefer the latter, since it is easier to edit 
> > and you get better visual feedback, but of course this would make 
> > contributions from non-developers more hard.
> 
> OK, starting on the list first. I can only comment on the cmake part.
> 
> [A] detection of  external  dependencies
>   cmake does full detection IMHO
> [B] create .rpm
>   cmake creates rpm, deb,
> [E] create window package
>   don't know, we should ask Peter

CC'ing Peter then.

Scott

> [I] Reliability
>   why is scons higher then autotools?
>   cmake not reliable?
> [J] Supported platforms
>   cmake supports all our platforms IMHO
> 
> Commandline arguments for autotools and cmake (arguments for cmake)
> custom archiver  -DCMAKE_AR=
> custom assemble   -DCMAKE_AS=
> custom C compiler  -DCMAKE_CXX_COMPILER=
> C++ runtime library   -DLYX_STDLIB_DEBUG=ON
> included boost   -DLYX_EXTERNAL_BOOST=OFF
> included hunspell  -DLYX_3RDPARTY_BUILD=ON
> included zlib  -DLYX_3RDPARTY_BUILD=ON
> installation prefix  -DCMAKE_INSTALL_PREFIX=
> version suffixin work
> verbose compiler output -DLYX_QUIET=OFF
> 
> 
> > >> One thing I noticed recently is the
> > >> version suffix: Which autotools you can use an arbitrary one, with cmake
> > >> you can only toggle between a predefined one or none at all, which is a
> > >> problem if you want to compare two different builds of the same version
> > >> with separate configurations (e.g. qt4/qt5 or different compiler
> > >> settings).
> > > 
> > > I never had problems with this. Each build with different settings can
> > > have its own build-dir, so the comparison is trivial. I am doing it this
> > > way. So for example my build dir for lyx using gcc5.3 with qt5.6 is
> > > '/usr/BUILD/BuildLyxGitQt5.6main-gcc5.3'
> > > 
> > > We don't need to install first.
> > > 
> > > But it is also easy to change the boolean selecting suffix to be a string.
> > 
> > IMHO it is needed. Sometimes you want to install and cannot use the build 
> > dir only. For example, Liviu would need to rename his .deb packages if we 
> > would switch to cmake right now, and this would be cumbersome for the users.
> > 
> 
> I started the work. But I have to know, what should be affected by the suffix.
> Suffix = xy
> 1.) Installations directory (probably not)
> 2.) Environment variables (like LYX_USERDIR_xy)
> 3.) Package name
> 4.) Program suffixes (lyx2.3.dev)
> 5.) Data directory (for lyx-system-lib-dir)
> 6.) Binary dir
> 
> > Georg
> 
> 
>   Kornel




signature.asc
Description: PGP signature

Re: One official build system?

[Liviu Andronic]

On Sun, Jun 5, 2016 at 7:43 PM, Kornel Benko  wrote:
> Am Sonntag, 5. Juni 2016 um 19:03:51, schrieb Kornel Benko 
>> Am Sonntag, 5. Juni 2016 um 18:43:03, schrieb Georg Baum 
>> 
>> > Kornel Benko wrote:
>> >
> ...
>> > The remaining directories from the second list would be located as follows:
>> >
>> > bin:$prefix/bin
>> > fonts:  $datarootdir/fonts/truetype/$package
>
> I am not sure about this one. Are there clashes with
> the same files installed by different lyx-version?
> How should latex select the correct data?
>
On Ubuntu for the fonts-lyx packages I simply make them conflict with
each other, meaning that the user can install only one on the same
system (e.g. fonts-lyx or fonts-lyx2.2).




>> > locale: $datarootdir/locale
>> > tex:$datarootdir/texmf/tex/latex/$package
>
> Same here.
>
Not sure what happens in this case, though.


Liviu


> Kornel



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: One official build system?

[Kornel Benko]

Am Sonntag, 5. Juni 2016 um 19:03:51, schrieb Kornel Benko 
> Am Sonntag, 5. Juni 2016 um 18:43:03, schrieb Georg Baum 
> 
> > Kornel Benko wrote:
> > 
...
> > The remaining directories from the second list would be located as follows:
> > 
> > bin:$prefix/bin
> > fonts:  $datarootdir/fonts/truetype/$package

I am not sure about this one. Are there clashes with
the same files installed by different lyx-version?
How should latex select the correct data?

> > locale: $datarootdir/locale
> > tex:$datarootdir/texmf/tex/latex/$package

Same here.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Kornel Benko]

Am Sonntag, 5. Juni 2016 um 18:43:03, schrieb Georg Baum 

> Kornel Benko wrote:
> 
> > ATM cmake installs almost everything under the installation directory.
> > Exceptions are (defaults for versioned)
> > manuals /usr/local/man, (e.g. /usr/local/man/man1/man1/lyxclient2.3.1)
> > lyx-icon /usr/local/share/icons/hicolor/scalable/apps/lyx2.3.svg
> > desktop /usr/local/share/applications/lyx2.3.desktop
> > 
> > So, under the installation directory we find directories
> > bin, bind, commands, doc, examples, fonts, images, kbd, layouts, locale,
> > lyx2lyx, scripts, templates tex, ui
> 
> Thanks for the explanation, now I understand what is meant. IMHO we should 
> follow the GNU standards (which autotools do): 
> http://www.gnu.org/prep/standards/standards.html#Directory-Variables
> 
> This means we have a prefix (defaults to /usr/local and is set to /usr by 
> distro packagers). Everything is installed below the prefix. The listed 
> exceptions above would fit in this scheme, but the differences are in the 
> second list:
> 
> All LyX specific directories (bind, commands, doc, examples, images, kbd, 
> layouts, lyx2lyx, scripts, templates, ui) should be under $datadir which 
> defaults to $datarootdir/$package, e.g. /usr/local/share/lyx2.3 
> ($datarootdir defaults to $prefix/share).
> 
> The remaining directories from the second list would be located as follows:
> 
> bin:$prefix/bin
> fonts:  $datarootdir/fonts/truetype/$package
> locale: $datarootdir/locale
> tex:$datarootdir/texmf/tex/latex/$package

OK.

> Both the binaries in $bin and the translations in $locale would get a 
> version suffix.

Version suffix for bin and locales is already used as expected.

> For windows the easiest thing would be to set both $prefix and $datarootdir 
> to the same installation directory. The only thing which would be special 
> would be the TeX files.

I think, there is nothing to do for windows yet, because it uses already cmake.

> > Each of them _could_ be installed on different place, one has only to
> > specify where do we want them. The prerequisite (IMHO) is that we should
> > be able to install different versions at the same time. Without conflicts.
> 
> Yes. In addition, there are certain standards that should be followed, so 
> that e.g. translations are found without special configurations.
> 

Yes.

> Georg

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Georg Baum]

Kornel Benko wrote:

> ATM cmake installs almost everything under the installation directory.
> Exceptions are (defaults for versioned)
> manuals /usr/local/man, (e.g. /usr/local/man/man1/man1/lyxclient2.3.1)
> lyx-icon /usr/local/share/icons/hicolor/scalable/apps/lyx2.3.svg
> desktop /usr/local/share/applications/lyx2.3.desktop
> 
> So, under the installation directory we find directories
> bin, bind, commands, doc, examples, fonts, images, kbd, layouts, locale,
> lyx2lyx, scripts, templates tex, ui

Thanks for the explanation, now I understand what is meant. IMHO we should 
follow the GNU standards (which autotools do): 
http://www.gnu.org/prep/standards/standards.html#Directory-Variables

This means we have a prefix (defaults to /usr/local and is set to /usr by 
distro packagers). Everything is installed below the prefix. The listed 
exceptions above would fit in this scheme, but the differences are in the 
second list:

All LyX specific directories (bind, commands, doc, examples, images, kbd, 
layouts, lyx2lyx, scripts, templates, ui) should be under $datadir which 
defaults to $datarootdir/$package, e.g. /usr/local/share/lyx2.3 
($datarootdir defaults to $prefix/share).

The remaining directories from the second list would be located as follows:

bin:$prefix/bin
fonts:  $datarootdir/fonts/truetype/$package
locale: $datarootdir/locale
tex:$datarootdir/texmf/tex/latex/$package

Both the binaries in $bin and the translations in $locale would get a 
version suffix.

For windows the easiest thing would be to set both $prefix and $datarootdir 
to the same installation directory. The only thing which would be special 
would be the TeX files.

> Each of them _could_ be installed on different place, one has only to
> specify where do we want them. The prerequisite (IMHO) is that we should
> be able to install different versions at the same time. Without conflicts.

Yes. In addition, there are certain standards that should be followed, so 
that e.g. translations are found without special configurations.


Georg

Re: One official build system?

[Liviu Andronic]

On Sun, Jun 5, 2016 at 4:20 PM, Georg Baum
 wrote:
> Kornel Benko wrote:
>
>> OK, starting on the list first. I can only comment on the cmake part.
>>
>> [A] detection of  external  dependencies
>> cmake does full detection IMHO
>> [B] create .rpm
>> cmake creates rpm, deb,
>> [E] create window package
>> don't know, we should ask Peter
>> [I] Reliability
>> why is scons higher then autotools?
>> cmake not reliable?
>> [J] Supported platforms
>> cmake supports all our platforms IMHO
>
> This is an old table, I did not look at it (I re-used an existing page with
> a suitable name).
>
>> Commandline arguments for autotools and cmake (arguments for cmake)
>> custom archiver  -DCMAKE_AR=
>> custom assemble   -DCMAKE_AS=
>> custom C compiler  -DCMAKE_CXX_COMPILER=
>> C++ runtime library   -DLYX_STDLIB_DEBUG=ON
>> included boost   -DLYX_EXTERNAL_BOOST=OFF
>> included hunspell  -DLYX_3RDPARTY_BUILD=ON
>> included zlib  -DLYX_3RDPARTY_BUILD=ON
>> installation prefix  -DCMAKE_INSTALL_PREFIX=
>> version suffixin work
>> verbose compiler output -DLYX_QUIET=OFF
>
> Thanks.
>
>> I started the work. But I have to know, what should be affected by the
>> suffix. Suffix = xy
>> 1.) Installations directory (probably not)
>> 2.) Environment variables (like LYX_USERDIR_xy)
>> 3.) Package name
>> 4.) Program suffixes (lyx2.3.dev)
>> 5.) Data directory (for lyx-system-lib-dir)
>> 6.) Binary dir
>
> The same what is affected by autotools --with-version-suffix ;-)
>
+1

At least on Ubuntu the package name is controlled by Debian packaging,
so this isn't something we should worry about. What is important in my
limited experience is to have binaries with appropriate suffix, the
various data dirs with appropriate suffix (including the ~./lyx2.3.dev
dir).

Liviu


> 2.) to 4.) definitely yes. What is the difference between 1 and 6)? My guess
> would be that this should not be affected.
>
>
> Georg
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: One official build system?

[Kornel Benko]

Am Sonntag, 5. Juni 2016 um 16:20:49, schrieb Georg Baum 

> Kornel Benko wrote:
> 
> > OK, starting on the list first. I can only comment on the cmake part.
> > 
> > [A] detection of  external  dependencies
> > cmake does full detection IMHO
> > [B] create .rpm
> > cmake creates rpm, deb,
> > [E] create window package
> > don't know, we should ask Peter
> > [I] Reliability
> > why is scons higher then autotools?
> > cmake not reliable?
> > [J] Supported platforms
> > cmake supports all our platforms IMHO
> 
> This is an old table, I did not look at it (I re-used an existing page with 
> a suitable name).
> 
> > Commandline arguments for autotools and cmake (arguments for cmake)
> > custom archiver  -DCMAKE_AR=
> > custom assemble   -DCMAKE_AS=
> > custom C compiler  -DCMAKE_CXX_COMPILER=
> > C++ runtime library   -DLYX_STDLIB_DEBUG=ON
> > included boost   -DLYX_EXTERNAL_BOOST=OFF
> > included hunspell  -DLYX_3RDPARTY_BUILD=ON
> > included zlib  -DLYX_3RDPARTY_BUILD=ON
> > installation prefix  -DCMAKE_INSTALL_PREFIX=
> > version suffixin work
> > verbose compiler output -DLYX_QUIET=OFF
> 
> Thanks.
> 
> > I started the work. But I have to know, what should be affected by the
> > suffix. Suffix = xy
> > 1.) Installations directory (probably not)
> > 2.) Environment variables (like LYX_USERDIR_xy)
> > 3.) Package name
> > 4.) Program suffixes (lyx2.3.dev)
> > 5.) Data directory (for lyx-system-lib-dir)
> > 6.) Binary dir
> 
> The same what is affected by autotools --with-version-suffix ;-)
> 
> 2.) to 4.) definitely yes. What is the difference between 1 and 6)? My guess 
> would be that this should not be affected.
> 

ATM cmake installs almost everything under the installation directory.
Exceptions are (defaults for versioned)
manuals /usr/local/man, (e.g. /usr/local/man/man1/man1/lyxclient2.3.1)
lyx-icon /usr/local/share/icons/hicolor/scalable/apps/lyx2.3.svg
desktop /usr/local/share/applications/lyx2.3.desktop

So, under the installation directory we find directories
bin, bind, commands, doc, examples, fonts, images, kbd, layouts, locale, 
lyx2lyx, scripts, templates tex, ui

Each of them _could_ be installed on different place, one has only to specify 
where do we want them.
The prerequisite (IMHO) is that we should be able to install different versions 
at the same time. Without conflicts.

> Georg

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Georg Baum]

Kornel Benko wrote:

> OK, starting on the list first. I can only comment on the cmake part.
> 
> [A] detection of  external  dependencies
> cmake does full detection IMHO
> [B] create .rpm
> cmake creates rpm, deb,
> [E] create window package
> don't know, we should ask Peter
> [I] Reliability
> why is scons higher then autotools?
> cmake not reliable?
> [J] Supported platforms
> cmake supports all our platforms IMHO

This is an old table, I did not look at it (I re-used an existing page with 
a suitable name).

> Commandline arguments for autotools and cmake (arguments for cmake)
> custom archiver  -DCMAKE_AR=
> custom assemble   -DCMAKE_AS=
> custom C compiler  -DCMAKE_CXX_COMPILER=
> C++ runtime library   -DLYX_STDLIB_DEBUG=ON
> included boost   -DLYX_EXTERNAL_BOOST=OFF
> included hunspell  -DLYX_3RDPARTY_BUILD=ON
> included zlib  -DLYX_3RDPARTY_BUILD=ON
> installation prefix  -DCMAKE_INSTALL_PREFIX=
> version suffixin work
> verbose compiler output -DLYX_QUIET=OFF

Thanks.

> I started the work. But I have to know, what should be affected by the
> suffix. Suffix = xy
> 1.) Installations directory (probably not)
> 2.) Environment variables (like LYX_USERDIR_xy)
> 3.) Package name
> 4.) Program suffixes (lyx2.3.dev)
> 5.) Data directory (for lyx-system-lib-dir)
> 6.) Binary dir

The same what is affected by autotools --with-version-suffix ;-)

2.) to 4.) definitely yes. What is the difference between 1 and 6)? My guess 
would be that this should not be affected.


Georg

Re: One official build system?

[Kornel Benko]

Am Sonntag, 5. Juni 2016 um 12:13:51, schrieb Georg Baum 

> Kornel Benko wrote:
> 
> > Am Samstag, 4. Juni 2016 um 09:55:10, schrieb Georg Baum
> >> 
> >> However, this is not so important. With autotools we have only very few
> >> people who understand the macro stuff in m4/, config/ and configure.ac,
> >> but everybody is able to do his modifications to the various Makefile.am.
> >> I am pretty sure that cmake can be setup in a similar way, so that we
> >> have the complicated parts that need expert knowledge and are not changed
> >> often, and the easy ones that can be changed by everybody.
> > 
> > Sort of. The comparable ones are m4 macros and macros in the
> > development/cmake/modules directory. But I do not see cmake-analogy to
> > Makefile.am files.
> 
> I thought those were the CMakeLists.txt files in the individual directories? 
> The purpose of Makefile.am is to define what gets built, packaged and 
> installed in that directory in a way as simple as possible. I had the 
> impression that the purpose of CMakeLists.txt is the same. If it is not 
> possible to set up cmake in a way that the average developer needs to know 
> as little cmake stuff as he currently needs to know from autotools, then 
> this would be a big disadvantage.

Yes, you are right. Sometimes I cannot see the forest. Too many trees.

> >> I would suggest to make a comparison table of build system features
> >> in the wiki, and everybody adds the ones he needs. Then we can see which
> >> build system supports which feature, and how much work it would be to
> >> implement the mising ones in cmake.
> > 
> > +1
> 
> I started a quite incomplete table at http://wiki.lyx.org/Devel/BuildSystems 
> with some options I used. I would invite everybody to contribute to make it 
> complete. The only question is whether we should continue it in the wiki or 
> in Development.lyx. I would prefer the latter, since it is easier to edit 
> and you get better visual feedback, but of course this would make 
> contributions from non-developers more hard.

OK, starting on the list first. I can only comment on the cmake part.

[A] detection of  external  dependencies
cmake does full detection IMHO
[B] create .rpm
cmake creates rpm, deb,
[E] create window package
don't know, we should ask Peter
[I] Reliability
why is scons higher then autotools?
cmake not reliable?
[J] Supported platforms
cmake supports all our platforms IMHO

Commandline arguments for autotools and cmake (arguments for cmake)
custom archiver  -DCMAKE_AR=
custom assemble   -DCMAKE_AS=
custom C compiler  -DCMAKE_CXX_COMPILER=
C++ runtime library   -DLYX_STDLIB_DEBUG=ON
included boost   -DLYX_EXTERNAL_BOOST=OFF
included hunspell  -DLYX_3RDPARTY_BUILD=ON
included zlib  -DLYX_3RDPARTY_BUILD=ON
installation prefix  -DCMAKE_INSTALL_PREFIX=
version suffixin work
verbose compiler output -DLYX_QUIET=OFF


> >> One thing I noticed recently is the
> >> version suffix: Which autotools you can use an arbitrary one, with cmake
> >> you can only toggle between a predefined one or none at all, which is a
> >> problem if you want to compare two different builds of the same version
> >> with separate configurations (e.g. qt4/qt5 or different compiler
> >> settings).
> > 
> > I never had problems with this. Each build with different settings can
> > have its own build-dir, so the comparison is trivial. I am doing it this
> > way. So for example my build dir for lyx using gcc5.3 with qt5.6 is
> > '/usr/BUILD/BuildLyxGitQt5.6main-gcc5.3'
> > 
> > We don't need to install first.
> > 
> > But it is also easy to change the boolean selecting suffix to be a string.
> 
> IMHO it is needed. Sometimes you want to install and cannot use the build 
> dir only. For example, Liviu would need to rename his .deb packages if we 
> would switch to cmake right now, and this would be cumbersome for the users.
> 

I started the work. But I have to know, what should be affected by the suffix.
Suffix = xy
1.) Installations directory (probably not)
2.) Environment variables (like LYX_USERDIR_xy)
3.) Package name
4.) Program suffixes (lyx2.3.dev)
5.) Data directory (for lyx-system-lib-dir)
6.) Binary dir

> Georg


Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Stephan Witt]

Am 05.06.2016 um 11:13 schrieb Georg Baum :
> 
> Scott Kostyshak wrote:
> 
>> On Sat, Jun 04, 2016 at 07:55:28PM +0200, Stephan Witt wrote:
>>> 
 Am 04.06.2016 um 10:15 schrieb Liviu Andronic :
 
 If moving to cmake definitively would imply losing version suffix
 functionality, this would be a big issue for my packaging arrangements
 for Ubuntu builds.
>>> 
>>> +1
>>> 
>>> On Mac the version suffix is essential too.
>> 
>> I just want to make sure you saw Kornel's reply to that. I don't know if
>> it addresses your needs or not.
> 
> IMHO it does. Livius builds could be done using their current names if the 
> boolean switch is replaced by a string version, which is easy to do as 
> Kornel wrote.

Yes. I think so.

> 
>>> I just tried to build a Mac application with cmake and failed.
>> 
>> What was the error?
>> 
>>> It looks like a lot of work or to learn to make this working.
>> 
>> This might be a reason to stop this discussion here. You already do a
>> huge favor by taking care of the Mac builds. It would not make sense to
>> make it more difficult. I was hoping that in the long-run it would
>> actually be easier for you, but perhaps the transition would be too
>> frustrating and time-consuming.
> 
> We should not yet stop the discussion. We need more information about the 
> problems.

I didn’t want to put the discussion on hold. I hadn’t the time to write
a mail with enough details at the moment.

I use cmake to create Xcode projects for debugging purpose. So, it’s possible
to create a working binary with cmake. To do the packaging with cmake is another
story and - at least on Mac - not done with LyX yet. No surprise it’s not
working though.

The packaging is done in three steps with autotools + scripts:
1. make install with the appropriate directory structure for Mac
2. adding the 3rd party components required to run LyX
3. create a mountable disk image and put the LyX app and some
decorative stuff there and compress the final result.

To get the first impression how difficult it is with cmake I tried two ways:
1. standard cmake install (the naive way) results in a Linux like directory
structure without an usable application.
2. LYX_DMG=ON cmake install (marked as experimental) is better as it copies
the components of LyX to the appropriate directory structure for Mac.
Therefore the 2nd one should be the default on Mac.

Nevertheless it doesn’t work ATM because of the type of the dependency on Qt.
This is not easy to explain - but I’ll try it.

The runtime linker knows of the usual LD_LIBRARY_PATH mechanism like Unix.
An more secure and more advanced approach is the modified RPATH mechanism.
For system libraries one uses hard coded library references.

The problem is the RPATH mechanism. Qt frameworks (a collection of header
files, shared libraries and documentation) are build with these. To distribute
these frameworks they have to be placed on a fixed location for system wide use
or inside the LyX application as so called private frameworks. LyX is using
the latter and I cannot see why this should be changed. The cmake build
for LyX needs to be extended to copy the Qt libraries into the LyX application
in or before the „fixup_bundle“ phase of the packaging step. I’m almost sure
this can be done in a reliable and clean way with cmake. That’s why I said
there is something to learn and to spend some time with.

Finally I want to add the concrete error log - it ends with:
===
-- fixup_bundle: preparing…
...
-- warning: gp_resolved_file_type non-absolute file 
'@rpath/QtCore.framework/Versions/5/QtCore' returning type 'other' -- possibly 
incorrect
-- 
warning: cannot resolve item '@rpath/QtCore.framework/Versions/5/QtCore'

  possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?

warning: target '@rpath/QtGui.framework/Versions/5/QtGui' is not absolute...
warning: target '@rpath/QtGui.framework/Versions/5/QtGui' does not exist...
CMake Error at /opt/local/share/cmake-3.4/Modules/GetPrerequisites.cmake:800 
(message):
  
  
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool
  failed: 1

  error:
  
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool:
  can't open file: @rpath/QtGui.framework/Versions/5/QtGui (No such file or
  directory)

Call Stack (most recent call first):
  /opt/local/share/cmake-3.4/Modules/GetPrerequisites.cmake:925 
(get_prerequisites)
  /opt/local/share/cmake-3.4/Modules/BundleUtilities.cmake:555 
(get_prerequisites)
  /opt/local/share/cmake-3.4/Modules/BundleUtilities.cmake:804 (get_bundle_keys)
  development/cmake/post_install/cmake_install.cmake:52 (fixup_bundle)
  cmake_install.cmake:2703 (include)
  


make: *** [install_buildpart_0] Error 1



I tried to find a log file of the build but didn’t find any.

Re: One official build system?

[Georg Baum]

Kornel Benko wrote:

> Am Samstag, 4. Juni 2016 um 09:55:10, schrieb Georg Baum
>> 
>> However, this is not so important. With autotools we have only very few
>> people who understand the macro stuff in m4/, config/ and configure.ac,
>> but everybody is able to do his modifications to the various Makefile.am.
>> I am pretty sure that cmake can be setup in a similar way, so that we
>> have the complicated parts that need expert knowledge and are not changed
>> often, and the easy ones that can be changed by everybody.
> 
> Sort of. The comparable ones are m4 macros and macros in the
> development/cmake/modules directory. But I do not see cmake-analogy to
> Makefile.am files.

I thought those were the CMakeLists.txt files in the individual directories? 
The purpose of Makefile.am is to define what gets built, packaged and 
installed in that directory in a way as simple as possible. I had the 
impression that the purpose of CMakeLists.txt is the same. If it is not 
possible to set up cmake in a way that the average developer needs to know 
as little cmake stuff as he currently needs to know from autotools, then 
this would be a big disadvantage.

>> I would suggest to make a comparison table of build system features
>> in the wiki, and everybody adds the ones he needs. Then we can see which
>> build system supports which feature, and how much work it would be to
>> implement the mising ones in cmake.
> 
> +1

I started a quite incomplete table at http://wiki.lyx.org/Devel/BuildSystems 
with some options I used. I would invite everybody to contribute to make it 
complete. The only question is whether we should continue it in the wiki or 
in Development.lyx. I would prefer the latter, since it is easier to edit 
and you get better visual feedback, but of course this would make 
contributions from non-developers more hard.

>> One thing I noticed recently is the
>> version suffix: Which autotools you can use an arbitrary one, with cmake
>> you can only toggle between a predefined one or none at all, which is a
>> problem if you want to compare two different builds of the same version
>> with separate configurations (e.g. qt4/qt5 or different compiler
>> settings).
> 
> I never had problems with this. Each build with different settings can
> have its own build-dir, so the comparison is trivial. I am doing it this
> way. So for example my build dir for lyx using gcc5.3 with qt5.6 is
> '/usr/BUILD/BuildLyxGitQt5.6main-gcc5.3'
> 
> We don't need to install first.
> 
> But it is also easy to change the boolean selecting suffix to be a string.

IMHO it is needed. Sometimes you want to install and cannot use the build 
dir only. For example, Liviu would need to rename his .deb packages if we 
would switch to cmake right now, and this would be cumbersome for the users.


Georg

Re: One official build system?

[Georg Baum]

Scott Kostyshak wrote:

> On Sat, Jun 04, 2016 at 07:55:28PM +0200, Stephan Witt wrote:
>> 
>> > Am 04.06.2016 um 10:15 schrieb Liviu Andronic :
>> > 
>> > If moving to cmake definitively would imply losing version suffix
>> > functionality, this would be a big issue for my packaging arrangements
>> > for Ubuntu builds.
>> 
>> +1
>> 
>> On Mac the version suffix is essential too.
> 
> I just want to make sure you saw Kornel's reply to that. I don't know if
> it addresses your needs or not.

IMHO it does. Livius builds could be done using their current names if the 
boolean switch is replaced by a string version, which is easy to do as 
Kornel wrote.

>> I just tried to build a Mac application with cmake and failed.
> 
> What was the error?
> 
>> It looks like a lot of work or to learn to make this working.
> 
> This might be a reason to stop this discussion here. You already do a
> huge favor by taking care of the Mac builds. It would not make sense to
> make it more difficult. I was hoping that in the long-run it would
> actually be easier for you, but perhaps the transition would be too
> frustrating and time-consuming.

We should not yet stop the discussion. We need more information about the 
problems.


Georg

Re: One official build system?

[Kornel Benko]

Am Samstag, 4. Juni 2016 um 15:36:37, schrieb Scott Kostyshak 
> On Fri, Jun 03, 2016 at 03:40:59PM -0700, Pavel Sanda wrote:
> > Scott Kostyshak wrote:
> > > I'm still not sure what the implications of moving to CMake as our
> > > official build system are (I should have made this more clear in my
> > 
> > To start with: If you make tarball with autotools and cmake is there
> > difference between those two, do we get the same files/and their contets?
> 
> Good question. I don't know. There is no 'lyxdist' target for CMake and
> no 'dist' target so I stopped there.

# make package_source
--> LyX-2.3.tar.xz
or
# make git_archive
--> LyX-2.3.0-47674git-Linux.tgz

> By the way, I saw your comment just above the definition of the lyxdist
> target, which you introduced in 2010 (d407a15c):
> 
> 
> #Wait some time for bumping automake 1.11, which can use dist-xz
> #directly without this code, which is to be removed.
> #xz has low compression by default, but can be affected via
> #export XZ_OPT=-9ev put somewhere in the makefile.
> lyxdist: dist
>   bunzip2 $(PACKAGE)-$(VERSION).tar.bz2
>   xz -9 $(PACKAGE)-$(VERSION).tar
>   ls -hl $(PACKAGE)-$(VERSION).tar.*
> 
> 
> Should we use dist-xz directly now?
> 
> Scott

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Scott Kostyshak]

On Fri, Jun 03, 2016 at 03:40:59PM -0700, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > I'm still not sure what the implications of moving to CMake as our
> > official build system are (I should have made this more clear in my
> 
> To start with: If you make tarball with autotools and cmake is there
> difference between those two, do we get the same files/and their contets?

Good question. I don't know. There is no 'lyxdist' target for CMake and
no 'dist' target so I stopped there.

By the way, I saw your comment just above the definition of the lyxdist
target, which you introduced in 2010 (d407a15c):


#Wait some time for bumping automake 1.11, which can use dist-xz
#directly without this code, which is to be removed.
#xz has low compression by default, but can be affected via
#export XZ_OPT=-9ev put somewhere in the makefile.
lyxdist: dist
bunzip2 $(PACKAGE)-$(VERSION).tar.bz2
xz -9 $(PACKAGE)-$(VERSION).tar
ls -hl $(PACKAGE)-$(VERSION).tar.*


Should we use dist-xz directly now?

Scott


signature.asc
Description: PGP signature

Re: One official build system?

[Scott Kostyshak]

On Sat, Jun 04, 2016 at 07:55:28PM +0200, Stephan Witt wrote:
> 
> > Am 04.06.2016 um 10:15 schrieb Liviu Andronic :
> > 
> > On Sat, Jun 4, 2016 at 9:55 AM, Georg Baum
> >  wrote:
> >> One thing I noticed recently is the
> >> version suffix: Which autotools you can use an arbitrary one, with cmake 
> >> you
> >> can only toggle between a predefined one or none at all, which is a problem
> >> if you want to compare two different builds of the same version with
> >> separate configurations (e.g. qt4/qt5 or different compiler settings).
> >> 
> > If moving to cmake definitively would imply losing version suffix
> > functionality, this would be a big issue for my packaging arrangements
> > for Ubuntu builds.
> 
> +1
> 
> On Mac the version suffix is essential too.

I just want to make sure you saw Kornel's reply to that. I don't know if
it addresses your needs or not.

> I just tried to build a Mac application with cmake and failed.

What was the error?

> It looks like a lot of work or to learn to make this working.

This might be a reason to stop this discussion here. You already do a
huge favor by taking care of the Mac builds. It would not make sense to
make it more difficult. I was hoping that in the long-run it would
actually be easier for you, but perhaps the transition would be too
frustrating and time-consuming.

Scott


signature.asc
Description: PGP signature

Re: One official build system?

[Stephan Witt]

> Am 04.06.2016 um 10:15 schrieb Liviu Andronic :
> 
> On Sat, Jun 4, 2016 at 9:55 AM, Georg Baum
>  wrote:
>> One thing I noticed recently is the
>> version suffix: Which autotools you can use an arbitrary one, with cmake you
>> can only toggle between a predefined one or none at all, which is a problem
>> if you want to compare two different builds of the same version with
>> separate configurations (e.g. qt4/qt5 or different compiler settings).
>> 
> If moving to cmake definitively would imply losing version suffix
> functionality, this would be a big issue for my packaging arrangements
> for Ubuntu builds.

+1

On Mac the version suffix is essential too.

I just tried to build a Mac application with cmake and failed.
It looks like a lot of work or to learn to make this working.

Stephan

Re: One official build system?

[Abdelrazak Younes]

On 04/06/2016 10:18, Georg Baum wrote:

Abdelrazak Younes wrote:


Hi Guys,

Funny to discover that the same discussion is coming back every couple
of years :-)

I am not surprised at all, maintaining two build systems with such a small
amount of developers is simply stupid.


I agree.


The main disadvantage of GLOB is that it can mess up your build if you
let in the source tree some files that was renamed for debugging or
development purpose. Personally I never do that because git branching
and stashing are so good that it is much simpler to use git instead of
manual renaming; but I can fully understand that you are not comfortable
with that.
For renaming files or adding new files I would prefer to handle that
completely in git as well. However, it does not work. If I add a new file
and then stash the changed away, git adds the new file to the stash, but
does not delete the one in the local working tree, so when I pop from the
stash again I get a conflict. Therefore, I do not add new files to the
stash, and then I can easily move around.


In this case branching is the solution, not stashing indeed.




1) Switch to CMake now
2) Take advantage of GLOB to do the much needed file hierarchy cleanups
now (both folder hierarchy and file/class names)
3) Switch file listing mode without GLOB.

Switching to cmake first and some time later from GLOB to explicit file
listing would create a huge amount of work, since you would need to recreate
all file lists from scratch.


Creating a list with all files in the tree is very simple... You can 
even automate that with CMake I think.


Anyway, those are details I think, the important thing to decide is to 
switch or not.


Thanks,
Abdel.

Re: One official build system?

[Kornel Benko]

Am Samstag, 4. Juni 2016 um 10:15:03, schrieb Liviu Andronic 

> On Sat, Jun 4, 2016 at 9:55 AM, Georg Baum
>  wrote:
> > One thing I noticed recently is the
> > version suffix: Which autotools you can use an arbitrary one, with cmake you
> > can only toggle between a predefined one or none at all, which is a problem
> > if you want to compare two different builds of the same version with
> > separate configurations (e.g. qt4/qt5 or different compiler settings).
> >
> If moving to cmake definitively would imply losing version suffix
> functionality, this would be a big issue for my packaging arrangements
> for Ubuntu builds.
> 
> Right now I keep master and branch daily builds (as well as
> pre-releases) completely independent from stable LyX packages, which
> allows people to blissfully install both stable and bleeding edge
> versions on the same system, without worrying of corrupting their
> production environment. Losing this will probably imply that we can
> install only one build at a time on a given system, which will reduce
> the testing opportunities for bleeding edge code

This is really no problem at all.
I for one have installed
# dpkg -l | grep lyx
ii  lyx21   2.1.5-45097git  
amd64A WYSIWYM (What You See Is What You Mean) 
document processor
ii  lyx22   2.2.0-47529git  
amd64A WYSIWYM (What You See Is What You Mean) 
document processor
ii  lyx23   2.3.0-47674git  
amd64A WYSIWYM (What You See Is What You Mean) 
document processor

without any conflicts. All of them created by cpack (called automatically by 
cmake).
And changing the suffix handling is not hard, as I wrote in my answer to Georg.

> Liviu
> 
> 
> >
> >
> > Georg
> >

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Kornel Benko]

Am Samstag, 4. Juni 2016 um 09:55:10, schrieb Georg Baum 

> Richard Heck wrote:
> 
> > On 06/03/2016 04:28 PM, Scott Kostyshak wrote:
> >> On Fri, Jun 03, 2016 at 09:38:09PM +0200, Kornel Benko wrote:
> >>> Am Freitag, 3. Juni 2016 um 12:42:33, schrieb Richard Heck
> >>> 
>  I guess maybe there is a question worth discussing here about how many
>  of us understand cmake well enough to modify the build scripts when
>  that needs doing. My sense is that the answer is "one",
> >> I also think this is and important question.
> >>
> >>> In alphabetical order:
> >>> Georg
> >>> Peter
> >>> Scott
> >>> Vincent
> >> I do not know CMake well. I suppose I do know enough to make minor
> >> modifications. I've been learning from Kornel and would put more effort
> >> into it if we did decide to move to CMake for our official builds. But
> >> the point remains that at least in the short-run I think we would depend
> >> a lot on one or two developers that have a lot of CMake experience.
> > 
> > It may be then that things are better than it seemed. But Vincent isn't
> > really active nowadays, and I'd like to hear from Georg. From what I've
> > seen on the list, he hasn't always seemed completely comfortable,
> > either, though it's true he does post some patches to the cmake stuff,
> > and of course he can learn.
> 
> I do not really understand cmake. I am able to do very simple modifications 
> which are basically copy-paste, but I tried several times to understand the 
> cmake language and always failed. Each time I needed a non-trivial change I 
> had to ask Kornel.
> 
> However, this is not so important. With autotools we have only very few 
> people who understand the macro stuff in m4/, config/ and configure.ac, but 
> everybody is able to do his modifications to the various Makefile.am. I am 
> pretty sure that cmake can be setup in a similar way, so that we have the 
> complicated parts that need expert knowledge and are not changed often, and 
> the easy ones that can be changed by everybody.

Sort of. The comparable ones are m4 macros and macros in the 
development/cmake/modules directory.
But I do not see cmake-analogy to Makefile.am files.

> We cannot afford having two build systems, this is a waste of time. So for 
> me the question is not about the official build system, but about the only 
> one, and since autotools cannot generate MSVC files the only solution is to 
> use cmake (I know none widely used build wystem that is better than cmake).
> 
> 
> IIRC the known show stoppers for making cmake the default build system are 
> some missing features when building the release packages, and the GLOB 
> stuff.

I use GLOB mainly because it was so easy to get the list of files. Sure they 
can be created manually too.

> I would suggest to make a comparison table of build system features 
> in the wiki, and everybody adds the ones he needs. Then we can see which 
> build system supports which feature, and how much work it would be to 
> implement the mising ones in cmake.

+1

> One thing I noticed recently is the 
> version suffix: Which autotools you can use an arbitrary one, with cmake you 
> can only toggle between a predefined one or none at all, which is a problem 
> if you want to compare two different builds of the same version with 
> separate configurations (e.g. qt4/qt5 or different compiler settings).

I never had problems with this. Each build with different settings can have its 
own build-dir,
so the comparison is trivial. I am doing it this way.
So for example my build dir for lyx using gcc5.3 with qt5.6 is 
'/usr/BUILD/BuildLyxGitQt5.6main-gcc5.3'

We don't need to install first. 

But it is also easy to change the boolean selecting suffix to be a string.
 
> 
> Georg

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Georg Baum]

Abdelrazak Younes wrote:

> Hi Guys,
> 
> Funny to discover that the same discussion is coming back every couple
> of years :-)

I am not surprised at all, maintaining two build systems with such a small 
amount of developers is simply stupid.

> I think the only point to discuss is the GLOB functionality. AFAIR Georg
> and you are against it and I can understand why. The advantage of GLOB
> are: 1) You do not have to maintain the list of files
> 2) You can move and rename the files from one folder to the other very
> easily.

GLOB is independent from cmake, you could set up autotools in a similar way. 
It is simply a conincidence that those who like cmake also like GLOB.

> The main disadvantage of GLOB is that it can mess up your build if you
> let in the source tree some files that was renamed for debugging or
> development purpose. Personally I never do that because git branching
> and stashing are so good that it is much simpler to use git instead of
> manual renaming; but I can fully understand that you are not comfortable
> with that.

For renaming files or adding new files I would prefer to handle that 
completely in git as well. However, it does not work. If I add a new file 
and then stash the changed away, git adds the new file to the stash, but 
does not delete the one in the local working tree, so when I pop from the 
stash again I get a conflict. Therefore, I do not add new files to the 
stash, and then I can easily move around.

> 1) Switch to CMake now
> 2) Take advantage of GLOB to do the much needed file hierarchy cleanups
> now (both folder hierarchy and file/class names)
> 3) Switch file listing mode without GLOB.

Switching to cmake first and some time later from GLOB to explicit file 
listing would create a huge amount of work, since you would need to recreate 
all file lists from scratch. IMHO it would be much better to write a small 
script that extracts the file lists from autotools and creates the proper 
cmake files from that. Then some reorganization work can be done 
independently of the switch (and if you move files around with git it is not 
much more effort to adjust the file lists as well).


Georg

Re: One official build system?

[Liviu Andronic]

On Sat, Jun 4, 2016 at 9:55 AM, Georg Baum
 wrote:
> One thing I noticed recently is the
> version suffix: Which autotools you can use an arbitrary one, with cmake you
> can only toggle between a predefined one or none at all, which is a problem
> if you want to compare two different builds of the same version with
> separate configurations (e.g. qt4/qt5 or different compiler settings).
>
If moving to cmake definitively would imply losing version suffix
functionality, this would be a big issue for my packaging arrangements
for Ubuntu builds.

Right now I keep master and branch daily builds (as well as
pre-releases) completely independent from stable LyX packages, which
allows people to blissfully install both stable and bleeding edge
versions on the same system, without worrying of corrupting their
production environment. Losing this will probably imply that we can
install only one build at a time on a given system, which will reduce
the testing opportunities for bleeding edge code

Liviu


>
>
> Georg
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: One official build system?

[Georg Baum]

Richard Heck wrote:

> On 06/03/2016 04:28 PM, Scott Kostyshak wrote:
>> On Fri, Jun 03, 2016 at 09:38:09PM +0200, Kornel Benko wrote:
>>> Am Freitag, 3. Juni 2016 um 12:42:33, schrieb Richard Heck
>>> 
 I guess maybe there is a question worth discussing here about how many
 of us understand cmake well enough to modify the build scripts when
 that needs doing. My sense is that the answer is "one",
>> I also think this is and important question.
>>
>>> In alphabetical order:
>>> Georg
>>> Peter
>>> Scott
>>> Vincent
>> I do not know CMake well. I suppose I do know enough to make minor
>> modifications. I've been learning from Kornel and would put more effort
>> into it if we did decide to move to CMake for our official builds. But
>> the point remains that at least in the short-run I think we would depend
>> a lot on one or two developers that have a lot of CMake experience.
> 
> It may be then that things are better than it seemed. But Vincent isn't
> really active nowadays, and I'd like to hear from Georg. From what I've
> seen on the list, he hasn't always seemed completely comfortable,
> either, though it's true he does post some patches to the cmake stuff,
> and of course he can learn.

I do not really understand cmake. I am able to do very simple modifications 
which are basically copy-paste, but I tried several times to understand the 
cmake language and always failed. Each time I needed a non-trivial change I 
had to ask Kornel.

However, this is not so important. With autotools we have only very few 
people who understand the macro stuff in m4/, config/ and configure.ac, but 
everybody is able to do his modifications to the various Makefile.am. I am 
pretty sure that cmake can be setup in a similar way, so that we have the 
complicated parts that need expert knowledge and are not changed often, and 
the easy ones that can be changed by everybody.

We cannot afford having two build systems, this is a waste of time. So for 
me the question is not about the official build system, but about the only 
one, and since autotools cannot generate MSVC files the only solution is to 
use cmake (I know none widely used build wystem that is better than cmake).


IIRC the known show stoppers for making cmake the default build system are 
some missing features when building the release packages, and the GLOB 
stuff. I would suggest to make a comparison table of build system features 
in the wiki, and everybody adds the ones he needs. Then we can see which 
build system supports which feature, and how much work it would be to 
implement the mising ones in cmake. One thing I noticed recently is the 
version suffix: Which autotools you can use an arbitrary one, with cmake you 
can only toggle between a predefined one or none at all, which is a problem 
if you want to compare two different builds of the same version with 
separate configurations (e.g. qt4/qt5 or different compiler settings).



Georg

Re: One official build system?

[Abdelrazak Younes]

Hi Guys,

Funny to discover that the same discussion is coming back every couple 
of years :-)


On 03/06/2016 22:22, Jean-Marc Lasgouttes wrote:

Le 03/06/16 à 18:42, Richard Heck a écrit :

Same here. I am used to autotools, so I use it.


I have reservations about cmake, but I would have some against 
autotools if I was not used to it already. All I ask from cmake is 
that it does the right think (i.e. what we advise people to do) by 
default (both for release and developer versions)


That's very much up to you guys to tell cmake to do the right thing. I 
believe that Kornel has done a lot of work already to



without having to use variables in capital letters that hurt my fingers.


CMake commands can be used lower or upper case. I personally always use 
lower case.




For the rest, I trust that the problems will vanish with time.


I think the only point to discuss is the GLOB functionality. AFAIR Georg 
and you are against it and I can understand why. The advantage of GLOB are:

1) You do not have to maintain the list of files
2) You can move and rename the files from one folder to the other very 
easily.


The main disadvantage of GLOB is that it can mess up your build if you 
let in the source tree some files that was renamed for debugging or 
development purpose. Personally I never do that because git branching 
and stashing are so good that it is much simpler to use git instead of 
manual renaming; but I can fully understand that you are not comfortable 
with that. Another con against GLOB is that we cannot control what the 
user does and there are some chances that he mess up with his source 
tree; in the best case this would just break compilation; in the worst 
case this would introduce very subtle bugs. IMHO, even this


Here is my humble advice to you guys:

1) Switch to CMake now
2) Take advantage of GLOB to do the much needed file hierarchy cleanups 
now (both folder hierarchy and file/class names)

3) Switch file listing mode without GLOB.

Hope that helps,
Abdel.

PS: for 2) I can dig out a proposal I made quite some years ago if you 
are interested

Re: One official build system?

[Pavel Sanda]

Scott Kostyshak wrote:
> I'm still not sure what the implications of moving to CMake as our
> official build system are (I should have made this more clear in my

To start with: If you make tarball with autotools and cmake is there
difference between those two, do we get the same files/and their contets?

Pavel

Re: One official build system?

[Jessica Hamilton]

> The following email thread (3 years ago) suggests that we would like to
> move to one official build system in the long-run across all platforms,
> but that there were barriers to using CMake:
> http://marc.info/?i=kmrd28$e1k$1%20()%20ger%20!%20gmane%20!%20org
>
> Have those issues been resolved?
>
> Is the opinion among currently active LyX developers also that we would
> like to move to CMake as the official build system?
>
> Is CMake currently used for our official builds on Mac and Win?
>
> I don't know much about build systems and I don't have a strong opinion
> on this. I just start this conversation now because of:
>
> (1) the recent discussion about making the release process easier/faster
> (2) it seems like a conversation that should be had at the beginning of
> a major release cycle
>
> From what I understand, most developers on Linux use autotools. I can't
> tell if this is because that is what most developers have experience
> with or if it is because autotools has other advantages.

If there is a move to CMake, I recommend the use of the GNUInstallDirs
module <https://cmake.org/cmake/help/v3.4/module/GNUInstallDirs.html>.
This alleviates a lot of pain on platforms with "non-standard"
installation locations.

Re: One official build system?

[Richard Heck]

On 06/03/2016 04:28 PM, Scott Kostyshak wrote:
> On Fri, Jun 03, 2016 at 09:38:09PM +0200, Kornel Benko wrote:
>> Am Freitag, 3. Juni 2016 um 12:42:33, schrieb Richard Heck 
>>> I guess maybe there is a question worth discussing here about how many
>>> of us understand cmake well enough to modify the build scripts when that
>>> needs doing. My sense is that the answer is "one",
> I also think this is and important question.
>
>> In alphabetical order:
>> Georg
>> Peter
>> Scott
>> Vincent
> I do not know CMake well. I suppose I do know enough to make minor
> modifications. I've been learning from Kornel and would put more effort
> into it if we did decide to move to CMake for our official builds. But
> the point remains that at least in the short-run I think we would depend
> a lot on one or two developers that have a lot of CMake experience.

It may be then that things are better than it seemed. But Vincent isn't
really active nowadays, and I'd like to hear from Georg. From what I've
seen on the list, he hasn't always seemed completely comfortable,
either, though it's true he does post some patches to the cmake stuff,
and of course he can learn.

That said, it's possible this is actually better than with autotools.

Richard

Re: One official build system?

[Scott Kostyshak]

On Fri, Jun 03, 2016 at 09:38:09PM +0200, Kornel Benko wrote:
> Am Freitag, 3. Juni 2016 um 12:42:33, schrieb Richard Heck 
> > On 06/03/2016 11:37 AM, José Abílio Matos wrote:
> > > On Friday, June 3, 2016 1:16:04 AM WEST Scott Kostyshak wrote:
> > >> From what I understand, most developers on Linux use autotools. I can't
> > >> tell if this is because that is what most developers have experience
> > >> with or if it is because autotools has other advantages.
> > >>
> > >> Scott
> > > In my case I use autotools by default because that it is what I am used 
> > > to. I do not have any particular attachment to autotools (or cmake).
> > 
> > Same here. I am used to autotools, so I use it.
> > 
> > I guess maybe there is a question worth discussing here about how many
> > of us understand cmake well enough to modify the build scripts when that
> > needs doing. My sense is that the answer is "one",

I also think this is and important question.

> 
> In alphabetical order:
> Georg
> Peter
> Scott
> Vincent

I do not know CMake well. I suppose I do know enough to make minor
modifications. I've been learning from Kornel and would put more effort
into it if we did decide to move to CMake for our official builds. But
the point remains that at least in the short-run I think we would depend
a lot on one or two developers that have a lot of CMake experience.

I'm still not sure what the implications of moving to CMake as our
official build system are (I should have made this more clear in my
initial email). I just wonder if it can help with making the release
process easier.

Scott

> > whereas at least two people (JMarc and Georg, maybe others) can do
> > this for autotools.
> > 
> > Richard
> 
>   Kornel




signature.asc
Description: PGP signature

Re: One official build system?

[Jean-Marc Lasgouttes]

Le 03/06/16 à 18:42, Richard Heck a écrit :

Same here. I am used to autotools, so I use it.


I have reservations about cmake, but I would have some against autotools 
if I was not used to it already. All I ask from cmake is that it does 
the right think (i.e. what we advise people to do) by default (both for 
release and developer versions) without having to use variables in 
capital letters that hurt my fingers.


For the rest, I trust that the problems will vanish with time.

JMarc

Re: One official build system?

[Scott Kostyshak]

On Fri, Jun 03, 2016 at 09:34:15AM -0600, Joel Kulesza wrote:
> On Fri, Jun 3, 2016 at 9:11 AM, Guillaume Munch  wrote:
> 
> >
> > What are the
> > advantages? What are the basic commands? How do you set up
> > out-of-directory builds?
> >
> >
> I am far from an expert; however, a self-contained and somewhat compact
> application of CMake is available here:
> https://github.com/jkulesza/NERS590_Project.
> 
> The basic commands are in the src/CMakeLists.txt file (which are almost
> certainly *not* following best practices, but they and their simplicity
> have served me well).
> 
> A simple script to drive out-of-source builds is shown in build/.
> 
> Advantages I might identify, without attempting to articulate further: it
> automates the Makefile generation process removing much of the manual labor
> (particularly as source files are added/removed).  In principle, it can
> also find compilers/libraries on the system quite readily and can be set up
> to flexibly use them in various combinations.  With various targets, it can
> also be setup to build release, debug, etc. for (straightforward) use with
> continuous-integration testing.
> 
> P.S. I hope you don't mind me chiming in...

Not at all, Joel! Please chime away. Any help is appreciated.

Guillaume, I didn't look in depth at the above, but if you have any
question, please ask. I usually just ask Kornel and he is happy to help.
I'm not sure it is worth your time though, unless we do decide to make
it our official build system. It is not clear yet we want that.

Scott


signature.asc
Description: PGP signature

Re: One official build system?

[Kornel Benko]

Am Freitag, 3. Juni 2016 um 12:42:33, schrieb Richard Heck 
> On 06/03/2016 11:37 AM, José Abílio Matos wrote:
> > On Friday, June 3, 2016 1:16:04 AM WEST Scott Kostyshak wrote:
> >> From what I understand, most developers on Linux use autotools. I can't
> >> tell if this is because that is what most developers have experience
> >> with or if it is because autotools has other advantages.
> >>
> >> Scott
> > In my case I use autotools by default because that it is what I am used to. 
> > I do not have any particular attachment to autotools (or cmake).
> 
> Same here. I am used to autotools, so I use it.
> 
> I guess maybe there is a question worth discussing here about how many
> of us understand cmake well enough to modify the build scripts when that
> needs doing. My sense is that the answer is "one",

In alphabetical order:
Georg
Peter
Scott
Vincent

> whereas at least two
> people (JMarc and Georg, maybe others) can do this for autotools.
> 
> Richard

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Richard Heck]

On 06/03/2016 11:37 AM, José Abílio Matos wrote:
> On Friday, June 3, 2016 1:16:04 AM WEST Scott Kostyshak wrote:
>> From what I understand, most developers on Linux use autotools. I can't
>> tell if this is because that is what most developers have experience
>> with or if it is because autotools has other advantages.
>>
>> Scott
> In my case I use autotools by default because that it is what I am used to. I 
> do not have any particular attachment to autotools (or cmake).

Same here. I am used to autotools, so I use it.

I guess maybe there is a question worth discussing here about how many
of us understand cmake well enough to modify the build scripts when that
needs doing. My sense is that the answer is "one", whereas at least two
people (JMarc and Georg, maybe others) can do this for autotools.

Richard

Re: One official build system?

[José Abílio Matos]

On Friday, June 3, 2016 1:16:04 AM WEST Scott Kostyshak wrote:
> From what I understand, most developers on Linux use autotools. I can't
> tell if this is because that is what most developers have experience
> with or if it is because autotools has other advantages.
> 
> Scott

In my case I use autotools by default because that it is what I am used to.
I do not have any particular attachment to autotools (or cmake).

With my Fedora hat on (pun intended) it does not matter which one is used to 
build, both are well supported in Fedora.

Regards,
-- 
José Abílio

Re: One official build system?

[Joel Kulesza]

On Fri, Jun 3, 2016 at 9:11 AM, Guillaume Munch  wrote:

>
> What are the
> advantages? What are the basic commands? How do you set up
> out-of-directory builds?
>
>
I am far from an expert; however, a self-contained and somewhat compact
application of CMake is available here:
https://github.com/jkulesza/NERS590_Project.

The basic commands are in the src/CMakeLists.txt file (which are almost
certainly *not* following best practices, but they and their simplicity
have served me well).

A simple script to drive out-of-source builds is shown in build/.

Advantages I might identify, without attempting to articulate further: it
automates the Makefile generation process removing much of the manual labor
(particularly as source files are added/removed).  In principle, it can
also find compilers/libraries on the system quite readily and can be set up
to flexibly use them in various combinations.  With various targets, it can
also be setup to build release, debug, etc. for (straightforward) use with
continuous-integration testing.

P.S. I hope you don't mind me chiming in...

Re: One official build system?

[Guillaume Munch]

Le 03/06/2016 06:16, Scott Kostyshak a écrit :

Dear all,

The following email thread (3 years ago) suggests that we would like to
move to one official build system in the long-run across all platforms,
but that there were barriers to using CMake:
http://marc.info/?i=kmrd28$e1k$1%20()%20ger%20!%20gmane%20!%20org

Have those issues been resolved?

Is the opinion among currently active LyX developers also that we would
like to move to CMake as the official build system?

Is CMake currently used for our official builds on Mac and Win?

I don't know much about build systems and I don't have a strong opinion
on this. I just start this conversation now because of:

(1) the recent discussion about making the release process easier/faster
(2) it seems like a conversation that should be had at the beginning of
a major release cycle

 From what I understand, most developers on Linux use autotools. I can't
tell if this is because that is what most developers have experience
with or if it is because autotools has other advantages.

Scott



From my perspective it is mostly ignorance about CMake. I would be happy
to give it a try and do not mind if it was default. What are the
advantages? What are the basic commands? How do you set up
out-of-directory builds?

One official build system?

[Scott Kostyshak]

Dear all,

The following email thread (3 years ago) suggests that we would like to
move to one official build system in the long-run across all platforms,
but that there were barriers to using CMake:
http://marc.info/?i=kmrd28$e1k$1%20()%20ger%20!%20gmane%20!%20org

Have those issues been resolved?

Is the opinion among currently active LyX developers also that we would
like to move to CMake as the official build system?

Is CMake currently used for our official builds on Mac and Win?

I don't know much about build systems and I don't have a strong opinion
on this. I just start this conversation now because of:

(1) the recent discussion about making the release process easier/faster
(2) it seems like a conversation that should be had at the beginning of
a major release cycle

From what I understand, most developers on Linux use autotools. I can't
tell if this is because that is what most developers have experience
with or if it is because autotools has other advantages.

Scott


signature.asc
Description: PGP signature