Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Caml-list] Toplevel - loading dependencies

0 views
Skip to first unread message

Dawid Toton

unread,
Jan 9, 2009, 9:23:46 AM1/9/09
to caml...@yquem.inria.fr
Another problem with loading modules in the toplevel:
I need to use the module A. So I write:
#load "A.cmo"
to get a messsage "Reference to undefined global B"
So I prepend a line:
#load B.cmo
and get another "undefined global". Then it repeats prohibitively many
times.
This is resolving dependencies by hand, one by one.

The solution would be to have a special version of cmo that knows
locations of all other cmo's it depends on.

In special cases I could use cma archives, but this is only applicable
when there is well defined and stable set of modules I need.
But in practice the modules I use in ocaml scripts are constantly
evolving. It leads to having multiple cma aggregates and maintaining
their building description. Again, lots of work.

If I put everything into one big cma, then I have to recompile it every
small change. It takes so long time, that it would make no sense to use
the interpreter at all.

Could I ask ocamlbuild to produce proper loading preamble for my scripts?

What is the right solution?

Dawid

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Matthieu Dubuget

unread,
Jan 9, 2009, 9:35:29 AM1/9/09
to caml...@inria.fr
Dawid Toton a écrit :

> What is the right solution?

What about camlfind?

Salutations

Matt

Florent Monnier

unread,
Jan 9, 2009, 12:15:44 PM1/9/09
to caml...@yquem.inria.fr
> If I put everything into one big cma, then I have to recompile it every
> small change. It takes so long time, that it would make no sense to use
> the interpreter at all.

in case you're doing so this way:
ocamlc -o my.cma mod1.ml mod2.ml mod3.ml mod4.ml

this will recompile everything,
but you can use in your makefile:
%.cmo: %.ml
ocamlc.opt -c $<
my.cma: mod1.cmo mod2.cmo mod3.cmo mod4.cmo
ocamlc.opt -a -o $@ $^

then you don't recompile everything, only the modified module

if there are dependencies between modules, just add additional rules:
modfoo.cmo: modfoo.ml modbar.cmi

Peng Zang

unread,
Jan 9, 2009, 12:53:30 PM1/9/09
to caml...@yquem.inria.fr, Dawid Toton
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Shouldn't ocamldep be able to solve this? It can read a source file and
figure out the dependencies. So you could in theory generate a fake source
file that is just "open A" and it should figure out the set of dependencies
for module A.

Peng

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFJZ48PfIRcEFL/JewRAvcBAJ93neP1/3O6GCqImp4PP/UPTd/iCACfeyTn
zFNLx2UjBo6pkgb9z3a0NPk=
=6+qX
-----END PGP SIGNATURE-----

Dawid Toton

unread,
Jan 9, 2009, 1:13:21 PM1/9/09
to caml...@yquem.inria.fr
> in case you're doing so this way:
> ocamlc -o my.cma mod1.ml mod2.ml mod3.ml mod4.ml
>
> this will recompile everything,
> but you can use in your makefile:
> (...)

> then you don't recompile everything, only the modified module
>

Yes, with ocamlbuild I need not to recompile everything, but it's slow
traversing even nothing-to-be-done tree:

Finished, 432 targets (411 cached) in 00:00:08.

It takes already 8 seconds if nothing is touched.

If I edit few files, it's worse:

Finished, 432 targets (256 cached) in 00:00:49.

I'm looking for alternatives.

That's why I try with scripting: keep core libraries compiled and run
outermost parts with an interpreter.

Another idea is to change ocamlbuild to work dynamically: keep the
dependency tree in memory and update it from time to time, watching
files on disk.

Dawid

0 new messages