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