This seems like a pretty simple task, but I’m having trouble figuring out how to write a dune file to accomplish this. In particular, I’d like to have something like:
src/
and have the dune file create a library w/ the Foo module exposed, and Foo depends on Bar.
Dune doesn’t support this. Out of curiosity, why do you want to use cm* files rather than source files?
A friend is TAing a class that uses OCaml, and I’m trying to help him modernize it (by turning Makefiles into dune). They have one project where they use a custom Set module that is distributed as cmo/cmi files. I’m actually not sure why… perhaps there isn’t a good reason.
I see. This would need to be supported specifically in dune, for instance with a field (self_build_modules set). You can open a ticket on the dune issue tracker for this, but if you can the best would be to simply include the set.ml file.
Another approach would be to distribute this set module as a findlib library. This way you wouldn’t have to distribute the sources if that is a problem. You might have to mess around with some findlib environment variables to make it visible for your local dune build, but it should be doable once you write a META file.
Thanks! This is precisely what I ended up recommending.
I wrote a META file and wrapped the whole thing up in an OPAM package. Then hosted it via university servers and had students just opam pin add ... and use the package.
The other advantage of this is that, since the sets.cm* files were compiled against 4.04.x, I can specify availability via the OPAM package.
I am also in the same situation as @ins. We used to distribute .cmos for complex utility functions (e.g. displaying images) because some students are tempted to solve a problem by reading into these files and then lose themselves into these, although they’re not useful to solve the original problem. The opam package solution seems a bit of an overkill for us, so I tend to think a solution allowing to link against a .cmo would be useful to many.
I wonder if we couldn’t solve this by allowing to manually add a local library path to the workspace. For instance, you would put a pre-compiled library in _libs/<mylib> with a META file etc… and dune would add _libs to the library search path. This seems like a more generic solution and requires less specific additions to dune.
On my side, the question raised is not of major importance although it does correspond to a real situation. So I guess any solution that is easy enough on the Dune implementation side while being not too demanding for users should be OK. As far as I’m concerned, I’m mainly reporting about a use case but I don’t think it’s a priority for Dune, rather a feature nice to have.
Ok, BTW that’s something you could already do right now by setting the environment variable OCAMLPATH:
$ OCAMLPATH=_libs:$OCAMLPATH dune ...
It would be quite natural load dune packages as well this way. As they’re just stanzas that could be interpreted as part of the current project.