[Development] Build system for Qt 6

Matthew Woehlke mwoehlke.floss at gmail.com
Wed Oct 31 18:09:13 CET 2018


On 31/10/2018 12.46, Oswald Buddenhagen wrote:
> On Wed, Oct 31, 2018 at 10:17:04AM -0400, Matthew Woehlke wrote:
>> On 30/10/2018 17.51, Oswald Buddenhagen wrote:
>>> after much thinking about the matter, i concluded that the interface
>>> files should correspond to "atomic linkable entities", which
>>> essentially means actual libraries
>>
>> That's basically the pkg-config approach... and I believe that design
>> to be intractable. In short, it fails to specify how to do the
>> equivalent of `find_package(X COMPONENTS A B C)`.
>
> i'd just aggregate by components: {qt.core, qt.gui} is the same as
> {qt.{core, gui}}. not sure what qbs currently does internally ...

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?

Having a top-level spec provides a well-defined answer to these sorts of
problems; if the top-level spec doesn't meet the user's requirements,
you ignore the entire thing and keep looking.

>> Especially if you have e.g. (ignoring 'C' for simplicity):
>>
>>   X.A-1.2
>>   X.A-1.0
>>   X.B-1.1
>>   X.B-1.0
>>
>> You *have* to be able to do package-level queries; otherwise, how do you
>> know (assuming X-1.z are mutually incompatible, but the consumer can use
>> any X-1.z) to use X-1.0?
>
> you can specify version constraints in the dependencies like e.g. debian
> packages do.

Again, please explain how you will ask the consuming tool to find your
requirements, and how it will accomplish this task.

With CPS as currently designed, it is easy:

  # CMake syntax, but same principle would apply to any tool
  find_package(X COMPONENTS A B)

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 a) that's harder to implement, and b) existing build
systems do not work that way (at least, both CMake and autotools don't).
Moreover, a package+components based model (i.e. CPS in its current
form) can be made to work with a tool that *does* work that way (QBS?),
but you have not demonstrated how a components-only model could be made
to work with a tool that does *not* do global dependency solving.

(Admission: CPS has been strongly influenced by what *CMake* needs. A
specification that doesn't satisfy CMake's needs, e.g. pkg-config, is
probably a non-starter as far as potentially replacing CMake's current
stuff.)

-- 
Matthew



More information about the Development mailing list