[Development] Build system for Qt 6

[Matthew Woehlke]

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.

That has a larger surface area for breakage than CPS as currently
formulated, but whatever. I suspect you'll find it a harder sell.

> 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)

Let's say we allow that... what then is Qt_FOUND? Qt_VERSION? Do I have
targets Qt::Core and Qt::WebEngine? Do we allow targets in the same
namespace that have different versions?

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.

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.

-- 
Matthew