On Wed, Oct 31, 2018 at 01:09:13PM -0400, Matthew Woehlke wrote:
> 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?
>
as i said below, by the sub-packages constraining their transitive
dependencies.
> 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.
>
that answer might be unnecessarily strict, though. if i build a
3rd-party qt module and install it into /opt/myqt, it might be
compatible with the system qt in /usr. i want to be able to use that
additional qt module by depending on {qt.{core,gui,3rdpartymodule}}.
> >> 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 that's exactly what you do anyway with the syntax above, within the
scope of a single package. whether the interfaces are explicitly
aggregated by some top-level file or implicitly by some shared
properties and mutual constraints is completely inconsequential for the
user.
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
