05.09.2016, 16:38, "Kevin Kofler" <kevin.kof...@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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development