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