Comment author: @gasche

This looks like an ocamldep bug. I'm not opposed to adding -dsource for debuggability, but if you're going to have to change the ocamldep sources to fix the issue anyway, why not directly dive in and debug it by temporarily instrumenting it with an extra print-ast call?

Comment author: @whitequark

I've changed my code since then, and I did not have time to debug ocamldep at the moment. So I filed the bug to at least simplify debugging for whoever encounters this next.

Comment author: @damiendoligez

I don't think this is pressing enough that it should go into 4.02.2. Speak up if you disagree.

Comment author: @alainfrisch

GitHub PR welcome!

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.

Does ocamldep really need to have a duplicate -dsource/-dparsetree options? Using ocaml{c,opt} to get the post-processed AST should work fine, isn'it?

Yes. The problem is that some ppx extensions (ones that read generated files, like .cmi or .cmt) have to return different parsetrees depending on whether they run as a part of ocamldep or ocamlc, since the generated files may not have been generated yet. Admittedly an obscure use case.

If your ppx have two modes, couldn't you just run the ppx in an ocamldep-debug mode with ocamlc -dsource and debug from that point? This certainly more convoluted than a -dsource option in ocamldep, but the issue seems quite specific. How common is it for a ppx to run into this constraint and related issue?

Probably not common at all. @gasche thought this is an issue; if you'd like to close this as something upstream isn't interested in, I'm not strongly opposed.

I think it is best to close the issue for now as a too specialized issue for adding a generic flag to ocamldep. If the issue rears it head again, we will reopen it with more data points proving that the issue is not that uncommon.

I think ocamldep should, morally speaking, have had that flag in first place (like any other tool that processes OCaml source and runs ppx extensions!) but no objection to closing.