On Sat, 2 Mar 2002, Mattias Waldau wrote:

> The above history is the reason I started using the CDK,
> in many cases using libraries that depend on other
> libraries is almost impossible without the CDK. Too much
> time is spent on downloading and compiling.

A related issue is independance w.r.t OCaml version; if you want to try a
new OCaml release or CVS version, it is necessary to rebuild all the
libraries.  For instance, I now have three OCaml versions installed (3.04,
3.04+7 and 3.04+6 polymorphic methods), and it is a pain to maintain three
library trees.

Similarly, when you upgrade a library, you also have to rebuild all
the libraries that depend on it. Some kind of automatization in the
process would be great.

> I know 3 solutions to the problem:
> 1. CDK
> 2. Gerd invented findlib to solve the above problem.
> 3. Adding good packages to the standard distribution,
>    so that mostly packages doesn't depend on other
>    packages, but on packages in the standard
>    distribution. (But very few if any new packages
>    are added to the distribution.)

The monolithic and centralized approach of CDK does not seem to scale
well. Findlib does a good job. It would be great to have such a tool
(findlib or a clone, but why not findlib ?) in the standard
distribution...


> We need a solution. Maybe a CPAN-like solution?

Indeed, the new packaging facility in OCaml (-pack option, which glues
together a set of modules and allows decent namespace management) opens
the door to this kind of project.

> In the Ocaml-CPAN it could either be source code, or
> compile binaries (I can live without native code, at
> least when experimenting with other peoples libraries.)

An intermediate solution would be to distribute so-called "lambda-code",
that is the internal representation used in OCaml compilers just before
code production. The advantage is that it is common to bytecode and
native back-end, and it should be possible to design an upward-compatible
(w.r.t OCaml version) concrete representation of this code.


-- Alain

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners