Probably not much, thanks. Don’t really need a parser once the ‘.’ has been changed to ‘./’ - the Scheme reader already parses everything. Well, at least the once I’m using does, I haven’t tested other implementations. In any case, my thinking is just that we might see more tools if Scheme implementations could read dune files; the only thing blocking that (to my knowledge) is the dot ‘.’ in lists.
1 Like
It would be a small feature, I personally would be grateful if a dune file parser existed. There have been times where I would have liked to be able to extract dune-project data programmatically (e.g. the version number, license name, etc.). This was never for anything important, but it would have been convenient. Although I’m not a fan of JSON, YAML, or any of those other configuration formats, I appreciate how you can easily read them with basically any scripting language.
@zozozo Thanks for sharing this! Your rules are much more comprehensive than mine, and may be a good model for the kind of thing Dune could do natively. I’ll file an issue with the Dune repo soon.
Edit: it looks like there’s already an open issue about Menhir messages: Support for menhir's `.messages` files · Issue #3284 · ocaml/dune · GitHub
Is there interest in generating system-independent Makefiles from dune?
I did some experiments on modifying the output of dune rules --makefile: xen/tools/ocaml/dune2makefile at xen-builds5 · edwintorok/xen · GitHub.
The idea was to remove absolute paths, and otherwise system specific configuration from it so that the makefile could be reused on another machine, running another distro, that doesn’t have ‘dune’ installed.
Although this may be brittle and not guaranteed to work for long it’d only need to hold together for a transition period.
OTOH doing these changes in ‘dune’ itself might be easier (rather than parsing the output of dune…), but I wouldn’t want to impose the additional maintenance burden for what might be a “one-off” feature used for a few months/years and then not used again.
Having makefiles generated from ‘dune’ would allow a more gradual transition from hand-written – and often incorrect – Makefiles to dune in projects such as Xen, where a sudden transition isn’t really possible due to part of the CI running on Debian oldstable which doesn’t have a suitable version of dune available.
OTOH a simple shell script can compile the entire OCaml code in Xen a lot more quickly than the recursive Makefile, and similarly modifying the current recursive Makefile to have a single hand-written Makefile with no incremental compilation that just builds everything in a single rule is still quite fast, comparable in time to how long make clean takes (which has accumulated sufficient cruft along the years that it is quite slow), and avoids all the problems with the old makefile: tools/ocaml: simplify and speed up build system · edwintorok/xen@96ef0e3 · GitHub
But obviously that Makefiles will then need to be maintained by hand alongside the ‘dune’ files for a transition period.
1 Like
As a slight tangent, not sure if this is a problem that should be fixed, more of a comment, but when working with beginners I’ve noticed some getting tripped up by the fact that while most dune commands are specific to the current directory (such as dune build, exec etc.), dune clean is project wide, and deletes all generated build artefacts.
This came up in the context of encoding a rather complicated build recipe (with Coq files that take minutes to compile) into dune and thus doing dune clean in one directory ended up requiring several minutes of compilation work to be done on the next compile.
Admittedly the reason we were using dune clean was because our build rules weren’t accurate recording their dependencies, and a good way of weeding this out was by running dune clean and then rebuilding particular subdirectories.
Insisting one last time 
I get that but I think it’s counterintuitive to have this as a default behavior. It’s quite rare to find commands that go upwards by default. Feels like a global side effect. As a teacher and sporadic developer of research tools, I’d rather have:
- at most upwards exporation until meeting a dune-project file (not dune-workspace)
subdir-like clauses in the said file to even avoid addingdunefiles anywhere (for simple projects; more complex projects may need specific dune files)- a clause in the dune-project file to allow going even more upwards (to accomodate the tool to the nice feature you describe)
1 Like
git and mercurial do that (and it is very convenient).
1 Like
I’ve updated Run inline tests in parallel · Issue #1516 · ocaml/dune · GitHub to explain how it could work.
Git tracks files that you have explicitly staged (or perhaps you’re speaking of other aspects of Git?; I don’t know Mercurial). Dune compiles files upwards if you don’t explicitly prevent it to do so. Even old files, small experiments that you made, old dune projects… and then you get dozens of errors completely unrelated to the project you think you’re compiling: speaking as an OCaml teacher, it’s not newcomer-friendly at all. Hence the middle-ground I’m proposing above for simple projects (typically those a newcomer will encounter).
1 Like
git and mercurial do that (and it is very convenient).
Not sure if we are discussing the same issue I had, but one major difference is that in the case of dune changing something in the directory above can change the behaviour for the current directory. This can give weird confusing issues, things that stop working if you move a dune project on your disk, etc. I have this “global side effect” feeling with dune, but not with git. A git repo inside a git repo behaves as you expect it.
BTW we’ve been running with (implicit_transitive_deps false) for like 10 months in our whole codebase and it’s been so challenging that it looks like we’re going to revert this back apparently. It’s a shame as the absence of it was also a major pain as well. I’m wondering if something can be done upstream
Something can surely be done upstream. There’s a proposal for it in fact Add `-Ihidden` in addition to `-I` for avoiding transitive dependencies in the initial scope by bobot · Pull Request #31 · ocaml/RFCs · GitHub
This has been included in dune 3.8
2 Likes
It would be nice if the dune init templates were updated to prevent this issue that many newcomers runs into: Unbound module for library if library name the same as test name · Issue #778 · ocaml/ocaml-lsp · GitHub
ppx_inline_test will run inline_tests in parallel starting with version v.0.16.1.
2 Likes