ocaml/dune

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

cristianoc opened this issue · 10 comments

cristianoc commented

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
Deleted user commented

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 commented

@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.

Deleted user commented

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.

  • 👍1
Deleted user commented

@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 commented

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.

Deleted user commented

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

rgrinberg commented

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

cristianoc commented

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 commented
andreypopp commented

In our projects we rely on dune build ./prog.exe invocations (or aliases set to build .exe). This results in broken merlin/ocamllsp experience as .cmt is missing (for example jump to definition jumps to .mli instead of .ml).

The current workaround we use is to build dune build ./prog.exe @./check so .cmt files are produced.

This is suboptimal for two reasons at least:

  • We overbuild e.g. .cmo being produced to produce .cmt instead of producing .cmt while building .cmx
  • Extra complexity in setting up aliases or crafting build invocations.

I wonder if we can fix these two items.