ocamlmktop support?

[dra27]

I'm not sure what the best route for this is - perhaps a toploop stanza?

For opam-admin.top, I have patched its main module to call Topmain.main () at the end and then simply link with compiler-libs.toplevel and add (ocamlc_flags (-linkall). Even this approach has problems, as there's no way to indicate to jbuilder that the executable in question must be bytecode (at least for now).

[rgrinberg]

I'm not sure what the best route for this is - perhaps a toploop stanza?

Would it be possible to just request a toploop target from jbuilder? E.g. $ jbuilder build lib.toploop.bc or something?

[dra27]

Could be - although it would be nice for the normal jbuilder build incantation to be able to do the right thing (which I think that wouldn't permit?!).

jbuilder always creates two targets for executables: name.exe and name.bc. It builds none be default, just the ones needed by other rules or for installation. When adding (public_name name) jbuilder will select the .exe (which will be the bytecode with -custom when native compilation is not available).

To install the byte-code, you can simply add an explicit install stanza, that's what utop does for instance: https://github.com/diml/utop/blob/master/src/top/jbuild#L20.

I guess we could have a (modes ...) field as for libraries to select what will be installed by default.

Regarding adding a stanza for toplevel, I'm not entirely sure. There are many case where you want to create a toplevel-like executable where Topmain.main () is not the entry point. There is such an example in jbuilder itself: https://github.com/janestreet/jbuilder/blob/master/test/expect-tests/jbuild#L3.

I guess if this is a recurrent pattern we can add a specific stanza, but in the meantime maybe just an example in the quick-start will do?

[dra27]

@diml - ah, I hadn't considered doing it via an install stanza, I was getting hung up on public_name in executable not allowing me to specify which I was after. The problem IIRC was the definition of "native compilation not available" - in this case, the build just failed because there're no native code versions of the toplevel library (rather than falling back to using the bytecode compiler).

I agree with you - I think an example solves it (I didn't think to look at utop...). Cases like the one you show are still fine, of course - however, it's possibly still a good aspiration to be able to run ocamlmktop - adding Topmain.main () isn't the "official" way to create a custom toplevel, right?

The problem IIRC was the definition of "native compilation not available"

Indeed, I clarified this. Detecting that a dependency is not available in native mode would be possible but it'd require more work.

I agree with you - I think an example solves it (I didn't think to look at utop...). Cases like the one you show are still fine, of course - however, it's possibly still a good aspiration to be able to run ocamlmktop - adding Topmain.main () isn't the "official" way to create a custom toplevel, right?

I think ocamlmktop mostly exists for historical reasons, as before the compiler libraries where not distributed. If we added a toplevel stanza, it would be a lot simpler to make it a syntactic sugar for (executable ...) rather make it call ocamlmktop, since you'd have to make sure not to link the compiler libraries twice.

In the meantime I added a (modes (...)) field to executable stanzas and an example in the quick start. Let's see how it goes for now, if we need that often I'll add a toplevel stanza.

I'm closing this since there is now enough in jbuilder to define and install toplevels

[andreypopp]

I think it is still would be useful to have a command in jbuilder to launch toplevels configured with the right directories.

Right now to experiment in REPL I need top/main.ml, top/jbuild and .ocamlinit and a command (quite long) to launch a toplevel.

Instead I think it would be useful just to have jbuilder repl command or something like that.

Thoughts?

@andreypopp see #114