The build system

Build features

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.

⚠️ Some configuration options, such as 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.

Things done the CMake way

• 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, uic and rcc)
• CMAKE_UNITY_BUILD - source files are excluded from unity builds when they cannot be build with that option enabled

Things not done the CMake way

• KATIE_TYPE - because SHARED and STATIC builds 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. - because GNUInstallDirs is 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, uic and rcc) instead fo relying on CMake to handle RPATH properly 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

Custom CMake modules

• All custom CMake modules support <PACKAGE>DIR environmental variable which if pointing to a directory with include/<package_header>.<suffix> and lib/<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.

Compatibility with CMake's Qt4 module 🎱

• 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 of QT_DEFINITIONS (for CMake) or Cflags (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

Build options sugar 🍬

• KATIE_UNIFDEF is option used as the path to unifdef executable
• KATIE_SHELL is option used as shebang for Shell scripts (profile-<arch>.sh, exec.sh, dbus.sh, xvfb.sh and dbg.sh)
• KATIE_UTILS is option to build utilities required for maintaining the toolkit
• KATIE_TOOLS_SUFFIX is 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, Devel and Doc. Each component has respective installation target, e.g install-runtime for the Runtime component

Things CMake does not get right 🐛

• 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 sequentual foreach() does not loop the same way the first foreach() did over the entries in the list
• CMAKE_<LANG>_STANDARD has no effect on try_compile()
• due to CMAKE_VISIBILITY_INLINES_HIDDEN in 2.8.12.x and maybe even newer releases -fvisibility-inlines-hidden may 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 via extern keyword, it also fails for functions (such as pthread_setname_np) which may do unusual things when called
• MinSizeRel type build with LLVM linker (which is default on current stable releases of FreeBSD) is not supported on older versions