[Development] Qt 6 buildsystem support requirements

[Thiago Macieira]

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