How can I retrieve the direct dependencies between modules?

[esope]

Hi,
I'm trying to extend the dune describe command so that it also prints the (direct) dependencies between modules, so that this information can be exploited by external tools (as mentioned in issue#3425 and on this discuss thread).
I am starting with the modules of executables as a first step (leaving modules of libraries as a next step).
By navigating in dune sources, I found the following way to get the dependencies I'm interested in:

1. Retrieve the compilation_context using Exe_rules.rules
2. Get the dependencies of a given module using Ocamldep.deps_of

This strategy fails, however: calling Exe_rules.rules fails with the following error message

Internal error, please report upstream including the contents of _build/log.
Description:
  ("Implicit_output.produce called without any handler in dynamic scope",
  { type = "Rules" })
Raised at Stdune__Code_error.raise in file "otherlibs/stdune/code_error.ml",
  line 11, characters 30-62
Called from Fiber.O.(>>|).(fun) in file "src/fiber/fiber.ml", line 255,
  characters 36-41
Called from Fiber.Scheduler.exec in file "src/fiber/fiber.ml", line 878,
  characters 10-13
Re-raised at Stdune__Exn.raise_with_backtrace in file
  "otherlibs/stdune/exn.ml", line 36, characters 27-56
Called from Fiber.Scheduler.exec in file "src/fiber/fiber.ml", line 878,
  characters 10-13

Am I doing anything illegal? Do you see a way to circumvent this issue, or better way to retrieve the direct dependencies of a module?

Thanks!

[esope]

I also tried to call Ocamldep.read_deps_of, that returns a list of module dependencies, but I only get error reports of the form

Error: No rule found for .foo.eobjs/dune__exe__Foo.impl.all-deps

for executables, and

Error: No rule found for .foo.objs/foo.impl.all-deps

for libraries.
Do you have any clue for me?

EDIT: answer is given in the discussion below.

[esope]

Ok, I have made some progress.
I managed to get the direct dependency of some modules, at the expense of some code duplication from ocamldep.ml, as a first step.

I think I better understand the errors Error: No rule found for .foo.eobjs/foo.ml.d:
I was providing the correct directory. However, it seems there is indeed no rule to create such a file under several conditions.
For example:

1. When a library or an executable is composed of a single file foo.ml, no foo.ml.d is produced
2. When a file foo.ml has a preprocessor, no foo.ml.d is produced
3. When a file is generated (such as dune__exe__foo.ml or foo.ml-gen), it has no corresponding .ml.d file.

Is it correct that, in such cases, no rule is registered to produce the .ml.d file? Is it a bug?
How can I fix this, or implement a workaround?

[nojb]

1. When a library or an executable is composed of a single file foo.ml, no foo.ml.d is produced

I think this is due to #3847 cc @rgrinberg

[esope]

Thanks @nojb: this PR clarified many things for me.
I made the following choices, which seem to provide correct results (at the very least, crashes have disappeared):

1. Return an empty list of dependencies for singleton modules
2. When a file is subject to preprocessing, ask for the dependencies for the preprocessed file, instead dependencies of the source file
3. Return an empty list of dependencies for modules of kind Alias (if I understand correctly, these are the dune-generated files I was mentioning earlier)

Does this look OK to you @rgrinberg ?

I am still surprised that there is no ocamldep rule for files with preprocessors (that would be defined as an alias for the "real" ocamldep rule on the preprocessed file).

[rgrinberg]

Yes, you have the right idea. I suggest you factor out the code so that this logic is shared somewhat though.

I am still surprised that there is no ocamldep rule for files with preprocessors (that would be defined as an alias for the "real" ocamldep rule on the preprocessed file).

Why do you think we need such a rule? Note that we run the preprocessing step only once in dune before the dependency analysis. Therefore, you will only have dependencies of the post-processed files.

[esope]

OK, I submitted the proposed changes in PR#5412.

I was thinking of such a rule, because I would find it convenient to ask for the dependencies of some file regardless of whether it is subject to preprocessing: it is indeed dune's job to correctly call ocamldep on the preprocessed file, but it is not the user's job to think whether a file should be preprocessed, and then either look at foo.ml.d or at foo.pp.ml.d. But that's fine if we keep the current behavior.