Although dune is a fully featured build system, it’s still relatively young and has a few unpolished corners remaining. We tried to address some of these in the release to avoid the dreaded death by a thousand cuts. Here’s a selection of some of the improvements we’ve made.

Path Related Improvements $ jbuilder {exec,utop} ¶

We improved $ jbuilder exec to completely replace the need for symlinks for executing built binaries (like in ocamlbuild).

Previously, exec would be limited to executing installable (public) binaries. Now dune is able to execute local binaries as well, by passing a relative path to the binary. E.g. if you’d like to execute a binary defined with:

( executable (( name foo )))

You can do it with:

$ jbuilder exec ./foo.exe

If the binary is in a sub directory like src . Then you can either give the full relative path from the build root, or a path relative to your CWD.

$ cd src && jbuilder exec ./foo.exe # works like in the original dir $ jbuilder exec ./src/foo.exe

Furthermore, exec will now make sure the binary is rebuilt before executing it. Those of you who are used to doing something like:

$ jbuilder build $X && jbuilder exec $X

can rejoice at the key savings. Those who don’t like this new behavior, can disable it with the --no-build flag. I’ll also take this opportunity to remind everyone that exec supports passing arguments to the executed binary by forwarding all the arguments after -- to it. This is a standard feature which is supported everywhere in dune where it makes sense.

Finally, exec can also execute arbitrary binaries in the install environment by providing it an absolute path:

$ jbuilder exec /bin/ls

This example isn’t very useful, as you’re unlikely to have a public ls binary, but you get the idea.

We’ve also done a little fix to $ jbuilder utop related to CWD handling. Previously, launching a top level when your CWD wasn’t the build root wouldn’t quite work.

$ cd src && jbuilder utop .