Original bug ID: 6795 Reporter:@whitequark Assigned to:@diml Status: closed (set by @xavierleroy on 2017-02-16T14:18:08Z) Resolution: fixed Priority: normal Severity: minor Target version: 4.03.0+dev / +beta1 Fixed in version: 4.03.0+dev / +beta1 Category: ~DO NOT USE (was: OCaml general) Has duplicate:#6996 Monitored by:@gasche@hcarty
Currently, if a rewriter returns an error, ocamldep blindly processes the [%%ocaml.error] node instead, and returns no dependency information at all, which causes the rest of compilation to fail in unexpected and confusing ways (no module found) if it does in fact depend on dependencies being present.
This happens with my package ppx_import.
The text was updated successfully, but these errors were encountered:
I'm not convinced that being stricter at what we accept won't break existing tooling in subtle way. The safest choice is probably to do exactly as for camlp4 here: what happens if ocamldep is called on a file whose preprocessor rejects?
I agree on principle on the idea of adding code to ocamldep to detect the specific error-return convention of -ppx. It's just that I don't know how robust or how fragile ocamldep is when dealing with camlp4 preprocessing errors, and I suggest to make it exactly as robust (and fragile) with ppx errors (recognized as such).