Debugging build failures with implicit_transitive_deps false

[jberdine]

I'm wondering if there is standard advice on debugging build failures introduced by setting implicit_transitive_deps false? For example, I added that config to a project that includes a ppx rewriter and see:

Error: The module Selected_ast is an alias for module Ppxlib_ast__.Import.Selected_ast, which is missing

I suppose that by digging through the metadata files for ppxlib I would eventually find some library name to add to the stanza:

(library
 (name ppx_trace)
 (kind ppx_rewriter)
 (preprocess no_preprocessing)
 (libraries ppxlib))

But is there a better message that dune can give, since without disabling implicit_transitive_deps the build succeeds?

[ghost]

I had similar issues with Dune's own testsuite, since we use ppx_expect. I suppose Dune could try and find out which libraries provides the module. However, it would have to start by parsing the compiler's error message, which is not great :/

However, on the compiler side some people are thinking about a "hidden include" feature, that would allow some .cmi files to be seen by the compiler but not the user. With such a feature, (implicit_transitive_deps ...) should get much more usable.

[rgrinberg]

I suppose Dune could try and find out which libraries provides the module. However, it would have to start by parsing the compiler's error message, which is not great :/

On the other hand, I think that we need a path forward for this regardless. It would be quite handy if dune could automatically suggest which libraries must be included based on the module name. This would be a huge boost to usability I believe. However, I agree that parsing the compiler's error message sounds like a bad idea. Is there a plan to add structured error messages to the compiler perhaps?

Another idea is to have dune use ocamlobjinfo to figure out the actual dependencies of every library. Dune could do so with (implicit_transitive_deps true). Once this mapping is generated, dune can automatically fix the dependency list for every stanza. Unfortunately, this has some flows as I believe it will erroneously include dependencies provided via preprocessors or re-exported, but it should still be a decent start.

[ghost]

On the other hand, I think that we need a path forward for this regardless. It would be quite handy if dune could automatically suggest which libraries must be included based on the module name. This would be a huge boost to usability I believe. However, I agree that parsing the compiler's error message sounds like a bad idea. Is there a plan to add structured error messages to the compiler perhaps?

AFAIK, there is no such plan.

Another idea is to have dune use ocamlobjinfo to figure out the actual dependencies of every library. Dune could do so with (implicit_transitive_deps true). Once this mapping is generated, dune can automatically fix the dependency list for every stanza. Unfortunately, this has some flows as I believe it will erroneously include dependencies provided via preprocessors or re-exported, but it should still be a decent start.

That's an interesting idea, but given that hidden includes will make this problem mostly moot, it seems to me that the best thing to do here is just wait.