[Development] Build system for Qt 6

[Oswald Buddenhagen]

On Tue, Oct 30, 2018 at 05:06:44PM -0400, Matthew Woehlke wrote:
> On 30/10/2018 14.25, Oswald Buddenhagen wrote:
> > On Tue, Oct 30, 2018 at 01:46:49PM -0400, Matthew Woehlke wrote:
> >> In order to actually implement the ability to read CMake interface
> >> files (without corner cases), you basically have to *be* CMake.
> >> If you assume that you will only have to deal with some subset, you
> >> will be subject to breakage at any time.
> >
> > yes, but [...] the whole thing would be only a "bridge technology" 
> > anyway.
> 
> So why not jump straight to a better way of exchanging package
> information, and teach CMake to speak that? If you can produce such a
> system (which is exactly what CPS tries to do), I think CMake would be
> receptive. Why bother with an interim solution?
> 
i would be all for it. not sure the message "would you mind accepting
that patch? it's just a bit more maintenance work for you, and it would
make it easier for everyone else to break your quasi-monopoly and
ultimately make your tool obsolete ..." would be *that* easy to sell,
though. :D

> >> I would rather see CMake learn to read and output something more
> >> portable, e.g. CPS¹.
> >
> > from a quick glance, this isn't all that bad, and in fact reflects the
> > strongly declarative concepts i'm envisaging for qbs' interface files.
> 
> Thanks :-). I've tried to make it plausible and address both likely edge
> cases and some issues that CMake currently does not handle well, while
> keeping it reasonably simple. It's mostly lacking implementation, and I
> haven't had the time/ability to do a lot more than write up the schema.
> Help would be much appreciated!
> 
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.

one thing i noticed is that you multiplex build variants and other stuff
into a single file. this is not helpful for packaging. after much
thinking about the matter, i concluded that the interface files should
correspond to "atomic linkable entities", which essentially means actual
libraries - not one interface to describe all build variants, and not
one interface to describe each architecture variant within a multi-arch
library. any aggregation of (however) related interfaces should happen
on the consumer side (in as far as necessary at all). this is actually
closely related to QBS-995.