Re: One official build system?
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 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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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: > @rpath/QtGui.framework/Versions/5/QtGui (No such file or directory) > > Call Sta
Re: One official build system?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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. Stephan
Re: One official build system?
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?
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?
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?
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?
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?
> 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?
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?
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?
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?
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?
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?
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?
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?
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?
> 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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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