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 > > >
>>
>>
>
>
>