Dune 1.2.0by Etienne Millon on Sep 6th, 2018
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 repository.
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
% cat dune (executable (name my_program) (librarys cmdliner) ) % 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 (executable (name ls) (libraries cmdliner) (preprocess (pps ppx_deriving.std) ) )
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
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.
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
(wrapped (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.