Hi Aleksey,
Anil posted a link to this thread in the Dune developer chat. I haven’t read the full discussion, but here are answers to your last questions: Dune does generate .install manifests files. File <package>.install contains the listing of every file that should be installed, grouped per section.
Such files are generated based on what programmers write in their dune files. For instance, if the programmer writes something like this:
(install
(section bin)
(package foo)
(files (prog.exe as prog)))
Then Dune will add the following entry to foo.install:
bin: [
"_build/install/default/bin/prog"
]
Or if the programmer declares that a library is public, by adding a (public_name <package-name>) or (public_name <package-name>.<something>) field, then Dune will generate lib entries for the various files of the library.
Regarding question 3, programmers don’t need to think in terms of the manifest file. They should simply tell Dune what libraries and executables are public, and what additional files they want their package to install. They should do that by adding the relevant public_name fields and install stanzas. .install files are mostly an implementation detail and are meant for package management tools. If in the future a new standard emerged and .install files would become unused, Dune would switch to the new standard and it should be transparent for Dune users.
It should be mostly safe to copy files from the staging directory to the destination directory. Although, the two current consumers of these files (opam-installer and dune install) both do a bit more, more precisely they both set exact permissions on the destination files.
However, a recent version of Dune introduced a new “site” feature which breaks the assumption that files can simply be copied and their permissions set. Indeed it requires some files to be rewritten at installation time to set in stone a few runtime parameters. dune install performs this rewritting but opam-installer does not, which means that packages using the “site” feature must be installed via dune install. We recently discovered this issue and haven’t yet made a decision as to how to move forward. So this is a good time to chime in if you’d like to bring a more package manegement point of view. The relevant issue to discuss this is this one.
Yes, they do list symbolic links. During the build, Dune setups symbolic links in the _build/install/default (or more generally _build/install/<build-context> directory) pointing to the real artefacts. This directory mimics the installation layout. This allows to have tests that works “as if the package had been installed”. These symbolic links are the one listed in .install files.
Do you have mind to take the list of files listed in the .install file, partition it in two (byte and native), and then have a simple way to ask Dune to build one of the two partitions? If yes, that could be done but there are some pitfalls. For instance, if the programmer wrote a rule to generate a source file using a generator that is locally built, then unless the programmer explicitly requests to use the bytecode version of the generator, Dune will use whichever version it thinks is best. More precisely it will use the native version if the native compiler is available. This means that requesting the bytecode artefacts could still involve native compilation. You could get away by hiding the native compiler during bytecode compilation, but then you’d loose sharing between the two builds. Anyway, nothing impossible here, but more designs and thinking is required. In the end, it is probably easier to ask Dune to build everything and then split the result in two binary packages.