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?


Ran.

On Tue, Mar 19, 2024 at 4:55 PM Bret Brown via SG15 <sg15@lists.isocpp.org> wrote:

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. 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).

Feedback here or in the above linked github issue would also be appreciated.

Thanks!
Bret

_______________________________________________
SG15 mailing list
SG15@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15