[Development] Build system for Qt 6

[Oswald Buddenhagen]

On Wed, Oct 31, 2018 at 10:17:04AM -0400, Matthew Woehlke wrote:
> 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?
> 
qt jira tasks. ;)
for me they are the first hits on google ...

> > 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.
> 
for components, that seems unnecessary in principle. if there is
anything shared, that's rather naturally expressed by there typically
being a central sub-package which every other one depends on anyway
(say, qtcore).
for build variants you'd indeed get 100% redundancy with my concept,
but that really doesn't sound exceedingly problematic given that we're
talking about small auto-generated files.

> > 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)`.
>
i'd just aggregate by components: {qt.core, qt.gui} is the same as
{qt.{core, gui}}. not sure what qbs currently does internally ...

> 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?
> 
you can specify version constraints in the dependencies like e.g. debian
packages do.

> > 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.
> 
one can priorize certain property values, both inside the interface and
on the consumer side.

> > and not one interface to describe each architecture variant within a
> > multi-arch library.
>
> Actually, I'm not sure if this would work.
>

slicing interfaces would work just fine for mac, because it's possible
to use just one architecture slice at any given time. however, it would
be inefficient (more tool calls) and at some point one needs to join the
own build artifacts into a multi-arch binary again anyway.
of course, one could make the consuming system intelligent enough to
recognize that a group of interfaces refer to different slices of the
same binary, but that seems unnecessarily complex.

conversely, having "lumped" multi-arch interfaces works as well, because
that just represents the reality of the binaries. however, the interface
then actually needs to specify a list of contained architectures.