Comment author: @damiendoligez

I'd like to second this feature request. I have a program (tlapm) whose makefiles would benefit.

Comment author: @whitequark

Is this really a good idea? Most languages I know, starting with C, embed the full path to the module into the location. Not only this is much less ambiguous (where does this "src/cset.ml" come from?), but also easier to use by tools. ocamldebug in particular has to rely on a crutch to locate the sources, currently.

Comment author: @gasche

If/when we do this we probably want OCAMLPARAM handling as well.

Comment author: @diml

@whitequark: you can already do that in OCaml, just pass the full filename to ocamlc/ocamlopt instead of the relative one

@gashe: actually it's not obvious to me we want it in OCAMLRUNPARAM. This would be a per-file setting as it would always depend on the filename. Another possibility is to pass a format string.

Comment author: @whitequark

@dim, my point is that I think ocamlc should always expand the path, fixing this issue and others. Alternatively it could be an OCAMLPARAM setting (and possibly also a command-line switch) that forces path expansion, if the change would be too invasive otherwise--I think it's a much better solution than providing the ability to change the filename in arbitrary ways.

Comment author: @diml

Having the full path is indeed good for local development/debugging but it shouldn't be the default. For instance it is often wrong for binary distribution. Having it as an OCAMLPARAM setting seems good, but it doesn't supersede this feature. This is really for projects that don't run all tools from their root directory.

Comment author: @whitequark

The current behavior is also incorrect for binary distribution (or anything really), because it does not allow to unambiguously locate the source. Ideally, the path would include the package name and then the path from the root of the package.

Hm, and your suggestion actually handles that. Perhaps it is a good idea after all.

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

Still an issue.

cc @jeremiedimino

I guess that'd still be useful, though I ran out of steam on this one. Additionally, since Dune run compilation commands from the root of the workspace it is less of an issue for Dune projects and so this seems less high priority to me.

Unless someone wants to take ownership of this, I'll leave the stable label and let the issue get closed.

I removed the newcomer-job tag though because it's not that simple.

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.