On Tue, Mar 19, 2024 at 9:35 PM Boris Kolpackov <boris_at_[hidden]>
wrote:

> Bret Brown via SG15 <sg15_at_[hidden]> writes:
>
> > - 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
> > - 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)
>
> One things that immediately strikes me as problematic in this model
> are conditional dependencies that are often based on information that
> is only known by the build system (target platform, compiler, compiler
> version, stdlib used, etc). Which means that there is a feedback loop
> from the build system to the package manager. You could probably make
> the user supply this information to the package manager manually, but
> that won't scale beyond basic things.
>

I don't believe distinguishing these roles precludes something in the
dependency management role from probing for dependencies and constraints in
whatever ways are appropriate, including cooperation with build systems to
understand implicit requirements like which precise compilation toolchain
is being targeted. I don't know that we need to define interoperability
standards around those sorts of discovery-phase cooperation workflows yet.
I think it's enough to convince ourselves that our next steps are not
counterproductive.

Given most or all of your examples are what I would consider baseline build
environment specification, I'll note that I expect we will eventually want
to develop interop standards to describe baseline build environment details
like selected toolchains, selected standard libraries, mandatory build
flags, and so on. I'm thinking of the kind of information often represented
by CMake toolchain files, Conan profiles, vcpkg target triplet files, Spack
specification, and there are plenty of other examples. It is possible that
the specification can be modeled as a CPS file, though I haven't considered
a full range of options yet. For now, I'm personally convinced that
progress on the current subject, defining roles, does not require
interoperation mechanisms for baseline build environments. If someone feels
otherwise, I would like to hear more, though.

I do agree that all three roles do need to be compatible with respect to
basic build requirements. I do not expect build systems will immediately
get dumber about dependency management to fit this model. I do expect that
eventually, given a useful model, we will see tools providing better
experiences to end users by at least having modes where they intentionally
conform to roles. For instance, a build system might skip dependency
discovery functionality given a well-structured dependency mapping as an
input. We already see something like this in POSIX when build systems
leverage pkg-config, though that specific approach is not adopted
consistently and it is far enough from our desired end state that I would
not propose convergence on that workflow.

Bret