Sep 6, 2018 by Etienne M.
After a tiny but important patch release as 1.1.1, the dune team is thrilled to
announce the release of dune 1.2.0! Here are some highlights of the new
features in that version. The full list of changes can be found in the dune
When developing, it is common to edit a file, run a build, read the error
message, and fix the error. Since this is a very tight loop and developers are
doing this hundreds or thousands times a day, it is crucial to have the
quickest feedback possible.
dune build and
dune runtest now accept a
flag that will
watch the filesystem for changes, and trigger a new build. This feature is
Better error messages
Inspired by the great work done in
dune now displays the relevant file in error messages.
% cat dune
% dune build
File "dune", line 3, characters 2-10:
3 | (librarys cmdliner)
Error: Unknown field librarys
Hint: did you mean libraries?
Many messages have also been improved, in particular to help users switching
jbuild format to the
Are you confused about how to format S-expressions? You are not alone.
That is why we are gradually introducing a formatter for
dune files. It can
transform a valid but ugly
dune into one that is consistently formatted.
% cat dune
(executable( name ls) (libraries cmdliner)
(preprocess (pps ppx_deriving.std)))
% dune unstable-fmt dune
This feature is not ready yet for the end user (hence the
and in particular the concrete syntax is not stable yet.
But having it already in the code base will make it possible to build useful
dune itself (to automatically reformat all dune files in a
project, for example) and common editors, so that they format
dune files on
First class support of findlib plugins
It is now easy to support findlib plugins by just adding the
library dependency. Then you can use
Fl_dynload module in your code which
will automatically do the right thing. A complete example can be found in the
dune promote command now accept a list of files. This is useful to
promote just the file that is opened in a text editor for example. Some emacs
bindings are provided to do this, which works particularly well with
inline expectation tests.
Deprecation message for (wrapped) modes
By default, libraries are
(wrapped true), which means that they expose a
single OCaml module (source files are exposed as submodules of this main
module). This is usually desired as it makes link-time name collisions less
likely. However, a lot of libraries are using
(wrapped false) (expose all
source files as modules) to keep compatibility.
It can be challenging to transition from
(wrapped false) to
because it breaks compatibility. That is why we have added
(transition "message")) which will generate wrapped modules but keep unwrapped
modules with a deprecation message to help coordinate the change.
Special thanks to our contributors for this release: @aantron, @anuragsoni,
@bobot, @ddickstein, @dra27, @drjdn, @hongchangwu, @khady, @kodek16,
@prometheansacrifice and @ryyppy.