[RFC] Installable directories

[rgrinberg]

Problem

Installing generated documentation is quite problematic with the current install stanzas. The issue is that the documentation is generated by tools that create a large set of files that we don't want to track as rules. So specifying as installed files would be quite painful.

Solution

Allow a user to specify an entire directory as installable. However, we can't simply allow for directories inside the files field. In the files filed, paths such as foo/bar/baz are installed as baz. That would be inconsistent with a directory construct that intends to preserve the internal paths structure (necessary for keeping links alive in html for example).

To accomplish that we can allow one of:

• A file_tree field instead of files field that will keep the paths structure.
• a tree constructor. So for example (files (tree dir/foo/)) would maintain the paths while (dir dir/foo/) would strip them.

Issues

Opam's install file format does not allow to specify directories directly. Since dune will have to support opam 2.0, we'll have to flatten the directory into a list of paths.

cc @ejgallego

[ejgallego]

Note that this also applies to Dune's own documentation.

[avsm]

This also came up when porting opam2web to dune, since it needs to install a bunch of javascript files. I've worked around it with a manual list in the dune file for now: https://github.com/ocaml/opam2web/pull/169/files#diff-11e776521519814f941e83aba6ddf08e

[kit-ty-kate]

I'm also having the same problem while trying to port the installation part of herd/herdtools7 to dune (they currently use shell scripts for configure and install and I was really hoping to be able to not use any shell scripts)

[anton-trunov]

I would also love to have this feature to install a standard library of a language under development along with its interpreter.

[ejgallego]

Was this fixed by #5097 ?

[kit-ty-kate]

not entirely. See https://github.com/ocaml/dune/issues/6133

[ejgallego]

Thanks for the information @kit-ty-kate , I won't reopen this bug as we already have #6133 .