Question on desired scope of drom

[jberdine]

I have a question about the desired scope of drom. It is not the common case, but sometimes a project has a nontrivial setup step before opam and dune can get started. For example, if more than one opam switch needs to be created (e.g. for multiple compiler versions, or with and without flambda, etc.) and a dune-workspace file needs to be generated using the names of those switches (e.g. to associate build profiles with switches).

I could imagine an extension of drom where a project description could declare several opam switches with differing constraints, and several dune build contexts with the associations between switches and contexts, as well as the dune build profiles. Essentially there are currently 3 distinct notions: opam switch, dune context, dune profile, which can have nontrivial associations between them, and need to be set up in different stages. It would be a user-level simplification if drom could provide a single concept that combines these together and generates the needed metadata for the current tooling.

[lefessan]

Do you have an example of such a project ? (it's easier to implement if we can have a good idea of the final result that drom should generate).

Note that drom can perform tests on multiple switches at the same time, with drom test --all, in which case it builds a specific _drom/dune-workspace.dev file and call dune with it.

The difficulty I see is that switch names are supposed to be decided by the user, whereas in your approach, it's the project description that decides which switches should be built and with which names. In your case, it sounds like drom should also set its own OPAMROOT for the project, and then create specific switches in it to be able to build the project. Am I right ?

[jberdine]

I don't have a simple enough case to make a good example. I can point to this dune-workspace file that relies on "sledge" and "sledge+flambda" switch already being setup (manually). That is a non-current commit, the current state gives up on having multiple switches due to the setup complexity. The current dune-workspace is otherwise similar in how it declares the build contexts, but associating all contexts to the same switch. The dune file then declares what the build contexts mean in terms of compiler flags and determining which context-specific conditional compilation is done via dune's env-vars mechanism. It would be useful if the dune-workspace could conveniently associate different switches to the different build contexts, and have some tooling support to set them up and keep them updated, etc.

I agree that name clashes are potentially troublesome. In the use cases I have in mind, the switch names are not themselves significant, they are only there so that dune-workspace can associate them to the right build contexts and profiles. If the dune-workspace file was generated, the switch names could be arbitrarily chosen to avoid clashes.