Conversation
| (deps (tests.mlt | ||
| (glob_files ${SCOPE_ROOT}/src/*.cmi) | ||
| (glob_files ${SCOPE_ROOT}/vendor/re/*.cmi) | ||
| (glob_files ${SCOPE_ROOT}/src/.jbuilder.objs/*.cmi) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
| | Cmi | Cmo -> extra_targets | ||
| | Cmx -> | ||
| Path.change_extension ~ext:ctx.ext_obj (Module.cm_file m ~obj_dir Cmx) :: extra_targets, | ||
| Path.change_extension ~ext:ctx.ext_obj (Module.cm_file m ~obj_dir:dir Cmx) :: extra_symlinks |
There was a problem hiding this comment.
What about Module.obj_file ~obj_dir ~ext:ctx.ext_obj?
| in | ||
| let old_dst = Module.cm_file m ~obj_dir:dir cm_kind in | ||
| if obj_dir <> dir then begin | ||
| SC.add_rule sctx ?sandbox (Build.symlink ~src:dst ~dst:old_dst) ; |
| let fn2 = Option.value_exn (Module.cmt_file m ~obj_dir:dir ml_kind) in | ||
| (fn :: extra_targets, fn2 :: extra_symlinks, A "-bin-annot") | ||
| in | ||
| let old_dst = Module.cm_file m ~obj_dir:dir cm_kind in |
| if obj_dir <> dir then begin | ||
| SC.add_rule sctx ?sandbox (Build.symlink ~src:dst ~dst:old_dst) ; | ||
| List.iter2 extra_targets extra_symlinks ~f:(fun src dst -> | ||
| SC.add_rule sctx ?sandbox (Build.symlink ~src ~dst)) |
There was a problem hiding this comment.
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
...
| (deps (tests.mlt | ||
| (glob_files ${SCOPE_ROOT}/src/*.cmi) | ||
| (glob_files ${SCOPE_ROOT}/vendor/re/*.cmi) | ||
| (glob_files ${SCOPE_ROOT}/src/.jbuilder.objs/*.cmi) |
There was a problem hiding this comment.
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.
|
I'm a bit puzzled by the build error of Camomile on OSX: the compiler seems to be picking up the wrong cmi file |
|
|
|
I had a look at the Camomile build failure. I looked at the compiler code and when typing I guess the change of include paths somehow disturb this lookup. Sometimes we pass |
|
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. |
|
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 |
No description provided.