[Development] Build system for Qt 6

[Oswald Buddenhagen]

On Wed, Oct 31, 2018 at 03:41:49PM -0400, Matthew Woehlke wrote:
> On 31/10/2018 14.26, Oswald Buddenhagen wrote:
> > On Wed, Oct 31, 2018 at 01:09:13PM -0400, Matthew Woehlke wrote:
> >> Again, how then does the consuming tool know which qt.core and which
> >> qt.gui are compatible with each other? How does it handle the case of
> >> finding a qt.core with no matching qt.gui?
> >
> > as i said below, by the sub-packages constraining their transitive
> > dependencies.
> 
> That is insufficient.
> 
no, it's not.

> A.X can be used by itself. A.Y also can be used by itself. However,
> mixing different versions of A.X and A.Y is an error.
> 
it's a rather contrived scenario that two components of a package
could be used truly independently (without a common dependency within
the package), yet still conflict between versions. anyway, let's go with
it.

> Even if you propose to solve this by having both A.X and A.Y depend on a
> "virtual" A.base target of the same version,
>
that's indeed one way to solve it.
another way are "anti-dependencies" like dpkg's Breaks: A.X != <myver>

> you still haven't explained how to make it so a consumer can find the
> correct version of A in the pathological scenario I outlined without a
> global dependency solver.
> 
no, instead i told you that your premise of needing a _global_ solver is
wrong.

> > that answer might be unnecessarily strict, though. if i build a
> > 3rd-party qt module and install it into /opt/myqt, it might be
> > compatible with the system qt in /usr. i want to be able to use that
> > additional qt module by depending on {qt.{core,gui,3rdpartymodule}}.
> 
> Well, then, don't make it part of the "Qt" package. I don't think you
> can have it both ways. (If it's a third-party module, why is it a first
> party component of the "Qt" package?)
> 
because users want to think in terms of namespaces, not packages. at
least i do. at least for modules that aren't part of "qt" but are hosted
on qt-project infrastructure. qtwebkit is an excellent example, and
qtwebengine will probably follow soon due to wanting release cycle
decoupling.

> >> I think you are suggesting that finding build requirements has to be
> >> done as a single, monolithic pass; i.e. a project must specify ALL of
> >> its requirements before ANY attempt is made to satisfy those
> >> requirements.
> >
> > but that's exactly what you do anyway with the syntax above, within the
> > scope of a single package.
> 
> Not quite. [...]
>
you just spent ~35 lines on ... showing that i'm right.
the TTA approach cannot possibly work without the atomic resolution
scope provided by the multi-component find_library() statement. and
given that constraint, it's absolutely irrelevant to the user what
happens behind the scenes.