[Development] Notes on "Qt Build Systems" @ QtCon 2016

[Kevin Kofler]

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
> people)
> - 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 
projects.

> - (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).

        Kevin Kofler