[Development] Build system for Qt 6

[Christian Gagneraud]

On Wed, 31 Oct 2018 at 22:47, Christian Kandeler
<Christian.Kandeler at qt.io> wrote:
>
> On Wed, 31 Oct 2018 10:44:43 +1300
> Christian Gagneraud <chgans at gmail.com> wrote:
>
> > On Wed, 31 Oct 2018 at 10:27, Thiago Macieira <thiago.macieira at intel.com> wrote:
> > > On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote:
> > > The only thing I'm criticising is that its proper chance involves Qt being the
> > > guinea pig. Find someone else instead and grow your community. Get track
> > > record for building, cross-compiling, working with weird set ups,
> > > containerised build environments, build farms, etc. Don't ask Qt to switch to
> > > it until you've done that work.
> >
> > !?!
> > What make you think qbs cannot be used in such environments?That all
> > very basic stuff to me.
> > - cross-compiling: Qbs support *out of the box* all "standard" OS
> > *and* "standard" toolchains.
> > - working with weird set ups: what does that even mean? That a very
> > vague statement.
> > - containerised build: any build system can run in a container, that's
> > orthogonal.
> > - build farms: Against what is the problem with build farm, i don't get it.
> > - etc: again, can you elaborate? that's very vague.
> >
> > I've used Qbs to build a Desktop SW for Windows + MacOS + Linux, all
> > producing platform specific installers.
> > It was a breeze.
> > I've used it to build a 1.5 million SLOC SW, with complex build
> > matrix. The only reason we dropped it, was because of lack of
> > integration:
> > QtCreator is the only IDE that knows Qbs, as i reported on Qbs mailing
> > long time ago, Qbs won't take off without XCode, Visual Stidio, Visual
> > Code, Eclipse, ... integration.
> > And, so far, we failed at switching to CMake, the build matrix is too complex.
>
> So what *are* you using now? Just curious.

Drum roll..... vcxproj + python + qmake!
This is close to a 'hand crafted' build system, it is dirty, fragile,
but "it works" (tm).
The middle man, python, is where we have full freedom to do the dirty
tweaking job.
We even have python code that "fix" the generated Makefiles, when needed.
Absolutely nobody likes this solution, it is heinous,  but it is the
only one that fulfill all our requirements.
With enough energy, i'm sure this whole thing could be switched to
Qbs, CMake or even qmake.
But I do believe that Qbs would be the cleanest solution.
Now, of these 3 build systems, CMake is the only one that is supported
by Visual Studio (I was told), and although i do not use it, this is
the most common IDE here.

We do hundreds of builds per days, for ca. 15 different build
configurations, and we do that in containers, in a build farm.
We're even experimenting with Windows native containers, and
off-loading our local build farm in the cloud.
We build the whole custom embedded Linux OS as well, a bunch of
in-house shell scripts that have to deal with at least the most common
build systems.
We have tera-bytes of artifacts every day. We generate firmwares for
at least 50 commercial products, every day.
Yes it's not an easy job, and CMake vs qmake vs Qbs doesn't influence
the number of issue we have to face.

Hence my criticism toward Thiago's requirements and arguments. I don't
buy a single line of what he said in this thread.

Last but not least, everyone maintaining a Embedded Linux Distro have
to maintain a set of patches to work around buggy source package build
system, and this includes Qt, see for example:
https://github.com/meta-qt5/meta-qt5/tree/master/recipes-qt/qt5/qtbase
See as well debian/patches in, eg
http://http.debian.net/debian/pool/main/q/qtbase-opensource-src/qtbase-opensource-src_5.3.2+dfsg-4+deb8u2.debian.tar.xz

Whatever the build system you use, your users will have to work it
around and deal with it.

Chris