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

[Konstantin Tokarev]

05.09.2016, 16:38, "Kevin Kofler" <kevin.kofler at chello.at>:
> 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.

Problem is that square wheel here is CMake. IMNSHO, it doesn't do _anything_ better than competition and it's only workable because of lots and lots of man-hours of pain and suffering, invested in its extension modules.

>
> 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
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin