I’m working on packaging a new version of Coq for pkgsrc system (cf. https://www.pkgsrc.org/). The system environment created by pkgsrc is slightly different from that created by e.g. a Debian or SUSE. In particular, the names of certain relevant executables (python, sphinx-build, etc.), and installation prefix locations are somewhat different. While some of these configuration items could be passed through environment variables, doing so is not always optimal, and it is also the case that some other build configuration items could not naturally be passed that way.
After becoming familiar with the dune documentation, I concluded that the most natural approach to accommodate the differences in system environments would be to produce a workspace definition that includes system-specific settings. This way, I hoped, the names of the executables, as well as other parameters, could be recorded in a set of global dune variables, and then applied to the code.
Unfortunately, the documentation does not appear to indicate any way to set the variables from dune-workspace specifications. The closest subsystem, described in the documentation, that comes to implementing this functionality, is the dune-configurator. While it would be relatively straightforward to use it to set variables, it is also rather awkward. Indeed, in the latter case, the build-specific values would need to be written into yet-another file (say, config/global-vars.sexp) to be subsequently read by the configurator script and applied, without regard to the concept of a workspace. This approach would introduce yet another entity for a functionality that belongs to workspace.
I also have another question. Does dune build system encode any path into any of the files that it installs? The way the installation works in pkgsc — and that mirrors a number of ther systems — is as follows: after build completes, files are copied from a build tree into staging directory, from which they are archived into a package, and that package is installed by normal system tools. I have seen the discussion on this forum of installing projects built by dune into /usr/local/, /usr/, and other system directories, and at the same time I have not seen a discussion about installation into a staging directory. Does dune make any assumptions that would break installation into a staging directory?
Finally, I’m not clear, how are the installation manifests generated (which, as I understand it, are targeted towards opam). What file sets are described in these manifests? How does opam treat those manifests? Does opam perform a simple cp operation for each listed file? Also, do the contents depend on the compilation modes? If so, is there a natural way to specify what parts of source tree should be build as native, and which should be built as bytecode; and also, how to get a failure if those constraints could not be met?