[ANN] Dune 2.3.0

Community
1

On behalf of the dune team, I’m proud to announce the 2.3.0 release of dune. This release is particularly relevant for users of coq that use dune to build their theories, developers of coq that use dune to build their favorite theorem prover. I’d like to thank @ejgallego for all the hard work to improve dune in this regard.

I’d also like to point out the (strict_package_deps) option that is now available in project files. This option will now ask dune to validate the package dependencies specified in the package stanzas in your dune-project files.

Here’s the full change list, and as always, happy hacking!

2.3.0 (15/02/2020)

  • Improve validation and error handling of arguments to dune init (#3103, fixes
    #3046, @shonfeder)

  • dune init exec NAME now uses the NAME argument for private modules (#3103,
    fixes #3088, @shonfeder)

  • Avoid linear walk to detect children, this should greatly improve
    performance when a target has a large number of dependencies (#2959,
    @ejgallego, @aalekseyev, @Armael)

  • [coq] Add (boot) option to (coq.theories) to enable bootstrap of
    Coq’s stdlib (#3096, @ejgallego)

  • [coq] Deprecate public_name field in favour of package (#2087, @ejgallego)

  • Better error reporting for “data only” and “vendored” dirs. Using these with
    anything else than a strict subdirectory or * will raise an error. The
    previous behavior was to just do nothing (#3056, fixes #3019, @voodoos)

  • Fix bootstrap on bytecode only switches on windows or where -j1 is set.
    (#3112, @xclerc, @rgrinberg)

  • Allow enabled_if fields in executable(s) stanzas (#3137, fixes #1690
    @voodoos)

  • Do not fail if ocamldep, ocamlmklib, or ocaml are absent. Wait for them
    to be used to fail (#3138, @rgrinberg)

  • Introduce a strict_package_deps mode that verifies that dependencies between
    packages in the workspace are specified correctly. (@rgrinberg, #3117)

  • Make sure the @all alias is defined when no dune file is present
    in a directory (#2946, fix #2927, @jeremiedimino)

7 Likes
2

What does this validation actually do? I searched the docs at Search — Dune documentation but it didn’t turn up anything.

I also tried adding and removing packages from my (package ...), as well as using an invalid package name, and dune build @all didn’t complain about anything.

3

It will validate the (dependencies ..) field in the the package stanzas of your dune-project. Simple example. Suppose you write the following dune files to define 2 libraries in two different packages:

(library (public_name pkg1))
(library (public_name pkg2) (libraries pkg1))

But your dune-project file omits the fact that pkg2 should depend on pkg1:

(package (name pkg1))
(package (name pkg2))

Dune will now be able to detect this and complain.

The plan is to further expand this check to external packages.

4

Ah, OK. This would be really useful! In CI, checking that the opam dependencies are correct requires installing each package individually, because otherwise one package can satisfy another’s dependency and the problem goes unnoticed. If we could rely on dune to check that the dependencies are correct, we could build everything in parallel safely.

I tried the local check with ocaml-ci itself. It reported:

$ dune build @all
Error: Package ocaml-ci-service is missing the following package dependencies
- current_ansi

As far as I can tell, ocaml-ci-service doesn’t use current_ansi directly; it’s just a transitive dependency of current_web. How can I find out why dune thinks I need to specify this?

I tried using (implicit_transitive_deps false) and adding all the dependencies explicitly, but even then service/dune doesn’t list current_ansi.

5

Could you report this as a bug? We should fix this issue for 2.3.1

6

(@rgrinberg added this at https://github.com/ocaml/dune/pull/3165 - thanks!)