ANN: dune (jbuilder) 1.0+beta18

On behalf of the dune development team, I’d like to announce the 18 beta.

This release brings a number of new features, but I’d like to highlight the one feature that towers above the rest. Given a module definition that contains only type declarations, you will able to write these type definitions in an .mli file, while omitting the customary implementation file - BUT only after listing these so called mli only modules in the modules_without_implementation field. We are awaiting your praise.

Apart from this, we’ve also changed the default to a far more quiet progress bar. To get back the old output use the --display=short option. You may set this option for all of your dune projects in the newly introduce dune config file. Refer to the manual for details.

As usual, the change log is replicated for your convenience:

1.0+beta18 (25/02/2018)

  • Fix generation of the implicit alias module with 4.02. With 4.02 it
    must have an implementation while with OCaml >= 4.03 it can be an
    interface only module (#549)

  • Let the parser distinguish quoted strings from atoms. This makes
    possible to use “${v}” to concatenate the list of values provided by
    a split-variable. Concatenating split-variables with text is also
    now required to be quoted.

  • Split calls to ocamldep. Before ocamldep would be called once per
    library/executables stanza. Now it is called once per file

  • Make sure to not pass -I <stdlib-dir> to the compiler. It is
    useless and it causes problems in some cases (#488)

  • Don’t stop on the first error. Before, jbuilder would stop its
    execution after an error was encountered. Now it continues until
    all branches have been explored (#477)

  • Add supprot for a user configuration file (#490)

  • Add more display modes and change the default display of
    Jbuilder. The mode can be set from the command line or from the
    configuration file (#490)

  • Allow to set the concurency level (-j N) from the configuration
    file (#491)

  • Store artifacts for libraries and executables in separate
    directories. This ensure that Two libraries defined in the same
    directory can’t see each other unless one of them depend on the
    other (#472)

  • Better support for mli/rei only modules (#490)

  • Fix support for byte-code only architectures (#510, fixes #330)

  • Fix a regression in external-lib-deps introduced in 1.0+beta17
    (#512, fixes #485)

  • @doc alias will now build only documentation for public libraries. A new
    @doc-private alias has been added to build documentation for private

  • Refactor internal library management. It should now be possible to
    run jbuilder build @lint in Base for instance (#516)

  • Fix invalid warning about non-existent direcotry (#536, fixes #534)


TL;DR; Where can I learn how to adapt to changes made in dune 1.0+beta18?

Long version:
On February 28th, continuous integration of my project on travis started to fail. I did not understand why until I opam update && opam upgrade my machine and build (based on ocamlbuild not dune, I know, I still live in the past…) started to fail there with the same error as in travis:

File "_none_", line 1:
Error: No implementations provided for the following modules:
         Cohttp_lwt_unix__ referenced from webapp/webapp_common.cmx,
         Cohttp__ referenced from webapp/webapp_common.cmx,
           webapp/route_root.cmx, webapp/WebSim.cmx
         Cohttp_lwt__ referenced from webapp/webapp_common.cmx,

The problem is deterministic. In an opam switch with jbuilder.1.0+beta17 everything works, in an opam switch with the exact same packages in the exact same version but jbuilder in version 1.0+beta18, my build complains about cohttp… and I have absolutely no idea what I need to modify in order to fix that (except my build system, I know … I know … but this won’t happen in the next days)

@pirbo This was an unintended consequence of a jbuilder change in beta18. For more information you can see the issue here and the commit addressing it here.

For now the options for a work-around (as far as I know) are:

  1. Pin jbuilder to 1.0+beta17 until beta19 is out (hopefully soon)
  2. Pin jbuilder to --dev-repo to track jbuilder’s master branch until beta19 is out (hopefully soon)
  3. Convert your codebase’s build system to jbuilder :slight_smile:

Hope this helps!

1 Like

For old-style ppx rewriters, I used to just add the package as a library dependency and add a preprocess action with ppxfind. For example, with beta17 I had:

  (libraries (ppx_deriving ppx_deriving.api fmt
              ;; we just need this for merlin
  (preprocess (action (run ppxfind -legacy ppx_tools.metaquot --as-pp ${<})))

The .merlin generation does not use PKG anymore, is there another way to add old-style ppx rewriters to the .merlin file?

1 Like