How does a library B express its internal dependency on library A, so that a user C can use B without knowing about A?
The case at hand is ocaml-ctypes, which depends on ocaml-integers. A public header in ocaml-ctypes includes a public header from ocaml-integers (ctypes_primitives.h includes ocaml_integers.h).
Then there is luv, which uses ocaml-ctypes directly (by including ctypes_cstubs_internals.h in some C source file.), but not ocaml-integers - because that is an internal dependency of ocaml-ctypes.
Since dune is apparently not aware of the dependency of B to A, the C stubs build includes only the include path to B, the include path to A is missing.
A workaround in user C may look like this:
--- ocaml-luv-0.5.7.orig/src/c/dune
+++ ocaml-luv-0.5.7/src/c/dune
@@ -117,6 +117,7 @@ let () = Jbuild_plugin.V1.send @@ {|
(deps (:c generate_types_step_2.c) helpers.h shims.h)
(action (bash "\
%{cc} %{c} \
+ -I '%{lib:integers:.}' \
-I '%{lib:ctypes:.}' \
-I %{ocaml_where} \
|}^ i_option ^{| -o %{targets}")))
But, now that I look at the patch, this cmdline is all manually constructed, so little dune can actually do.
The question still stands: does dune actually know that B depends on A, and would it add the include path to A when B is used?
2 posts - 2 participants