[2/3] Restructure LIBDIR: Remove duplicate topdirs.cmi #11199
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the second PR in a series starting with #11198 which seek to separate the components in OCaml's
$LIBDIR
.In OCaml 4.00.0, the compiler's libraries started to be installed in
$LIBDIR/compiler-libs
. This created a small conundrum fortopdirs.cmi
as the toplevel and the debugger both require this signature to be available.Curiously, the debugger and toplevel were fixed in different ways. In #5647, the debugger directly enriches the environment with
topdirs.cmi
read fromcompiler-libs
(see fa0e0b6). This avoids having to add the whole of+compiler-libs
to the load path. However, 10 days later the toplevel was fixed with a slightly different sledgehammer in #5691 by putting a second copy oftopdirs.cmi
into$LIBDIR
, keeping the copy which used to be there in 3.12 and earlier (f786ea8). #827 somewhat needlessly duplicatestopdirs.cmt
,topdirs.cmti
andtopdirs.mli
in$LIBDIR
as well.The duplication of these files are in themselves something a smell (in fact, the presence of two identically named .cmi files upsets
ocamlfind
). This PR changes the toplevel to adopt the debugger's approach and enriches the environment withtopdirs.cmi
loaded from+compiler-libs
.This is done immediately after
Compmisc.init_path
for which are three cases:ocaml script.ml
orocamlnat script.ml
) inToploop.run_script
Topmain.main
Topeval.init
which is called at the initialisation ofToploop
. This, as the comment intoploop.ml
explains, is necessary or code linked together withocamlmktop
can't useTopdirs.dir_install_printer
At present, this PR requires a small patch to
utop
(to callTopcommon.load_topdirs_signature
) and, when it's updated for OCaml 5, Coq will require a similar patch for theDrop.
instruction incoqtop.byte
.It's tempting to move
Compmisc.init_path
out ofTopmain.main
and intoToploop.loop
, and so also put theTopcommon.load_topdirs_signature
there too. This would eliminate the need for patching Coq, certainly, but the code in utop serves as a reminder of why this (I think) is not a sound course of action: utop, for example, will drop intoToploop.loop
only on some code paths, so where it has (or at least should have) setup up the paths itself - and it would still need to callTopcommon.load_topdirs_signature
for the other code paths which don't go via the toplevel's own interactive loop.This PR includes two earlier commits: the first simply adds
+toplevel
and gets the toplevel to include that directory. Simple, but it doesn't fix the smell! The second commit assumes thattopdirs.cmi
will be in the load path and falls back to loading it manually otherwise and then the final commit goes all-in on the manual enrichment approach.The effect of this PR on the installation directory is that
topdirs.cmi
,topdirs.cmt
,topdirs.cmti
andtopdirs.mli
are no longer installed to$LIBDIR
. This change has no visible check in opam-health-check on OCaml 5.0 packages. A version of it in OCaml 4.14 revealed some problems with older packages, but all of those packages already require updating for OCaml 5.0.