[ANN] Dune 1.2.0

On behalf of the dune team, I’m pleased to announce the release of Dune 1.2.0. This release contains many new goodies which I will not describe here. This is because Etienne Millon has prepared a blog post for this release: https://tarides.com/2018-09-06-dune-1-2-0.html

I’d also like to personally thank him for all work he’s done to make this release so great.

As usual, the change log is replicated below for your convenience.

Happy hacking!

1.2.0 (14/09/2018)

  • Ignore stderr output when trying to find out the number of jobs
    available (#1118, fix #1116, @jeremiedimino)

  • Fix error message when the source directory of copy_files does not exist.
    (#1120, fix #1099, @emillon)

  • Highlight error locations in error messages (#1121, @emillon)

  • Display actual stanza when package is ambiguous (#1126, fix #1123, @emillon)

  • Add dune unstable-fmt to format dune files. The interface and syntax are
    still subject to change, so use with caution. (#1130, fix #940, @emillon)

  • Improve error message for dune utop without a library name (#1154, fix
    #1149, @emillon)

  • Fix parsing ocamllex stanza in jbuild files (#1150, @rgrinberg)

  • Highlight multi-line errors (#1131, @anuragsoni)

  • Do no try to generate shared libraries when this is not supported by
    the OS (#1165, fix #1051, @jeremiedimino)

  • Fix Flags.write_{sexp,lines} in configurator by avoiding the use of
    Stdune.Path (#1175, fix #1161, @rgrinberg)

  • Add support for findlib.dynload: when linking an executable using
    findlib.dynload, automatically record linked in libraries and
    findlib predicates (#1172, @bobot)

  • Add support for promoting a selected list of files (#1192, @jeremiedimino)

  • Add an emacs mode providing helpers to promote correction files
    (#1192, @jeremiedimino)

  • Improve message suggesting to remove parentheses (#1196, fix #1173, @emillon)

  • Add (wrapped (transition "..message..")) as an option that will generate
    wrapped modules but keep unwrapped modules with a deprecation message to
    preserve compatibility. (#1188, fix #985, @rgrinberg)

  • Fix the flags passed to the ppx rewriter when using staged_pps (#1218, @jeremiedimino)

  • Add (env var) to add a dependency to an environment variable.
    (#1186, @emillon)

  • Add a simple version of a polling mode: dune build -w keeps
    running and restarts the build when something change on the
    filesystem (#1140, @kodek16)

  • Cleanup the way we detect the library search path. We no longer call
    opam config var lib in the default build context (#1226, @jeremiedimino)

  • Make test stanzas honor the -p flag. (#1236, fix #1231, @emillon)

  • Test stanzas take an optional (action) field to customize how they run (#1248,
    #1195, @emillon)

  • Add support for private modules via the private_modules field (#1241, fix
    #427, @rgrinberg)

  • Add support for passing arguments to the OCaml compiler via a
    response file when the list of arguments is too long (#1256, @jeremiedimino)

  • Do not print diffs by default when running inside dune (#1260, @jeremiedimino)

  • Interpret $ dune build dir as building the default alias in dir. (#1259,

  • Make the dynlink library available without findlib installed (#1270, fix
    #1264, @rgrinberg)


Thanks for the new release. I’m probably going to test out the watch feature soon!

Not sure whether this is the right place to raise concern but I am wondering why dune unstable-fmt formats S-Expressions in this highly unidiomatic way. As a former Lisper I can state that decades of using S-Expressions for programming have yielded a pretty well established way of formatting S-Expressions that Common Lisp, Scheme and Clojure adhere to. Therefore I am surprised why dune files would use a different style to the one that e.g. Emacs and other editors that are used in the Lisp world use.


I share your concern. This is something that we need to fix before blessing unstable-fmt for general use. Here’s the ticket where some discussion about this occurred:

1 Like

Exactly. Basically it was quick and easy to implement, and meant to be put in place so that we can have feedback on the general feature before committing to a particular syntax.

One challenge that we’ll have is that not all dune users are experienced with lisp, nor use a text editor with powerful s-expression features. Also, since the concrete syntax will be automated (and probably not configurable), it won’t be perfect for anyone. That being said, s-expressions have a rich history of formatting so we’ll build on top of it!

1 Like

Yes, this has also been my experience which is why I greatly appreciate the feature! If you don’t have an editor with structural editing, you can just as well write it in any way and then have dune reformat it in a way where Lispers don’t have to wonder and reconfigure their editors and I don’t have to explain Lisp formatting rules to coworkers. Best of both worlds.

This is also why we’re planning to introduce ocamlformat at work because that will save us from bickering about formatting and having to explain new hires how we want our files to be formatted. While there is not really any universally agreed upon way to format code so I am sometimes a bit annoyed by how ocamlformat chooses to format things but would like to use it for the sake of consistency, for Sexprs that exists. I was actually thinking to deploy an existing Sexpr formatter on our dune files, but of course an integrated solution would be even better.