Add convenience targets for .cmx/.cmo?

[nojb]

What do you think about adding a convenience target in the source directory for .cmx and .cmo files? It is convenient in large codebases to check compilability of a single module without having to compile anything else. Right now one needs to know the library or executable the module belongs to in order to deduce the path in the build directory, which is not practical.

[ghost]

Initially we were generating these files in the source directory, then when we moved them to the object directory, we initially add copy rules for backward compatibility. We dropped these when switching to Dune as we observed that doing so resulted in a noticeable speedup. We could re-introduce them, but we'd have to make sure they don't slow down things.

Alternatively, one idea would be to have a notion of target proxies. I.e. we could use convenient target names that don't exist and Dune would print what they actually mean:

$ dune build src/file.cmx
src/file.cmx resolves to _build/default/src/.foo.objs/foo__File.cmx
  [...]
$ ls _build/default/src/.foo.objs/foo__File.cmx
_build/default/src/.foo.objs/foo__File.cmx

The main difference would be that the resolution of these names would be done lazily, while if we setup actual rules, we have to do more work eagerly.

[nojb]

Thanks for the explanation. I agree the lazy approach is better.

[rgrinberg]

Why can't you rely on merlin to check a single module?

I'm not a huge fan of introducing these targets because they're too low level. It's not really clear for a user when they should build the .cmo vs. the .cmx target to "error check" their module. Not to mention that these targets create even more backwards compatibility obligations for us.

I think if we really wanted something like it would be better to have aliases for these kinds of targets.

[ghost]

We just talked about this with @rgrinberg offline.

If these targets are only available from the command line, it doesn't create much backward compatibility obligations. But it's true that for someone who is not familiar with OCaml compilation, these might be hard to discover. Another possibility would be to have virtual targets for module names, i.e. dune build Foo.Bar would build the cmi for module Bar of library foo. This seems intuitive. Having both seems fine to me, so for instance if a user wanted to check module Bar of library foo in src/, they could do one of:

$ dune build src/.foo.objs/foo__Bar.cmi
$ dune build src/bar.cmi
$ dune build Foo.Bar

Similarly, dune build Foo could build all of library foo.

[rgrinberg]

I've written up an RFC for a more heavyweight but also more widely applicable solution here:

#1642

[nojb]

Coming back to this after after having experimented a bit more, I still think having a way for the command-line tool to build convenience names like foo.cmx (along the lines of @diml's suggestion) would be useful. Being able to build a module without having to know which library or executable it belongs to is a big plus in terms of convenience. (merlin is not always usable in our development setup.)

Unless there is strong opposition I will try to give this a shot whenever I get some free time.

[rgrinberg]

Okay, but diml's suggestion can be folded over into #1648 pretty easily. For example, we could have:

$ dune build module:Foo.Bar

Modules aren't the only alternative way of referring to build artifacts so let's be considerate of that.

Update: In fact you could also add support for $ dune build module:{byte,native}:Foo.Bar if you really want a way to build .cmo or .cmx files.

[ghost]

I suppose the two make sense: experts would likely prefer foo.cmx because that's what they are familiar with, while new OCaml users who don't know what a cmx is would likely prefer module:Foo.Bar because it talks more to them.

Personally, I'm fine with supporting both as long as introducing these convenient names doesn't impact performances of normal builds.