[Development] Qt 6 buildsystem support requirements
thiago.macieira at intel.com
Tue Jul 31 19:49:49 CEST 2018
On Tuesday, 31 July 2018 09:35:42 PDT Lisandro Damián Nicanor Pérez Meyer
> > 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,
- 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
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
More information about the Development