[Development] Notes on "Qt Build Systems" @ QtCon 2016
kevin.kofler at chello.at
Mon Sep 5 15:38:09 CEST 2016
Andrew Knight wrote:
> - (Tobias) Cmake is the "worst" system in Qt Creator because CMake
> doesn't give enough feedback to the IDE. We need first-class support for
> CMake in Qt Creator, though, so that is irrelevant to the discussion of
> which system we use to build Qt.
Anything you can get into CMake to improve IDE support will also help
KDevelop, and vice-versa. KDevelop dropped their own CMake parser in
KDevelop 5 and now relies on the information CMake gives (using a dedicated
query mode that was added mainly for KDevelop), they know about things
missing there and want them added to CMake.
> * Quick survey: which build system do you use (raise of hands by ~40
> - CMake ~70%
> - qmake ~20%
> - Qbs ~10%
That basically says it all. :-)
> - (Milian) CMakeis used by e.g. clang and it works for them
… and the whole stack of software from the KDE project, and other large
> - (Eddy) Why are we using this ancient tool? (Referring to make)
You don't have to use make with CMake, CMake has other generator backends,
e.g., a Ninja generator. And the really nice thing is, the developer of the
application or library (Qt in this case) normally does not have to do
anything to support them, it should just work (and make will still just
work, too, for those who prefer using make).
> - (Andreas) "Every big project ends up building their own system. Qbs is
> a possibility to create a new build system. If it stays in the Qt
> Project, less people will use it."
The fact that many big projects (thankfully not all of them) reinvent their
own square wheel is a bad thing, not something worth copying. This is a
major annoyance when packaging.
That said, what I have also seen in some projects is strange wrapper layers
above CMake, with things like:
* custom Find* files that work differently from the standard ones,
* custom macros that do everything instead of standard commands,
* undocumented hacked-on support for bundled libraries (with custom macros
and custom Find* files) that makes it hard to unbundle them,
* lack of support for important standard CMake variables, e.g., some broken
CMakeLists setups use neither LIB_INSTALL_DIR nor LIB_SUFFIX.
So using CMake is not always enough to avoid being a pain to package.
But an entirely custom build system is always the worst. I don't see why one
would need to do different just for the sake of doing different, it just
makes us packagers' jobs harder (see e.g. Chromium's gyp and/or gn).
More information about the Development