Implement #427

[hnrgrgr]

No description provided.

[bobot]

Since writters of dune files needs to know about the location of the files we need to document it. However it could complicate automatic dune file migration if in a new version of the format/tool we change the destination directory. Is it really problematic? What are the solutions?

I would propose to export in some way the lib_obj_dir function if we had a syntax for calling builtin function: (glob_files ${lib_obj_dir ${SCOPE_ROOT}/src/ jbuilder}/*.cmi}). And it is even more complicated with private module. So perhaps a better possibility: (glob_cms ${SCOPE_ROOT}/src jbuilder *.cmi) which would also match the private directory if needed.

[hnrgrgr]

For the compatibility with current dune files, I just pushed a second patch where bar.cmi is a symlink towars .foo.objs/bar.cmi. But this is probably better to export a lib_obj_dir or glob_cms.

[ghost]

We already have an alias to denote all the cmY files of a library, we could just document it.

But there are also users who are calling jbuilder build src/blah.cmo directly (this was mentioned in some ticket recently), so in any case the symlink method seems good for now.

[ghost]

What about Module.obj_file ~obj_dir ~ext:ctx.ext_obj?

[ghost]

You can remove the ?sandbox for symlinks

[ghost]

This should do inside the if obj_dir ...

[ghost]

Instead of carefully building the two lists symmetrically, what about just building the list of targets as a string list (it would just be the filenames), then at the end we do:

let targets  = List.map target_filenames ~f:(Path.relative ~dir:obj_dir) in
let symlinks = List.map target_filenames ~f:(Path.relative ~dir) in
...

[ghost]

We already have an alias to denote all the cmY files of a library, we could just document it.

But there are also users who are calling jbuilder build src/blah.cmo directly (this was mentioned in some ticket recently), so in any case the symlink method seems good for now.

[ghost]

I'm a bit puzzled by the build error of Camomile on OSX:

      ocamlc Camomile/.camomile.objs/uChar.{cmo,cmt} (exit 2)
(cd _build/default && /Users/travis/ocaml/bin/ocamlc.opt
  -I Camomile -w -40 -g -bin-annot
  -I /Users/travis/ocaml/lib/ocaml -no-alias-deps
  -I Camomile/.camomile.objs
  -o Camomile/.camomile.objs/uChar.cmo
  -c -impl Camomile/uChar.ml)
File "Camomile/uChar.ml", line 1:
Error: Wrong file naming: /Users/travis/ocaml/lib/ocaml/uChar.cmi
contains the compiled interface for 
Uchar when UChar was expected

the compiler seems to be picking up the wrong cmi file

[ghost]

jbuilder rules _build/default/Camomile/.camomile.objs/uChar.cmo might be useful to debug the actual rule that's generated

[ghost]

I had a look at the Camomile build failure. I looked at the compiler code and when typing <file>.ml, the compiler looks for <module-name>.cmi in the load path. I would have thought that it would just derive the cmi filename from the -o option but no....

I guess the change of include paths somehow disturb this lookup. Sometimes we pass -I <stdlib-dir>, and filtering it out solves the issue. I'll create a PR to do this change.

[ghost]

The code has changed quite a bit and I realize it's not really fair to ask you to do the rebase work since I asked you about this in the first place, so I'm going to rebase and merge this feature manually.

[ghost]

I manually merged this in master. The main change I did was to store artifacts of executables in a separate directory as well. I used .<first-executable-name>.eobjs for the object directory name.