[Development] Qt 6 buildsystem support requirements

Jason Newton nevion at gmail.com
Sun Jul 22 14:58:26 CEST 2018


On Sun, Jul 22, 2018 at 3:11 AM Kevin Kofler <kevin.kofler at chello.at> wrote:
>
> Jason Newton wrote:
> > My conclusion for the build system with the brightest future is bazel
>
> Looking at this, this build system depends on Python AND Java! They ship
> binaries with everything bundled, but that is a huge bloat (and it also does
> not help GNU/Linux distributions, which will want to use the system versions
> of the languages).

Yeah, I think java is the only actual curve ball in there but OpenJDK
works just fine and seemingly all they care to use.  I think your main
concern as bloat would likely be around ~200 or so megabytes of disk
space used on linux platforms for your distro to pull that in, in
development capable machines (which would pull in copious amounts of
devel packages + doc).  Python is in most distributions, and I'm
hesitant to say integral but it frequently seems installed by default,
often relating to package management, and I believe they use the
system install for python one all the time.  In practice I really have
to question how much this matters as hard drive space is so cheap and
this really is a maximum of a few hundred megabytes, and they offer
builds with it built-in to the binary image to free the user from
having to install it.  Inline history lesson - I believe they started
in python or jython and the GIL or performance caused enough grief
getting things fast/scalable so they rewrote the runtime to address
these and ended up with a python-like interpreter in java.  Also the
goto language for things that aren't bazel but are a script are either
shell or python, not sure how well they explicitly spell this out but
that is how it is.

>
> I think a build system should have minimal dependencies, and ideally be
> written in C++ as Qt itself is. If you require more stuff to build the build
> system than to build Qt, something is clearly wrong.
>
> > -Time tested, running in production environments
>
> Bazel is still fairly new and adoption is low, especially in the Free
> Software world. It is being mostly adopted by "hip" projects rather than the
> well-known Free Software projects. In particular, it is not widely used in
> the Qt community. Compare:
> https://github.com/bazelbuild/bazel/wiki/Bazel-Users
> vs.:
> https://cmake.org/ ("Notable Applications Using CMake" section).
>
> There is also little to no documentation on packaging Bazel-using software
> for GNU/Linux distributions. E.g., the Fedora wiki does not contain a single
> reference to Bazel. (The only 2 results I get with a full-text search are
> about a person with that surname.)

Fairly new is interesting in this case because it's core is blaze, and
that's not new -  two other build systems were built trying to copy
it.  It is a weird case and even towards your later mentioning of
their self declaration of beta, I think it bears in mentioning google
considers that term differently (google maps, google mail anyone?).
However I know they're rewriting c++ code paths under the hood - if
you look at build rules though, you'll see not alot is changing there
- I've used it for ~ 1 year and I haven't experienced breakage in this
way yet, but I would expect it soon as a part of that process - keep
in mind we're looking at a long term shift though, not short term.
Also have to point out cmake 2->3 was not painless and as usual
projects tend stick to a supported range if and when things break and
address it with point releases if possible.  Can't deny incompatible
changes wouldn't come up but I think that's possible for just about
any of the options out there.

Not quite sure about what the last section is about - distro-made
binaries for bazel?  I don't think it's generally on their radar (yet)
-  There are these pages:
https://docs.bazel.build/versions/master/install-redhat.html for the
centralized install guides.  If you want to build it, you'll need to
boot-strap it with a prebuilt binary, but building the executable, tar
 archives, rpms and debs are all supported - building them oneself is
fairly trivial and here is the file of interest in terms of targets:
https://github.com/bazelbuild/bazel/blob/master/scripts/packages/BUILD
, and owning directory contents.  Documentation could be better
though, but that comes with distros being made more aware of it, which
is often a community based thing, or popularity and in terms of
distros acknowledging bazel, yes, I don't think there are any.

>
> > -Ability to build external libraries from source or pull in binary
> > libraries - the former offering alot of power that comes with custom
> > flags and controlled dependencies for users developing products, and
> > the later for distribution like software - the choice is always there
> > and low barrier of entry.  One can fuse approaches where it makes
> > sense.
>
> GNU/Linux distributions actually want to link against the system libraries,
> not pull in binaries (nor library sources) into the package.

What I'm saying is you get both and you want to flesh out both, qt
actually is caught in the middle of this (precompiled SDK in
particular) of packages in c/c++ becoming a thing (see conan, jfrog) -
will they have success? I don't know, people desire pip/npm like
capabilities to get libraries close to language, distro agnostic and
it's something even the standards folk are poked with.  By the way,
both of those projects are foremost in cmake.  Hodgpodge of sources
built JIT and precompiled.  Multiple hats and installation types have
to be considered ontop of platforms/architectures, in particular since
Qt tries to work both with FOSS and proprietary software customers.
Also as a python user I frequently felt alot of pain trying to work on
distributions that want to replace pip (poorly), but anaconda rocks
because it is the eject button on when distros can't deal with
dependencies as the developers/users/scientists need to - I bring this
up because of pip, and the qt installation independent of distro,

I think some of the other points I read earlier, for anaconda related
packaging, could be related to third parties not themselves offering -
I am interesting in hearing about this, maybe in a more private space
@Ray Donnelly .

.

>
>         Kevin Kofler
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



More information about the Development mailing list