C++ Logo


Advanced search

Re: Defining Roles of Tools in Dependency Management

From: Ran Regev <regev.ran_at_[hidden]>
Date: Tue, 19 Mar 2024 20:41:54 +0900
I didn't read the entire link, but the idea of separating for roles (or
concerns, or responsibilities) is great.

For the layer connecting the package managers with the build system, I
would suggest: projector, or projection.

Can you elaborate on the expected flow (or different flows) once we have
this clear-cut roles separation?


On Tue, Mar 19, 2024 at 4:55 PM Bret Brown via SG15 <sg15_at_[hidden]>

> Hi all,
> I've been thinking for some time now that it's important to define
> specific roles in dependency management workflows. This is a needed task so
> that we can start defining interoperability mechanisms between these roles.
> I'm using the word "role" in my email here intentionally because we have
> both package managers and build systems serving the same roles.
> As to specifics, Daniel Ruoso and I are attempting to describe our current
> model of dependency management workflows with three roles:
> - One is a dependency manager (a.k.a. package manager)
> - These resolve dependencies on source or binary artifacts
> - The second role is a build system
> - These construct and order build commands
> - The third role... needs name
> - Name suggestions would be helpful if any has some
> - This takes the universe populated by the dependency manager and
> flattens a projection into the specific view needed by the build system to
> construct a target model (i.e., model libraries and executables)
> Daniel has posted an illustrative diagram on roles and how they overlap on an
> existing github issue <https://github.com/isocpp/pkg-fmt/issues/5>.
> Please follow that link to see the annotated illustration of the concepts
> I'm outlining here.
> To the motivation for this discussion, this overlap is a root cause of
> interoperability problems in C++ tooling. Because concerns mix, each
> integration between pairings of build systems and package managers has to
> be implemented and maintained individually. For instance, if a new build
> system is introduced, manual engineering effort needs to be spent to get
> that build system to work with each interesting package manager. This is an
> O(m * n) problem where each unit is quite expensive on its own.
> Instead, we need to define a clean "seam" between different tools so that
> build systems and package managers can clearly understand what they should
> *not* be responsible for. Instead, they should be able to target one
> interoperation standard and support any number of integrations.
> If we have time in the agenda for SG-15 in Tokyo this week, it would be a
> good idea to discuss and get feedback on these ideas. In particular, this
> shared understanding will support progress in the development of the
> Common Packaging Standard (CPS) <https://github.com/cps-org/cps>.
> Feedback here or in the above linked github issue would also be
> appreciated.
> Thanks!
> Bret
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15

Received on 2024-03-19 11:42:05