Skip to content

OCAMLPATH value when ocamlfind is vendored #4196

@emillon

Description

@emillon

Hi,

While testing #3956 we noticed some strange behavior when ocamlfind is part of the workspace. The exact issue is described at
https://github.com/NathanReb/test-new-mdx-stanza.

After debugging with @NathanReb, it seems that the core of the issue is how OCAMLPATH is set by dune. This variable defines where ocamlfind looks for packages (or something related to that question). In a pure opam context, opam-switch/lib seems to be correct. dune sets it to _build/install/default/lib which corresponds to the "compiled version of the dune workspace".

; extend_var "OCAMLPATH" ~path_sep:ocamlpath_sep local_lib_root

The question is how can an ocamlfind that is part of the workspace access packages installed in a local opam switch?

In https://github.com/realworldocaml/book, we were not seeing any issues because the mdx stanzas have a dependency on (package mdx) and so everything was copied under _build/install/default/lib. In the minimum working example above, it is possible to "fix" the test by adding (deps (package findlib)) which copies all the findlib definitions at the place where findlib will look for them, but it seems that it should not be necessary.

I tried adding default_ocamlpath (as defined above - in the opam2 situation it's opam-switch/lib) to OCAMLPATH:

let* default_ocamlpath, (ocaml_config_vars, ocfg) =

This fixes the mdx situation but I'm not sure it's the right one.

What do you think @jeremiedimino @rgrinberg @bobot ?

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions