Using findlib, -ppx_driver means "NOT a ppx_driver", meaning use this as a "normal" dep, not a ppx dep. I think.
So in such cases we need two build targets, for for ppx and one not. Currently we only have one, for ppx.
Examples: ppx_bin_prot, ppx_expect
ppx_expect META:
# This is what dune uses to find out the runtime dependencies of
# a preprocessor
ppx_runtime_deps = "ppx_expect.collector ppx_expect.config"
# This line makes things transparent for people mixing preprocessors
# and normal dependencies
requires(-ppx_driver) = "ppx_expect.collector
ppx_expect.config
ppx_here.runtime-lib
ppx_inline_test.config
ppx_inline_test.runtime-lib"
ppx(-ppx_driver,-custom_ppx) = "./ppx.exe --as-ppx"
library_kind = "ppx_rewriter"
From this we emit ppx_codeps = ["@ppx_expect//collector", "@ppx_expect//config"] because of the ppx_runtime_deps entry, but we don't handle the requires(-ppx_driver) correctly, nor the ppx(...) entry.
In the meantime: this does not prevent the user from using the lib, it just means the deps may need to be hand-tuned.
One possibility: currently we use @foo//:foo, which we can abbreviate as @foo (seems to work). We could use that for the "normal" dep. For ppx we can use @foo//:ppx.
Using findlib,
-ppx_driver
means "NOT a ppx_driver", meaning use this as a "normal" dep, not a ppx dep. I think.So in such cases we need two build targets, for for ppx and one not. Currently we only have one, for ppx.
Examples: ppx_bin_prot, ppx_expect
ppx_expect META:
From this we emit ppx_codeps = ["@ppx_expect//collector", "@ppx_expect//config"] because of the
ppx_runtime_deps
entry, but we don't handle therequires(-ppx_driver)
correctly, nor theppx(...)
entry.In the meantime: this does not prevent the user from using the lib, it just means the deps may need to be hand-tuned.