obazl / tools_opam

Bazel rules for OPAM support
https://obazl.github.io/docs_obazl/
Eclipse Public License 2.0
5 stars 1 forks source link

handle `requires(-ppx_driver)` correctly #11

Open mobileink opened 2 years ago

mobileink commented 2 years ago

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.

mobileink commented 2 years ago

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.