The build system - fluxer/katie GitHub Wiki
There are many compile time options you can choose to opt-out from, simply pass the respective argument as CMake defined variable, e.g. cmake . -DQT_NO_<OPTION>=1. Do note that if requirements are not met for the options they may be automatically turned off, there are also compiler and architecture dependant options which also may be automatically turned off regardless of your preferences.
Besides those you can choose to opt-out from features that are platform dependant (e.g. getifaddrs), simply pass the respective argument as CMake defined variable, e.g. cmake . -DQT_HAVE_<feature>=FALSE. You can git grep QT_HAVE_ to find out what features are supported.
QT_NO_XMLSTREAM or QT_NO_MAINWINDOW, are essential for the tools. For example without main window support the qtconfig tool cannot operate, without QFontComboBox it cannot present font options to the user. Other configuration options, such as QT_NO_ICON and QT_NO_CURSOR, are essential for the UI generation tool uic. For example it may have to output code that relies on these classes if properties for them are set in the UI files. As such it is yet to be determined if they should be options.
-
WITH_<PACKAGE>- all optional dependencies can be enabled or disabled -
CMAKE_POSITION_INDEPENDENT_CODE- affects the project itself and other projects -
CMAKE_CROSSCOMPILING_EMULATOR- when cross-compiling it should be set to QEMU executable that will be used to run the tools during the build stage (moc,uicandrcc) -
CMAKE_UNITY_BUILD- source files are excluded from unity builds when they cannot be build with that option enabled
-
KATIE_TYPE- becauseSHAREDandSTATICbuilds cannot be performed from the same build directory (CMAKE_BINARY_DIR). It is similar to BUILD_SHARED_LIBS which is not mandatory -
KATIE_HEADERS_PATH,KATIE_LIBRARIES_PATH, etc. - becauseGNUInstallDirsis simply not enough, but a good base -
KATIE_TESTS- because automatic tests and benchmarks are build as tests -
KATIE_BENCHRMARKS- because automatic tests and benchmarks are build as tests - script is used to run the tools during the build stage (
moc,uicandrcc) instead fo relying on CMake to handleRPATHproperly and the host system to support it. Besides that, environment variables must be set to be able to run the tests without prior installation and some special cases must be handled carefully
- All custom CMake modules support
<PACKAGE>DIRenvironmental variable which if pointing to a directory withinclude/<package_header>.<suffix>andlib/<package_library>.<suffix>will be used instead of what CMake can find by default. This should rarely find use case but it may be useful when building ala Linux From Scratch two-pass builds - packages can be anywhere like in GoboLinux, Bedrock, etc. Or at least in theory. This should avoid the need to learn and remember about CMake module variables and overriding them via-DSQLITE_LIBRARIRIES="-L/home/joe/mysqlite -lmysqlite"and the like.
-
KATIE_COMPAT- imported targets,QT_<COMPONENT>_INCLUDES,QT4_<COMPONENT>_LIBRARY,QT4_<COMPONENT>_DEFINITIONS, etc. compat but macros from Qt4 modules are still used. If your build system makes use ofQT_DEFINITIONS(for CMake) orCflags(for Autotools, via pkg-config) all should be well since it includes feature definitions. - porting to Katie is not that hard tough, you may fix some issues in the process too
-
KATIE_UNIFDEFis option used as the path tounifdefexecutable -
KATIE_SHELLis option used as shebang for Shell scripts (profile-<arch>.sh,exec.sh,dbus.sh,xvfb.shanddbg.sh) -
KATIE_UTILSis option to build utilities required for maintaining the toolkit -
KATIE_TOOLS_SUFFIXis option to suffix the tools avoiding possible conflicts with other toolkits - all files that the project provides (headers, libraries, etc.) can be installed separately or as part of component, that includes
Runtime,Tools,DevelandDoc. Each component has respective installation target, e.ginstall-runtimefor theRuntimecomponent
- after list is being iterated over once in
foreach()it is mutated into string which breaks the Qt4 module compat mode in 3.4.x and some 3.5.x releases, a sequentualforeach()does not loop the same way the firstforeach()did over the entries in the list -
CMAKE_<LANG>_STANDARDhas no effect ontry_compile() - due to
CMAKE_VISIBILITY_INLINES_HIDDENin 2.8.12.x and maybe even newer releases-fvisibility-inlines-hiddenmay be passed to the C compiler which is not valid, some compilers reject it and fail but GCC is known to issue a warning and continue -
check_symbol_exists()cannot detect functions marked as external viaexternkeyword, it also fails for functions (such aspthread_setname_np) which may do unusual things when called -
MinSizeReltype build with LLVM linker (which is default on current stable releases of FreeBSD) is not supported on older versions