The @all alias does not produce .cmt files which are produced by @check.

[cristianoc]

Expected Behavior

In example https://github.com/cristianoc/dune-cmt,
dune build should produce both a .cmt and .cmti file.

Actual Behavior

dune build produces only a .cmti file.
dune build @check produces s both a .cmti and a .cmt.

Specifications

• Version of dune (output of dune --version):
  2.2.0
• Version of ocaml (output of ocamlc --version)
  4.06.1
• Operating system (distribution and version):
  macOS Catalina 10.15.3

Hmm, it's because @all means "all the targets" but only the final ones, i.e. things like main.exe. So for an executable, @all will only build the various modules in native mode rather than both native and byte code. And since we only produce cmt files when building in bytecode, the cmt files are not produced at all.

For instance, if you add (modes byte exe) to your executable stanza, then @all will build the cmt files.

In Dune, we could either:

1. explicitly add cmt files to @all
2. build cmt files when building native code as well

1 is a bit ad-hoc, but it's probably the most viable solution.

[cristianoc]

@diml I'm testing out a global dead code analysis that relies on this.
Currently I'm telling every user to use the workaround dune build @check @all. However, if there's a solution in future, I'll recommend to upgrade dune instead.

Ok, I don't have a satisfying answer yet, but I'm making a note to myself to bring the subject up to the rest of the team at the next dev meeting. Hopefully we can find a good compromise.

The problem here is that requesting an alias cannot change the behaviour of the build. i.e. aliases are constructed in a pure manner and have no side effects. However, maybe we could introduce a separate command or setting. Or even change the compiler so that we can produce only the cmt file. That would be nice actually.

@cristianoc we discussed the problem last week. You can find the notes of our discussion here.

Basically, there is no perfect solution, but we decided on the following we should fix this PR: when building in bytecode is not requested by the user, for instance because the user wrote (modes native), then the cmt files should be produced by the rules to compile in native mode.

Would you be happy to write a PR for this change? Happy to give some pointers if yet :)

[cristianoc]

Hey @jeremiedimino thank you for the update.
This is the current workaround I am suggesting:
https://github.com/cristianoc/reanalyze#full-project-test-infer-native-project

Once a better workaround has shipped, I will update the recommendation.

Fair enough. @rgrinberg I'm assigning this to you, let's get rid of the need for such workarounds!

[rgrinberg]

@cristianoc Is there a reason why you can't enable bytecode targets in your projects?

[cristianoc]

The ides is just to simplify the set-up instructions, so people can use their build with no changes. Not a huge deal, just a convenience.

[rgrinberg]

Thanks, that makes sense. For now I think the correct workaround is to tell people that disabling bytecode targets is a bad idea (for many reasons)

…

On Sep 8, 2020, 11:53 PM -0700, Cristiano Calcagno ***@***.***>, wrote: The ides is just to simplify the set-up instructions, so people can use their build with no changes. Not a huge deal, just a convenience. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or unsubscribe.