[Development] Build system for Qt 6

[Matthew Woehlke]

On 02/11/2018 13.39, Oswald Buddenhagen wrote:
> 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.

My approach forces packages to be transactional. Either you find *all*
the required components in a package spec, or you ignore that package
spec. Once you've found a package, you "commit" to that; if anything
subsequently goes wrong, it's up to the user to fix it (e.g. by
specifying a different instance of the package that's causing problems).

Your approach doesn't provide for transaction points except at the
component level. That means it either has to be able to arbitrarily
backtrack (global dependency solving), or there exist cases that will
cause it to get stuck that my approach would handle more gracefully.

> On Fri, Nov 02, 2018 at 11:59:39AM -0400, Matthew Woehlke wrote:
>> 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.

I suspect that would require much more significant alterations to CMake.
Also...

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

...this *is* relevant to CMake, so it needs to have a plausible answer.
Otherwise, what you are proposing is not helpful, because CMake will not
be able to use it.

It is fairly easy to make use of a package/component based system in a
tool that only works on components. Going the other way around is more
problematic. (Except... a tool that only uses components is going to
have the sorts of issues I've been describing.)

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

Well, that sounds like QBS's problem ;-).

Offhand, I'd guess that the most plausible solution is to manually
specify a package-level spec and auto-generate component-level specs.
(Yes, you can do that with CPS.)

-- 
Matthew