I see. That was it, indeed.

Thanks a lot for the answers!

On 24/11/15 17:48, Jeremie Dimino wrote:
> It might be to do with where foo.cmi ends up. When using ocamlbuild it > will be in _build while when running the command manually it will be > in the current directory. Toplevels are not standalone, they need to > read the .cmi files at runtime. The cmi files are located by the OCaml > compiler using a search path. > > Try running myutop.top as follow after building it with ocamlbuild: > >     ./myutop.top -I _build > > Alternatively you can also use `#directory "_build";;` from inside the toplevel. > > On Tue, Nov 24, 2015 at 5:42 PM, Armaël Guéneau > <armael.gueneau@ens-lyon.fr> wrote: >> It sounds better to put "Foo" at the beginning of myutop.mltop >> indeed! However, it still doesn't work here (same thing, the >> toplevel cannot access Foo). >> >> What is super super weird is that if I manually run the build commands >> _that ocamlbuild lists in the terminal_, which are: >> >>    ocamlfind ocamlc -c -thread -package threads,utop -o foo.cmo foo.ml >>    ocamlfind ocamlc -c -thread -package threads,utop -o myutop_main.cmo >> myutop_main.ml >>    ocamlfind ocamlmktop -linkpkg -thread -package threads,utop -package >> threads,utop foo.cmo myutop_main.cmo -o myutop.top >> >> this time, it works... >> >> This smells like $PATH issues or something related to my setup, but I >> triple-checked and I don't see where this could come from... >> >> On 24/11/15 17:14, Jeremie Dimino wrote: >>> Did you try adding "Foo" at the beginning of myutop.mltop? foo.cmo > needs >>> to come before myutop_main.cmo and I suppose that ocamlbuild > puts the cmo >>> in the same order as the one specified in the .mltop > unless the >>> dependencies force reordering. > > The reason foo.cmo needs to come before >>> is that OCaml run the > initialization code of linked compilation units in >>> the same order they > are specified on the command line and the toplevel can >>> only see > modules that have been initialized. > Myutop_main contains the >>> entry point of the toplevel - i.e. the call > to the interactive loop - so >>> the toplevel doesn't have access to units > that are linked after >>> myutop_main.cmo. That's also the reason why you > can't access Myutop_main >>> from the custom toplevel. > > On Tue, Nov 24, 2015 at 4:58 PM, Armaël >>> Guéneau > <armael.gueneau@ens-lyon.fr> wrote: >> Hi list, >> >> I was trying >>> to build a custom toplevel, bundled with my custom >> modules, and >>> encountered a few issues. >> >> Following the last advice given by gasche on >>> this reddit post >> >>> https://www.reddit.com/r/ocaml/comments/3qjs1q/utop_is_a_much_better_toplevel_than_ocaml_if_you/cwisrrj >>>>> I copy-pasted the files from examples/custom-utop, added a foo.ml file >> >>> containing "let x = 3", and added "Foo" at the end of myutop.mltop. >> >> >>> Then, if I compile the custom toplevel using the provided Makefile >> (which >>> simply uses ocamlbuild and the builtin rule for .mltop files, I >> guess), >>> the toplevel produced does not have access to the Foo module. >> >> However, >>> if I manually build using ocamlfind ocamlmktop: >> >>   ocamlfind ocamlmktop >>> -o myutop -thread -linkpkg -package utop foo.cmo >> myutop_main.cmo >> >> >>> this time, it works, and `myutop` has access to Foo. >> >> Is the default >>> ocamlbuild rule for building .mltop files missing some >> option?  Am I >>> doing something wrong? >> >> — Armaël >> >> -- >> Caml-list mailing list. >>> Subscription management and archives: >> >>> https://sympa.inria.fr/sympa/arc/caml-list >> Beginner's list: >>> http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: >>> http://caml.inria.fr/bin/caml-bugs > > > >> >> > > >