From: "Armaël Guéneau" <armael.gueneau@ens-lyon.fr>
To: Jeremie Dimino <jdimino@janestreet.com>
Cc: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] Custom toplevel and ocamlbuild
Date: Tue, 24 Nov 2015 17:52:26 +0000 [thread overview]
Message-ID: <5654A3DA.7000503@ens-lyon.fr> (raw)
In-Reply-To: <CANhEzE4UzneRYFz2HEaivesSqxeUuF+UHys6KsE+1j4ki8kfGA@mail.gmail.com>
[-- 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 --]
prev parent reply other threads:[~2015-11-24 17:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-24 16:58 Armaël Guéneau
2015-11-24 17:14 ` Jeremie Dimino
2015-11-24 17:42 ` Armaël Guéneau
2015-11-24 17:48 ` Jeremie Dimino
2015-11-24 17:52 ` Armaël Guéneau [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5654A3DA.7000503@ens-lyon.fr \
--to=armael.gueneau@ens-lyon.fr \
--cc=caml-list@inria.fr \
--cc=jdimino@janestreet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox