I did some work on two related libraries in the last few days which weren’t using Dune, so was using
opam pin extensively. Having added the features I wanted, and made pull requests, I then converted the two libraries to use Dune.
I’ve written a post comparing the workflow using
opam pin with how much more efficient it is using the composition feature of Dune to compile multiple libraries which you’re working on at once. Hope it might be an informative demo for why you might want to convert your own libraries to Dune too
A very nice writeup on a generally undersold feature of Dune - thank you @dra27!
This is one of the greatest features of Dune; thanks for the writeup! We are very close to getting the core of the MirageOS libraries to all switch to Dune, and so be able to develop unikernels in exactly the same way. I have a local ‘duniverse’ with >150 opam packages all building from a single Dune invocation
Thanks for the writeup.
For subprojects, there’s a install process after build which only exposes the interfaces needed per project, how does dune cover that?
Is your install process expressed as dune rules? If so,
dune build @install should just work in a monorepo as it does with a smaller polyrepo.