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!
Improve validation and error handling of arguments to
dune init (#3103, fixes
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)
(boot) option to
(coq.theories) to enable bootstrap of
Coq’s stdlib (#3096, @ejgallego)
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)
enabled_if fields in
executable(s) stanzas (#3137, fixes #1690
Do not fail if
ocaml are absent. Wait for them
to be used to fail (#3138, @rgrinberg)
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)
What does this validation actually do? I searched the docs at https://dune.readthedocs.io/en/latest/search.html?q=strict_package_deps&check_keywords=yes&area=default 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.
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.
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
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
Could you report this as a bug? We should fix this issue for 2.3.1