Re: [Caml-list] Custom toplevel and ocamlbuild

["Armaël Guéneau" <armael.gueneau@ens-lyon.fr>]

[-- Attachment #1: Type: text/plain, Size: 3813 bytes --]

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



[-- Attachment #2: Type: text/html, Size: 5291 bytes --]