modes not respected in combination with library with public_name

[jberdine]

Expected Behavior

With a dune file such as:

(env
 (_
  (flags ())))

(subdir
 lib
 (library
  (name test_lib)
  (public_name test_package.test_lib)
  (modes native)))

(executable
 (name test_exe)
 (public_name test_exe)
 (package test_package)
 (libraries test_lib)
 (modes native))

I expect that executing dune build will not run ocamlc on implementation files. I realize that it might compile interface files with ocamlc even when building for native code only.

Actual Behavior

In the case above, dune build does run ocamlc on implementation files. Curiously, if (public_name test_package.test_lib) is removed, it does not.

Reproduction

Here is a small project that shows this: dune-bc-test.tar.gz

Specifications

• Version of dune (output of dune --version): 2.5
• Version of ocaml (output of ocamlc --version): 4.08.1
• Operating system (distribution and version): macos 10.14.6

[rgrinberg]

Try writing an empty mil for your executable. Does it fix the problem?

[jberdine]

It already has one. :-)

[ghost]

It's the same problem as described in #3182. Adding a public name pulls in the cmt files since they are installed, and cmt files are produced by ocamlc.

Also, this time I'm really adding the topic to the next meeting (I forgot it last time): https://github.com/ocaml/dune/wiki/dev-meeting-next

[jberdine]

Ah, I see, thanks.

For context, in the actual usage this example is reduced from, the library is 'public' just so that a directory of the repo can be used from several others. That is, the 'install' that we rely on is only within dune-land, and need not make it to opam-land. In case that helps or is relevant.

Also, the motivation for not compiling with ocamlc is one to reduce build times, but mostly to avoid getting duplicate warnings from both ocamlc and ocamlopt. Turning off warnings in ocamlc_flags doesn't work since .mli files are only compiled with ocamlc. So for this particular case, a way to pass different flags to ocamlc when compiling .ml and .mli would be a workaround.

[ghost]

Hmm, if you only use the public library only inside the workspace but don't install it, then the cmt files shouldn't be pulled in 🤔

[jberdine]

Ah, but a dune "install" is needed to version-stamp the binaries, so that is always done (except in watch mode).

[ghost]

Note that you can also version-stamp the binaries by promoting them to the source tree via:

(executable
 (name foo)
 (promote unitl_clean)
 ...)

That only works if you are using a single build context though.

[ghost]

@jberdine BTW, while looking at #3701 we just remembered that Dune does caching of error messages to avoid getting the same error twice when compiling in both bytecode and native code. So normally you already should not get the same warnings and errors twice.

[jberdine]

Interesting. I don't know if I always see potential duplicate messages, but I definitely started out hunting this due to seeing duplicated messages in practice. There might be something nontrivial in the definition of "duplicated" though, I'm not sure. Is the scope of the cache the whole workspace? The duplicates I saw may have been coming from different contexts (with different ppx configs leading to different preprocessed code). Is there any info on the caching mechanism that you can point me to that would help me to find a small repro more efficiently than a monkey at a keyboard? :-)

[ghost]

Just the code really, the caching is done there:

dune/src/dune_util/report_error.ml

Lines 87 to 88 in d629481

	let hash = Digest.generic msg in
	if not (Digest.Set.mem !reported hash) then (

If one message as one more trailing whitespace, they won't be deduplicated.