[Development] Build system for Qt 6

[Matthew Woehlke]

On 30/10/2018 17.51, Oswald Buddenhagen wrote:
> for starters just some food for thought:
> QBS-995 should be implementable on top of it.
> if you want to go full monty, QBS-942 is your target.

What are those? Can you provide links?

> one thing i noticed is that you multiplex build variants and other stuff
> into a single file. this is not helpful for packaging.

This is not entirely true; a single package specification *can* be split
into multiple units. (I'm not sure this is well documented, but it is
definitely intended. OTOH, while I'm pretty sure this is well supported
for separate *components*, I'm less sure about separate *configurations*
of the same component, so maybe there is room for improvement.)

There does need to be one package that owns the "root" specification,
but this is not so different from one package owning the top level
directory.

> after much
> thinking about the matter, i concluded that the interface files should
> correspond to "atomic linkable entities", which essentially means actual
> libraries

That's basically the pkg-config approach... and I believe that design to
be intractable. In short, it fails to specify how to do the equivalent
of `find_package(X COMPONENTS A B C)`. Especially if you have e.g.
(ignoring 'C' for simplicity):

  X.A-1.2
  X.A-1.0
  X.B-1.1
  X.B-1.0

You *have* to be able to do package-level queries; otherwise, how do you
know (assuming X-1.z are mutually incompatible, but the consumer can use
any X-1.z) to use X-1.0?

> not one interface to describe all build variants,

Aside from this isn't how lots of existing packages work, how would you
then architect the system to allow the user to both be able to choose
which build variant to use *or* to just pick one? Requiring the user to
know which variant they want is an anti-goal.

> and not one interface to describe each architecture variant within a
> multi-arch library.
Actually, I'm not sure if this would work. I won't swear that it won't
(I don't think I've ever really thought about it), but it wasn't a
design goal. The goal of having an arch specification is so that a
consumer can ignore packages that are built for an incompatible
architecture. (This is one of features that CMake is currently missing.)

IOW, the intent was for one package specification to have only a single
architecture. And at least CMake currently wouldn't support such
packages anyway. (At best, it would use the component's from the
consumer's arch and pretend the rest doesn't exist.)

-- 
Matthew