On Tuesday, 31 July 2018 09:35:42 PDT Lisandro Damián Nicanor Pérez Meyer wrote: > > I would say the only two options in the running are qbs and CMake. > > Just for curiosity I checked qbs' reverse dependencies (packages that > require qbs installed in order to be built) in Debian. We currently only > have two of them: qtcreator and dewalls (a library).
I know. That's why I am challenging the supporters of qbs to meet my requests in (2). To wit: a) Must be used by roughly a dozen packages in major distros. I'm not saying all of them have to have a dozen, not even that one of them has a dozen. But all of the ones listed above must have at least one and there must be a dozen distinct packages in total. b) At least one package must have been continuously packaged for two years. One for an RPM distro and one for a .deb distro. c) At least one package of comparable complexity to qtbase, packaged by the three of the six Linux distros I listed. I'm looking for: - compiling certain files with different compiler flags - several third-party dependencies, some required, others optional - lots of configure-time options - installing several different types of targets (binaries, libraries, plugins, arch-dependent files, arch-independent files, documentation, translations, etc.) - obeying distro-supplied options (compiler & linker flags, compiler selection [ccache, icecc, clang], debuginfo split, stripping, etc.) I know CMake meets these requirements, but it has other problems and the fact that it currently does not build Qt. On that front, qbs is ahead. But qbs has a shorter track record. Since we're not switching buildsystems in the next 2 years, there's time for the proponents of qbs to take actions to achieve those requirements above. In other words: get others to adopt the buildsystem before we switch Qt. Prove that it can support Qt. I know switching Qt would gain it a big critical mass, the same way that KDE switching to CMake in 2006 gave CMake an important boost [*]. But we're not switching Qt just yet, so if you're saying the tool is ready, get others to use it now. [*] I was there in Akademy 2005 when we decided to use Scons because CMake's language was too ugly. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
