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
> 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
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 :
> ------------------------------------------------------------------------
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
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
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?
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.
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.