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

[Caml-list] ocamlbuild and packs

32 views
Skip to first unread message

Romain Bardou

unread,
Jan 31, 2008, 6:54:13 AM1/31/08
to caml...@inria.fr
Hello,

I have this big project I work on, which could be summarized like this:

module A
module bla/A
module bla/B
module Main

The module B in the bla directory depends on the module A of the bla
directory. The module Main depends on both modules A and on module B.
For some reasons I cannot rename either of the modules.

So what I do is pack A and B in a Bla module, so I can write Bla.A and
Bla.B, using the -pack command line option. It works with my Makefile.

Now I try to use ocamlbuild, because I really like its approach (I come
from the Pascal world where no makefile is needed). So I made this file
bla.mlpack containing the lines:

A
B

Now if I compile using:

ocamlbuild Main.byte

I get the following error:

Unbound module Bla.A

I can't compile using:

ocamlbuild -I bla Main.byte

Because now the module A is defined twice.

So I tried to compile using two steps: first, compile bla.cmo, and then,
compile Main.byte, but ocamlbuild doesn't seem to be good at that (and
actually that's not a bad thing imo). Indeed, if I do:

ocamlbuild bla.cmo

I get the following error:

Solver failed:
Ocamlbuild cannot find or build bla.ml.

(but the file bla.mlpack does exist).
Actually at first I did that from a parent directory, so the command I
used looked more like:

ocamlbuild -I dir dir/bla.cmo

And the error was different:

Solver failed:
Ocamlbuild knows of no rules that apply to a target named dir/bla.mly.

There is no such file as dir/bla.mly anywhere on my drive, although the
project does contain some other mly files.

Now for the questions:
1) What is the best way to compile my project? By "best" I mean: with no
plugin if possible, with a small _tags file, and as few command line
options as possible, while still keeping the spirit of ocamlbuild (for
instance, compiling everything in one single call to ocamlbuild if
possible).
2) Why doesn't ocamlbuild compile my file bla.mlpack into bla.cmo? In
the manual I can read that "%.mlpack" has target "%.cmo".
3) If ocamlbuild actually did compile bla.cmo, could it use it to
compile main.byte or must I build a library bla.cma first?

Thanks. I would be glad to contribute to the wiki, but I have to
understand ocamlbuild first ;)

--
Romain Bardou

_______________________________________________
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

Nicolas Pouillard

unread,
Jan 31, 2008, 8:03:23 AM1/31/08
to Romain Bardou, caml-list
Excerpts from Romain Bardou's message of Thu Jan 31 12:55:20 +0100 2008:
> Hello,
Hello,

> I have this big project I work on, which could be summarized like this:
>
> module A
> module bla/A
> module bla/B
> module Main
>
> The module B in the bla directory depends on the module A of the bla
> directory. The module Main depends on both modules A and on module B.
> For some reasons I cannot rename either of the modules.
>
> So what I do is pack A and B in a Bla module, so I can write Bla.A and
> Bla.B, using the -pack command line option. It works with my Makefile.
>
> Now I try to use ocamlbuild, because I really like its approach (I come
> from the Pascal world where no makefile is needed). So I made this file
> bla.mlpack containing the lines:
>
> A
> B

bla.mlpack should not be in the bla/ directory, and should contain:

bla/A
bla/B

Because you don't want to expose bla to all your modules since you have a name clash.

> Now if I compile using:
>
> ocamlbuild Main.byte

Does it works now?

[...]

> I can't compile using:
>
> ocamlbuild -I bla Main.byte
>
> Because now the module A is defined twice.

Yes

> So I tried to compile using two steps: first, compile bla.cmo, and then,
> compile Main.byte, but ocamlbuild doesn't seem to be good at that (and
> actually that's not a bad thing imo). Indeed, if I do:
>
> ocamlbuild bla.cmo

You won't trick ocamlbuild with this technique, but it's a good way to
specifically found what's should be buildable and is not.

[...]

> Now for the questions:
> 1) What is the best way to compile my project? By "best" I mean: with no
> plugin if possible, with a small _tags file, and as few command line
> options as possible, while still keeping the spirit of ocamlbuild (for
> instance, compiling everything in one single call to ocamlbuild if
> possible).

In most of cases it will works. However precise directory scopes and packages
contents and scope can be done in a plugin.

> 2) Why doesn't ocamlbuild compile my file bla.mlpack into bla.cmo? In
> the manual I can read that "%.mlpack" has target "%.cmo".

Yes there is such a rule.

> 3) If ocamlbuild actually did compile bla.cmo, could it use it to
> compile main.byte or must I build a library bla.cma first?

Yes it will use it.

> Thanks. I would be glad to contribute to the wiki, but I have to
> understand ocamlbuild first ;)

I would be thankful.

--
Nicolas Pouillard aka Ertai

signature.asc

Romain Bardou

unread,
Jan 31, 2008, 8:41:26 AM1/31/08
to Nicolas Pouillard, caml-list
Thanks for your help!

Now it still doesn't compile, but the error is different and shows that
I'm getting closer.

What I didn't tell you is that I actually have several directories
"bla", so it is more like this:

module A
module C
module bla/A
module bla/B
module bli/C
module Main

You can view the "bla" and "bli" directories as the "parsing" and
"utils" directories of the OCaml source.

The module bla/A depends on the module bli/C. There is no clash between
names in the directories bla and bli, and I want to pack bla and bli
together in a big module Blabli so Main can access Blabli.A, Blabli.B
and Blabli.C. So I have a file blabli.mlpack:

bla/A
bla/B
bli/C

The problem is that ocamlbuild doesn't look in bli to compile the files
in bla, so I get an error while compiling bla/A: the module bli/C is
unbound.

I guess one possible solution would be to put all the files in "bla" and
in "bli" together in the same directory, but I'd really prefer to avoid
that if possible. I tried it and it works, though: when I put every file
in the same subdirectory, the following command works, and produces the
file _build/bla.cmo:

ocamlbuild bla.cmo

However, the following command doesn't work:

ocamlbuild bla.cmx

Because the files aren't compiled with the -for-pack option. I have to
add "-cflags -for-pack,Bla". I guess it shouldn't be hard to use the
_tags file to make it use the flag only on the files of bla, so I'll try
and investigate that (couldn't it be automatic though?).

Thanks again,

Romain Bardou

Nicolas Pouillard a écrit :

> ------------------------------------------------------------------------

Nicolas Pouillard

unread,
Jan 31, 2008, 8:51:59 AM1/31/08
to Romain Bardou, caml-list
Excerpts from Romain Bardou's message of Thu Jan 31 14:42:30 +0100 2008:

> Thanks for your help!
>
> Now it still doesn't compile, but the error is different and shows that
> I'm getting closer.
>
> What I didn't tell you is that I actually have several directories
> "bla", so it is more like this:
>
> module A
> module C
> module bla/A
> module bla/B
> module bli/C
> module Main
>
> You can view the "bla" and "bli" directories as the "parsing" and
> "utils" directories of the OCaml source.
>
> The module bla/A depends on the module bli/C. There is no clash between
> names in the directories bla and bli, and I want to pack bla and bli
> together in a big module Blabli so Main can access Blabli.A, Blabli.B
> and Blabli.C. So I have a file blabli.mlpack:
>
> bla/A
> bla/B
> bli/C

If there is no name clash due to bli/ you can expose it (-I bli).
If not, your last option is fine-grained directory scoping using a plugin.

[...]

> However, the following command doesn't work:
>
> ocamlbuild bla.cmx
>
> Because the files aren't compiled with the -for-pack option. I have to
> add "-cflags -for-pack,Bla". I guess it shouldn't be hard to use the
> _tags file to make it use the flag only on the files of bla, so I'll try
> and investigate that (couldn't it be automatic though?).

Using -for-pack is a pain. If your project is not too complex, I can advise
to use your _tags that way:

$ cat _tags
<bl{a,i}/**/*.ml>: for-pack(Blabli)
# This is to avoid -I bli
"bli": include

If you need more precise scoping, plugin is your last option.

--
Nicolas Pouillard aka Ertai

signature.asc

Romain Bardou

unread,
Jan 31, 2008, 9:03:06 AM1/31/08
to Nicolas Pouillard, caml-list
> Using -for-pack is a pain. If your project is not too complex, I can advise
> to use your _tags that way:
>
> $ cat _tags
> <bl{a,i}/**/*.ml>: for-pack(Blabli)
> # This is to avoid -I bli
> "bli": include
>
> If you need more precise scoping, plugin is your last option.

I want to pack all the files in bla and bli together anyway, so this
solution would be great; however, now ocamldep gives me an error:

/usr/local/bin/ocamldep.opt: unknown option `-for-pack'.

Btw, wouldn't the line including "bli" result in the same problem as
before, with name clashes between the files in "/bli" and the files in "/"?

I'll investigate and try to add the include option only on the files in
bl{a,i}, using some tags or some plugin.

--
Romain Bardou

Nicolas Pouillard

unread,
Jan 31, 2008, 9:14:37 AM1/31/08
to Romain Bardou, caml-list
Excerpts from Romain Bardou's message of Thu Jan 31 15:11:01 +0100 2008:

> > I want to pack all the files in bla and bli together anyway, so this
> > solution would be great; however, now ocamldep gives me an error:
> >
> > /usr/local/bin/ocamldep.opt: unknown option `-for-pack'.
>
> Okay well this part was easy, I use the tag:
>
> <bl{a,i}/**/*.cm*>: for-pack(Blabli)

Yes my bad (I've not checked), more precisely only cmx deserve for-pack so you can be more precise:

<bl{a,i}/**/*.cmx>: for-pack(Blabli)

> And it works. Using the includes I can compile blabli.cmo but I can't
> compile main.native because of the name clashes.

Is there name clashes between bli/* and your toplevel modules?

signature.asc

Nicolas Pouillard

unread,
Jan 31, 2008, 9:15:42 AM1/31/08
to Romain Bardou, caml-list
Excerpts from Romain Bardou's message of Thu Jan 31 15:04:18 +0100 2008:

> > Using -for-pack is a pain. If your project is not too complex, I can advise
> > to use your _tags that way:
> >
> > $ cat _tags
> > <bl{a,i}/**/*.ml>: for-pack(Blabli)
> > # This is to avoid -I bli
> > "bli": include
> >
> > If you need more precise scoping, plugin is your last option.
>
> I want to pack all the files in bla and bli together anyway, so this
> solution would be great; however, now ocamldep gives me an error:
>
> /usr/local/bin/ocamldep.opt: unknown option `-for-pack'.
>
> Btw, wouldn't the line including "bli" result in the same problem as
> before, with name clashes between the files in "/bli" and the files in "/"?
>
> I'll investigate and try to add the include option only on the files in
> bl{a,i}, using some tags or some plugin.

If there is name clashes you need a plugin that basically says:

..
Pathname.define_context "bla" ["bla"; "bli"]
..

signature.asc

Romain Bardou

unread,
Jan 31, 2008, 9:34:24 AM1/31/08
to Nicolas Pouillard, caml-list
> If there is name clashes you need a plugin that basically says:
>
> ...
> Pathname.define_context "bla" ["bla"; "bli"]
> ...

Wow, it compiles :)

So, from what I understand, the API function Pathname.define_context a b
basically says that all files in directory a depend on ("should
include") the directories in list b.

Okay, now I have to sum up all that I learned and make a nice wiki page.

Nicolas Pouillard

unread,
Jan 31, 2008, 9:44:26 AM1/31/08
to Romain Bardou, caml-list
Excerpts from Romain Bardou's message of Thu Jan 31 15:35:35 +0100 2008:

> > If there is name clashes you need a plugin that basically says:
> >
> > ...
> > Pathname.define_context "bla" ["bla"; "bli"]
> > ...
>
> Wow, it compiles :)
>
> So, from what I understand, the API function Pathname.define_context a b
> basically says that all files in directory a depend on ("should
> include") the directories in list b.

They don't depend on, they see the content.

> Okay, now I have to sum up all that I learned and make a nice wiki page.

It would be very nice.

signature.asc
0 new messages