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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
