Set OCAMLTOP_INCLUDE_PATH (as in ocaml.5.3.*)
#22
Conversation
| [OCAML_TOPLEVEL_PATH = "%{toplevel}%"] | ||
| ] | ||
| x-env-path-rewrite: [ | ||
| [CAML_LD_LIBRARY_PATH (";" {os = "win32"} ":" {os != "win32"}) "target"] | ||
| [OCAMLTOP_INCLUDE_PATH (";" {os = "win32"} ":" {os != "win32"}) "target"] |
There was a problem hiding this comment.
Any reason why you don't do this for OCAML_TOPLEVEL_PATH ?
There was a problem hiding this comment.
It's not a PATH-like variable - it's only ever set using =
|
Unfortunately this does also trigger a rebuild of the |
|
That's not really different from a dune update :–) |
|
looks ok to me (although I don't have time to try to reproduce the conditions in which this is an issue) |
dra27
force-pushed
the
deploy-fix-25819
branch
from
b0632fd to
e30e484
Compare
OCAML_TOPLEVEL_PATH is left for now as ocamlfind's stub still uses it.
dra27
force-pushed
the
deploy-fix-25819
branch
from
e30e484 to
88f3b38
Compare
|
Following up on @kit-ty-kate suggestion, let's try to merge this at the same time as dune 3.18.0 is released |
Actually i'm not sure this will mitigate anything given the source of the issue (ocaml/opam#6455). We'll discuss this at the opam dev meeting on monday and report back a course of action. |
Extension of the setting of
OCAMLTOP_INCLUDE_PATHwhich was trialled with ocaml#26594.4.08.0 is the first version of the compiler supporting this environment variable. Updating the remaining packages mitigates the issue seen in dbuenzli/topkg#142 and reported in ocaml#25819 (comment).
Opened here for review, as the revdeps testing impact is obviously quite large...