<< | Page list | >>
LyX Build Systems
1. LyX Build Systems
To make an educated guess on what might be the best build system for LyX
we try to collect some facts on this page
1.1 Implemented features
Rate 0 (non-exitent) ... 5 (full support). Try not to use personal biased
numbers but what you think a good consensus might look like. If you strongly
oppose a certain rating, add an extra line and mark it as your personal
opinion)
autotools scons cmake qmake
[A] detection of
external 5 4 3 0
dependencies
[B] create .rpm 5 0
[C] create .tar.gz 5
[D] create .vcproj 0 2 5 5
[E] create window 0 5 0
package
[F] completeness
[G] simplicity of 2 5 3 1
language for extensions
[H] PCH support 0.8* 0 0.8*
[I] Reliability high higher
[J} Supported *nix,mac, windows, *nix mac,win/vc **
platforms mingw,cygwin (vc,mingw,cygwin)
...
* not reliable.
** other platforms are supposed to be supported
1.2 Measured performance (ratio to autotools, high numbers bad)
autotools scons cmake qmake
[11] Empty build 1.0 1.0* 0.5 ?
(release mode)
[12] Change one file 1.0 1.1/0.7** 0.35 ?
(release mode)
[13] Full build 1.0 ? ? ?
(release mode)
[21] Empty build 1.0 ? ? ?
(debug mode)
[22] Change one file 1.0 ? ? ?
(debug mode)
[23] Full build 1.0 0.51 ? ?
(debug mode, single thread, linux)
[24] Full build 1.0 0.52
(parallel, 6 threads, linux)
* scons --implicit-deps-unchanged / make = 1.04. scons / make = 1.46. The former uses
stored dependency, comparable to what make does.
** My test, adding an empty line to src/Buffer.cpp, yields scons/make = 0.69.
1.3 Weighting of items (numbers in a column should sum up to 100)
developer1 developer2 developer3
[A]
[11]
[12]
[13]
[21]
[22]
[23]
1.4 Opinions
Abdel:
These are the very reason why I think CMake is superior:
- XCode project for Mac
- KDevelop project for KDE
- GNU Makefiles for gcc
- MSVC project for MSVC.
I only seldomly go to the command line to type CMake. With scons (and
autotools) I had to do that all the time, which forced me to reload the
project every time...
Bo:
> I chose scons for a lot of reasons, such as flexibility, platform
> independence. I have doubt in cmake's approach because I am not sure
> if cmake can achieve what we want. Conceptually, I am wondering:
>
> 1. Who is handling Package.cpp.in ==> Package.cpp? If cmake does it,
> then the generated vcproject or xcode stuff can not detect changes in
> Package.cpp.in. If cmakes gives this to make or vcproject, how can
> cmake make sure these tools can do something like this? If cmake has
> to re-generated a vcproject after such a change, why cmake is better
> than autogen.sh?
>
> 2. Along the same line, will cmake be able to do 'cmake install
> version_prefix=16', 'cmake install DESTDIR=destdir' in a platform
> independent way? If vcproject does not do installation, how would
> cmake do it, or trick vcproject do it?
>
> Overall, scons tries not to depend on another build system to achive
> maximum power, and I am not sure how cmake can achieve the same.
2. Commandline arguments for autotools and cmake
The following table compares commandline arguments of configure (autotools) and cmake. All autotools options of the form --enable-something have also a corresponding --disable-something, and all autotools options of the form --with-something have also a corresponding --without-something
configuration commandline arguments
Feature | autotools | cmake | comment |
compiler warnings | --enable-warnings |
custom C compiler flags | CXXFLAGS=-fmessage-length=0 |
custom preprocessor flags | CPPFLAGS=-fmessage-length=0 |
custom C compiler flags | CFLAGS=-fmessage-length=0 |
custom archiver | AS=x86_64-w64-mingw32-as |
custom assembler | AR=x86_64-w64-mingw32-ar |
custom assembler | AS=x86_64-w64-mingw32-as |
custom C compiler | CC=x86_64-w64-mingw32-gcc |
custom C compiler | CXX=x86_64-w64-mingw32-g |
custom objective C compiler | OBJC=x86_64-w64-mingw32-gcc | | In theory only needeed for OS X, but due to the implementation of autotools test also needed for cross compilation if an objc compiler for the host system is installed. |
custom archive indexer | RANLIB=x86_64-w64-mingw32-ranlib |
custom resource compiler | RC=x86_64-w64-mingw32-windres | | only needed for windows builds |
debug builds | --enable-debug |
C runtime library debug builds | --enable-stdlib-debug |
included boost | --with-included-boost |
included iconv | --with-included-iconv |
included hunspell | --with-included-hunspell |
included mythes | --with-included-mythes |
included zlib | --with-included-zlib |
installation prefix | --prefix=/opt/lyx |
qt version | --enable-qt5 | -DLYX_USE_QT=QT5 |
C standard | --enable-cxx11 | -DLYX_ENABLE_CXX11=ON |
compiler optimization | enable-optimization=-O2 |
version suffix | --with-version-suffix=-2.3 | -DLYX_PROGRAM_SUFFIX=ON | autotools allows arbitrary string, cmake a fixed value tat can be switched on and off |
verbose compiler output | --disable-silent-rules |
monolithic build | --enable-monolithic-build[=LIST] | -DLYX_MERGE_FILES=ON | autotools allows a list of modules, don't know if this is important |
cross compilation | --host=x86_64-pc-mingw64 | | this is an example for 64bit mingw, it can be any string as long as you have a correspoding cross compiler in the path |
create GUI application | | -DLYX_CONSOLE=ON | only for windows |
3. Links
Related discussion threads:
4. Categories
Category: Development, LyX_1_6 LyX_2_3