[Development] Build system for Qt 6

[Oswald Buddenhagen]

On Fri, Nov 02, 2018 at 11:59:39AM -0400, Matthew Woehlke wrote:
> On 01/11/2018 08.10, Oswald Buddenhagen wrote:
> > no, instead i told you that your premise of needing a _global_ solver is
> > wrong.
> 
> ...but you have failed to explain how dependency resolution will succeed
> in a scenario such as I have outlined.
> 
> Actually, I realize now there is a possible answer: it *doesn't*
> succeed. It finds A.X-1.2. Then it finds A.Y-1.1 which is incompatible,
> and gives up, forcing the user to manually correct the situation.
> 
i honestly don't understand what your problem is. the only difference
between the approaches is that you centralize the meta data, while i
distribute it. TTA works exactly the same way.

> > 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.
> 
> ...but having a separate release cycle is an excellent reason to *not*
> be the same package. And I'm not entirely convinced that users shouldn't
> be aware of that distinction, because it may well matter when they need
> to specify more fine-grained version requirements (i.e. '5.8' vs. '5').
> 
> For that matter, what happens to namespacing? Can I do this?
> 
>   find_package(Qt 5.8 COMPONENTS Core Gui)
>   find_package(Qt 2.1 COMPONENTS WebEngine)
> 
sure you can.

> Let's say we allow that... what then is Qt_FOUND? Qt_VERSION?
>
not relevant in the qbs model, because "package" isn't a thing there -
that's only a convenience syntax for importing multiple modules in one
go.

> Do I have targets Qt::Core and Qt::WebEngine?
>
yes

> Do we allow targets in the same namespace that have different
> versions?
> 
yes, provided they don't break each other.

> OTOH, there is nothing stopping you from producing component-level
> compatibility CPS's that are just references to the individual
> components in a multi-component package.
> 
that's correct, but then you potentially have a problem in the inverse
direction of generating CPS files from a qbs project.

> One reason I am optimistic about CPS's chances re: CMake is that it
> behaves very similarly to how CMake *currently works*. Trying to
> shoehorn in something that works very differently is going to be more
> work and face more resistance.
> 
it certainly is an *improvement*.