You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently @obazl//convert:dune can handle these in some cases but not all. Dependency on ppx_inline_test is not always directly expressed by dune stanzas. For example, ppx_bench/example/dune has:
and the ppx_bench library (//src:ppx_bench) depends on @ppx_inline_test//lib/libname. So in order to discover the dependency we would have to inspect everything in the (preprocess (pps ...)) directive. The mibl data has all the required info, but implementing the search will be a PITA.
That would work internally for ppx_bench. But if some other project were to depend on an opam package that depends on ppx_inline_test, we would have no way of discovering the dependency short of crawling around in the opam dependency graph.
We need to discover the dependency because it means we need to add ["-inline-test-lib", "foo"] to the ppx_args attribute wherever a ppx transform uses the lib in question. So we see module FOO needs ppx.exe, which depends on ppx_bench, which depends on ppx_inline_test.
We currently do not have this capability. To add it we would need a library, but if we used an ocaml lib we would have a bootstrapping problem. We do not want @obazl//convert to depend on an ocaml toolchain.
Ooops, spoke too soon. ppx_bench.opam does list ppx_inline_test in its depends: clause. So maybe we can address this by adding opam file parsing to the converter.
Another alternative is to inspect the dune-package file that gets added to the pkg directory in the switch. For ppx_bench it contains:
So the BUILD.bazel file produced by @obazl//coswitch:refresh has this info. To obtain it for the converter, we would need to read either the META file or the BUILD.bazel file from the coswitch.
Reading the META files would only work for installed opam pkgs. What about e.g. a company's internal pkg that is not on opam? In that case its dune files would have to explicitly list ppx_inline_test as a dependency?
Currently
@obazl//convert:dune
can handle these in some cases but not all. Dependency onppx_inline_test
is not always directly expressed by dune stanzas. For example, ppx_bench/example/dune has:and the ppx_bench library (
//src:ppx_bench
) depends on@ppx_inline_test//lib/libname
. So in order to discover the dependency we would have to inspect everything in the(preprocess (pps ...))
directive. The mibl data has all the required info, but implementing the search will be a PITA.That would work internally for ppx_bench. But if some other project were to depend on an opam package that depends on ppx_inline_test, we would have no way of discovering the dependency short of crawling around in the opam dependency graph.
We need to discover the dependency because it means we need to add
["-inline-test-lib", "foo"]
to theppx_args
attribute wherever a ppx transform uses the lib in question. So we see module FOO needs ppx.exe, which depends on ppx_bench, which depends on ppx_inline_test.We currently do not have this capability. To add it we would need a library, but if we used an ocaml lib we would have a bootstrapping problem. We do not want
@obazl//convert
to depend on an ocaml toolchain.Ooops, spoke too soon.
ppx_bench.opam
does listppx_inline_test
in itsdepends:
clause. So maybe we can address this by adding opam file parsing to the converter.Another alternative is to inspect the
dune-package
file that gets added to the pkg directory in the switch. For ppx_bench it contains:The text was updated successfully, but these errors were encountered: