Comment author: @xavierleroy

Installing more of / all of the compiler interfaces is being considered.

For your second wish (dynlink / toplevel compatibility), this raises some non trivial issues. Could you please tell us more about the usage scenario(s) that you have in mind?

Comment author: gerd

In GODI we install the compiler interfaces in a separate directory. This turned out as very helpful - some packages interacting deeply with the compiler can now be built without requiring the full ocaml sources.

I'd suggest to put them simply into a subdir of the stdlib.

Comment author: @zoggy

About dynlink/toplevel compatibility, I encountered the problem twice:

1. In Chamo: this is a source code editor in ocaml, able to evaluate ocaml code to perform some operations (à la emacs) and able to load plugins, too.
2. In Stog, a static web site generator, able to evaluate ocaml code and display (or not) the toplevel result, for example to show real examples, tested when the site is compiled; Stog also offers the possibilty to load plugins to define new callbacks associated to some tags.

A workaround exists: in bytecode version, rather than linking with dynlink, I load plugins with Topdirs.load_file. But it complicates the build process.

In native code versions, no problem since toplevellib.cmxa does not exist. Would it be hard to have a native version of the toplevel ?

Comment author: @protz

Moving to acknowledged since we probably want to package the compiler modules somehow.

Comment author: @xavierleroy

First wish (install more of the compiler internals) granted in 4.00.

Second wish (toplevel & dynlink that work together well) needs more work.

Comment author: @bobzhang

another use case for mixing dynlink with toplevellib, is that you can do some compile-time evaluation like D language, that's to say the user can specify which part of the program should be evaluated at compile time.

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.