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_at_[hidden]>
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 <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
>