For each of these, it is possible to do a configurator/jbuild-generation pass, but the big advantage of having variable rules directly is that they work when embedded in a Duniverse of related packages. For example, with a manually assembled Mirage duniverse, the default dune build rule doesnt work as it selects the Linux- and macOS-only packages simultaneously. If Dune could handle these parameters as part of the build scanning process, then package embedding works great.
As a longer term consideration, this also expands our ability to generate accurate package management scripts as well -- for example, opam files could have accurate available: constraints added based on these build rules as well.
The code from opam-depext could be vendored in to help with the os variables -- there's a lot of fairly clean code there that generates the variables in opam2.
It would be useful to be able to select build rules based on some variables other than the presence of libraries. For example:
For each of these, it is possible to do a configurator/jbuild-generation pass, but the big advantage of having variable rules directly is that they work when embedded in a Duniverse of related packages. For example, with a manually assembled Mirage duniverse, the default
dune build
rule doesnt work as it selects the Linux- and macOS-only packages simultaneously. If Dune could handle these parameters as part of the build scanning process, then package embedding works great.As a longer term consideration, this also expands our ability to generate accurate package management scripts as well -- for example,
opam
files could have accurateavailable:
constraints added based on these build rules as well.