Switches are configured with `OCAML_TOPLEVEL_PATH` but the variable name is `OCAMLTOP_INCLUDE_PATH`

[dbuenzli]

I was trying to change omod and down to stop pooping omod.top and down.top into ocaml's library directory and leave it for $(opam var lib)/toplevel to handle it.

This should be possible since OCaml 4.08.0 when https://github.com/ocaml/ocaml/issues/7808 was resolved by @nojb's https://github.com/ocaml/ocaml/pull/1841.

Unfortunately the compilers packages set the OCAML_TOPLEVEL_PATH instead of OCAMLTOP_INCLUDE_PATH so that doesn't work.

Not sure exactly who's responsible for opam compiler packages so I tentatively cc @Octachron and @dra27.

# With a down modified to no longer install `down.top` in $(opam var lib:ocaml)

> OCAML_TOPLEVEL_PATH=/Users/dbuenzli/.opam/4.14.2/lib/toplevel ocaml -noinit 
OCaml version 4.14.2
Enter #help;; for help.

# #use "down.top";;
Cannot find file down.top.
# ^D
> OCAMLTOP_INCLUDE_PATH=/Users/dbuenzli/.opam/4.14.2/lib/toplevel ocaml -noinit
OCaml version 4.14.2
Enter #help;; for help.

# #use "down.top";;
Down v0.3.0-5-g8eef77b loaded. Type Down.help () for more info.
# 

[dra27]

Not sure exactly who's responsible for opam compiler packages so I tentatively cc @Octachron and @dra27.

Suggests that I really should move on getting the precise value in https://github.com/dra27/opam-repository/commit/7813e70e155ac3a9c11927ab40b620d7741117d4 sorted out and upstreamed 🙂

[dbuenzli]

@dra27 do you have an ETA on that one ? I should likely do an omod and down release and I would have liked to stop installing stuff in OCaml's library directory.

[dra27]

Sorry for the slowness, I've at least updated ocaml.5.3.0 to support it (would you be able to test that with omod and down versions which do install to %{toplevel}% instead?). Updating the older ocaml packages triggers mass switch rebuilds, but the time to do that might be at a point where that's going to be happening anyway (e.g. the next Dune release, which I imagine won't be too far away). There's then the matter of updating the ocamlfind package to stop installing the ocaml shim both because it doesn't work on Windows and because with that change it becomes unnecessary to have it at all (finally).

[dbuenzli]

@dra27 thanks for your answer which it seems I missed (or didn't get notified of). I will try to test that things work when the first 5.3.0 betas get out.

[dbuenzli]

@dra27, it seems this is creating mayhem :–(

ocamlfind installs a stub for ocaml which uses the (wrong) variable $OCAML_TOPLEVEL_PATH. Since that is no longer set by the ocaml packages in 5.3 we get a mixup somewhere. Leading to this report in topkg.

The ocamlfind stub looks wrong anyways (-I) does not accept path like directories. OCAMLTOP_INCLUDE_PATH was introduced in 4.08 I suggest simply not installing the stub after that.

But perhaps the emergency fix is to set both OCAMLTOP_INCLUDE_PATH and $OCAML_TOPLEVEL_PATH in the 5.3 compilers.

[dra27]

But perhaps the emergency fix is to set both OCAMLTOP_INCLUDE_PATH and $OCAML_TOPLEVEL_PATH in the 5.3 compilers.

But it already is?

https://github.com/ocaml/opam-repository/blob/aa131f3eda80ed7121debe7582faaf50448bc105/packages/ocaml/ocaml.5.3.0/opam#L27-L33

[dra27]

We should almost certainly change this line in the ocamlfind.1.9.6 and earlier: https://github.com/ocaml/opam-repository/blob/aa131f3eda80ed7121debe7582faaf50448bc105/packages/ocamlfind/ocamlfind.1.9.6/opam#L35 to be {ocaml:preinstalled && ocaml:version < "5.3.0~~"} (xref #27253), but this is for system compilers only already?

[dbuenzli]

So perhaps it's rather that when a user switches to a switch with < 5.3 the OCAMLTOP_INCLUDE_PATH is not undone but actually meaningful to the ocaml of a [4.08;5.3[ switch and thus brings the confusion.

So in this case the fix would be rather to also set OCAMLTOP_INCLUDE_PATH on all the compiler switches.

[dra27]

I think so, yes (we just posted the same analysis on opposite issues!). Setting OCAMLTOP_INCLUDE_PATH was already planned, it was just waiting for #27302.

[dra27]

(just preparing the PR)