Context

• (using melange 0.1) allows writing Melange / OCaml code together with limitations
• Recent work on "universal libraries" proposes using different contexts and enabled_if

Problems

• Multi-context libraries introduce a few problems:
  • library stanzas end up duplicated for any non-trivial use cases, and (enabled_if (= %{context} melange)) is infectious (melange libraries only work within the melange context)
  • it's not trivial to install multi-context libraries in the same context as native (for consumption within the same OPAM switch).
  • Editor support becomes more painful, and switching between files in different contexts still requires restarting the LSP.

Requirements:

• Installing multi-mode libraries alongside each other
• vary module sources according to the library mode
• vary preprocessing according to the library mode
• vary library dependencies according to the library mode

Proposed solution

• The proposed solution is 2-fold:
  • new conditional fields libraries, preprocess, flags, modules in (library ..)
    • prior art: melange.compile_flags
    • in their absence, a library with (modes melange) falls back to the fields already supported before this change.
  • the ability to choose module sources based on the mode e.g. foo.%{mode}.ml
    • we can solve the "copy_files problem" by having shared module sources and mode-specific sources in the same directory, with different extensions. Example:

- src
  |_ dune
  |_ common.ml
  |_ foo.melange.ml
  |_ foo.ocaml.ml

Slightly unrelated: this proposal is likely backwards-compatible with (using melange 0.1); after adopting it successfully in universal library projects such as Ahrefs, I propose we mark the Melange extensions stable in dune (1.0).

Implementation details

• we can keep module sources in the same directories in the build folder
• for Melange, we'll have to copy them to e.g. a .melange-sources folder after setting up rules for the implementation-specific module sources
• Installation keeps working since we already copy melange artifacts to <lib-root>/<pkg-name>/melange. We can install the Melange sources there, too.

Caveats / further work

It's likely we'll have to change Merlin to map a module name to its source file. This is desirable in general even without this proposal: Merlin currently guesses what module source corresponds to a module, and implementing this mapping would be a benefit for most OCaml projects and editor tooling.