Bret Brown via SG15 <sg15@lists.isocpp.org> 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