[ANN] Dune 2.7.0

Community
,
1

On behalf of the dune team, I’m pleased to announce the release of dune 2.7.0.
This release adds a couple of important features and many bug fixes. I’ll just briefly summarize the two features, and let our improved documentation elaborate on the details.

The first one is first class support for instrumentation tools such as bisect_ppx and landmarks. This is one of the most requested dune features ever, and we’re pleased to show you all what we’ve come up with

Special thanks to @stephanieyou & @nojb for implementing this feature. Many thanks to @aantron for tirelessly iterating on the end user experience with us.

While the features is looking quite good already, we consider it a “first take” on this subject. We welcome your experience reports and feature requests.

The second feature we’re introducing this release is dune’s cram testing framework. The cram framework is our secret weapon for making dune (relatively) bug free. I’ll soon write up a dedicated post to give you a flavour of how it works. To those who can’t wait, there’s a new section in the documentation that explains everything.

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

Happy Hacking.

2.7.0 (13/08/2020)

  • Write intermediate files in a .mdx folder for each mdx stanza
    to prevent the corresponding actions to be executed as part of the @all
    alias (#3659, @NathanReb)

  • Read Coq flags from env (#3547 , fixes #3486, @gares)

  • Allow bisect_ppx to be enabled/disabled via dune-workspace. (#3404,
    @stephanieyou)

  • Formatting of dune files is now done in the executing dune process instead of
    in a separate process. (#3536, @nojb)

  • Add a --debug-artifact-substution flag to help debug problem with
    version not being captured by dune-build-info (#3589,
    @jeremiedimino)

  • Allow the use of the context_name variable in the enabled_if fields of
    executable(s) and install stanzas. (#3568, fixes #3566, @voodoos)

  • Fix compatibility with OCaml 4.12.0 when compiling empty archives; no .a file
    is generated. (#3576, @dra27)

  • $ dune utop no longer tries to load optional libraries that are unavailable
    (#3612, fixes #3188, @anuragsoni)

  • Fix dune-build-info on 4.10.0+flambda (#3599, @emillon, @jeremiedimino).

  • Allow multiple libraries with inline_tests to be defined in the same
    directory (#3621, @rgrinberg)

  • Run exit hooks in jsoo separate compilation mode (#3626, fixes #3622,
    @rgrinberg)

  • Add (alias …), (mode …) fields to (copy_fields …) stanza (#3631, @nojb)

  • (copy_files …) now supports copying files from outside the workspace using
    absolute file names (#3639, @nojb)

  • Dune does not use ocamlc as an intermediary to call C compiler anymore.
    Configuration flags ocamlc_cflags and ocamlc_cppflags are always prepended
    to the compiler arguments. (#3565, fixes #3346, @voodoos)

  • Revert the build optimization in #2268. This optimization slows down building
    individual executables when they’re part of an executables stanza group
    (#3644, @rgrinberg)

  • Use {dev} rather than {pinned} in the generated .opam file. (#3647,
    @kit-ty-kate)

  • Insert correct extension name when editing dune-project files. Previously,
    dune would just insert the stanza name. (#3649, fixes #3624, @rgrinberg)

  • Fix crash when evaluating an mdx stanza that depends on unavailable
    packages. (#3650, @CraigFe)

  • Fix typo in cache-check-probablity field in dune config files. This field
    now requires 2.7 as it wasn’t usable before this version. (#3652, @edwintorok)

  • Add "odoc" {with-doc} to the dependencies in the generated .opam files.
    (#3667, @kit-ty-kate)

  • Do not allow user actions to capture dune’s stdin (#3677, fixes #3672,
    @rgrinberg)

  • (subdir ...) stanzas can now appear in dune files used via (include ...).
    (#3676, @nojb)

16 Likes
2

Two questions

  1. I have executable regression/test081llist.exe. To run it in cram test I should write ../../../default/regression/test081llist.exe because cram tests are executed from _build/.sandbox/9a4a45a345b90bc87da82d427df06c2c/default and not from _build/.default. What is expected way to write cram tests?

  2. If I have a bunch of executables in a directory how to run them all in the test? I heard about @all stanza, but it seems that it is not implemented.

3
  1. What is the path of the executable relative to the test? If it’s regression/test081llist.exe, then you can use the cram stanza to depend on the executable:
(cram (deps regression/test081llist.exe))

And then use ./regression/test081llist.exe from inside the test.

  1. You should depend on them all in the cram stanza (like I did in #1). Then, just run them one by one inside the test:
  $ ./foo.exe
  $ ./bar.exe
  ..

Regarding the sandbox directory: that’s just an implementation detail for tests to make sure that tests only see files they’ve explicitly depended on, and to make sure that tests never see files created by other tests in the same directory. It should be completely transparent to you.

4

The current approach to add test seems a little bit ovecomplicated, isn’t it? To add test666 I need

  1. add test666 to (executables (names ...))
  2. add test666 to (executables (modules ...))
  3. add (cram (deps regression/test666.exe))
  4. add $ dune exec regression/test666.exe to .t file.

Can I simplify this somehow? (cram (deps regression/@exes)) or dune exec regression/@exes ?

5

Wait, there might be some misunderstanding here. If you test executable is just the binary test666 then you just need the test stanza:

(test (name test666))

Cram tests are for testing public executables. Therefore you don’t need this additional boilerplate, as your executable is already defined.

This post might give you a better idea of how it works Cram - Tests on Short Notice

1 Like
6

Cram tests are for testing public executables.

AFAIU public means “to be installed for further use”. How should I use dune to perform expectation tests on the output of private executables?

Also doc doesn’ say anything about publicity of executables.

Also, I think it would be more useful to rewrite the doc to show how cram test perform on executable created by dune, and not system-wide wc command.

3 Likes
7

How should I use dune to perform expectation tests on the output of private executables?

My first reply already explained this.

Also, I think it would be more useful to rewrite the doc to show how cram test perform on executable created by dune, and not system-wide wc command.

That’s a good idea. I’ll update the example to work with a wc that’s defined using an executable stanza.