(optional) does not seem to work with executable stanzas.

[mefyl]

Expected Behavior

When flagged as (optional), executable are skipped if a dependency is missing.

Actual Behavior

When running dune build, a fatal error is raised because one of the dependecies of the optional executable is missing.

It works as intended with libraries, and the document states it should behave the same on executables and libraries.

Reproduction

$ dune --version
2.7.1
$ cat dune-project 
(lang dune 2.7)
$ cat dune
(executable
 (name test)
 (optional)
 (libraries fmt))
$ dune build
File "dune", line 4, characters 12-15:
4 |  (libraries fmt))
                ^^^
Error: Library "fmt" not found.
Hint: try:
  dune external-lib-deps --missing @@default
Done: 0/0 (jobs: 0)
$

Specifications

• dune 2.7.1
• ocamlc 4.10.0
• Operating system: Gentoo

[toots]

I can confirm this issue. Here's a gist to test: https://gist.github.com/toots/63144bf565f39be2ee248e724c90c128

I noticed that only dune build @install was tested in https://github.com/ocaml/dune/pull/3163/files. If I, indeed, change name for public_name in my gist then everything works as expected with dune build @install.

Looks like the fix and test did not cover the case of a call to dune build.

[nojb]

I believe this is the expected behaviour : (optional) is meant to avoid hard dependencies during OPAM installations and only affects the @install target. Other targets (like @all) will continue to try to build everything.

Duplicate of #3970

[toots]

This is, frankly, pretty odd.

First, this is not the way it works for libraries, despite the documentation saying:

(optional is the same as the corresponding field of library

Second, this creates a situation where dune build fails while there is nothing wrong with the build. For most people, dune build is the routine command to check that your module doesn't have any issues. For the same reason, it will also be likely to be used in continuous integration setups.

If that is the way the developers are intending it then this is unfortunate in my opinion. At the very least, the documentation should be updated to clarify this.

[nojb]

cc @rgrinberg

[nojb]

Closing as behaviour is expected. If there are suggestions for a different behaviour, please do open a new issue :) Cheers!

[toots]

Okay. This is a bit disappointing but I understand.

[toots]

I just wanted to point out that this issue is breaking all our CI builds at the moment b/c of some test executable that should only be built when ocamlnet is present: https://github.com/savonet/liquidsoap/runs/2203120089?check_suite_focus=true

I would really reconsider this semantics.