Bünzli Daniel a écrit :

> 3. Manage packages per project (vs. per machine) to make project 
> dependencies explicit. Thus a single command can install you the (OCaml 
> + C stubs only) dependencies of your project on a fresh system. If your 
> project is a package itself, it facilitates its packaging .
> 
> 4. Rely on ocamlbuild to do the hard work. Grosso modo in the way 
> described here [3], which may be unrealistic for big projects, but on 
> unices ressource consumption could be mitigated by making hard links to 
> a cache maintained per user or machine (inspired by ideas in this 
> message [4]).

I'm not a big fan of hardlinking external stuff into the _build directory.

I think we should rather add to Ocamlbuild a module for calling 
ocamlfind, parsing its output, etc. This way ocamlbuild plugins could 
easily call ocamlfind, be it for configuration or compilation.

Pursuing the ocamlbuild philosophy of having a simple solution for 
simple problems, a built-in tag syntax and associated rules should allow 
such simple (e.g. regular) projects to easily use a package registered 
in ocamlfind.

I'm thinking of a tag use_ocamlfind(PROJECTNAME) so that you could write:

   <myproject.{byte,native}>: use_ocamlfind(pcre), use_ocamlfind(mysql)

Of course you still need to register those packages in ocamlfind.

As Ocaml binaries are brittle, a solution for compiling from source such 
as Godi is welcome.

However Godi needs to be kept up-to-date with respect to the Ocaml 
distribution... it is currently only available for 3.09!
--
Berke DURAK