dune

dune copied to clipboard

Inspired by a question from @andreypopp.

This is a bit of a sad limitation, because it means enabled_if just proliferates when depending on installed libraries.

I talked about this with @andreypopp offline, the problem is that we have been using two contexts in a single opam switch until now. But installing public libs with the same name should be possible if each context was linked to a different opam switch, using st like (context melange (opam (switch x.xx.x))).

I tried using (switch) in the melange context defined in the test so that public libraries get installed in separate switches, but the result is the same. 😕 I guess Dune duplication checks come before actually checking if the public libraries are being installed in separate switches?

because it means enabled_if just proliferates when depending on installed libraries.

I fail to see how the premise of this PR would work. How can we avoid the proliferation of enabled_if without something like https://github.com/ocaml/dune/issues/10362? As a consumer of a universal library, how can I use it without having two contexts? In reality, a "universal" library consists of two implementations, so I can't imagine a way in which these two implementations are exposed under a single name. For this, Dune already provides a solution: virtual libraries. But they require to hide the implementation details behind abstract types to make it work. Universal libraries allow you to expose the implementations to consumers, at the cost of defining two build contexts.

I guess Dune duplication checks come before actually checking if the public libraries are being installed in separate switches?

Indeed, I believe they're coming from scope.ml, when creating the db from stanzas.

@rgrinberg thanks, I made the description a bit more clear.