caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Alain Frisch <frisch@clipper.ens.fr>
To: Mattias Waldau <mattias.waldau@abc.se>
Cc: Caml list <caml-list@inria.fr>
Subject: Re: [Caml-list] The DLL-hell of O'Caml
Date: Sat, 2 Mar 2002 15:46:54 +0100 (MET)	[thread overview]
Message-ID: <Pine.SOL.4.44.0203021512370.22250-100000@clipper.ens.fr> (raw)
In-Reply-To: <014901c1c1bf$ebb29c30$0700a8c0@gateway>

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


  parent reply	other threads:[~2002-03-02 14:46 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-01 18:52 [Caml-list] troubleshooting problem related to garbage collection james woodyatt
2002-03-02  0:11 ` james woodyatt
2002-03-02  7:57   ` [Caml-list] The DLL-hell of O'Caml Mattias Waldau
2002-03-02 11:56     ` Markus Mottl
2002-03-02 21:40       ` Alexander V. Voinov
2002-03-02 14:46     ` Alain Frisch [this message]
2002-03-02 19:00       ` Chris Hecker
2002-03-02 19:42         ` Mattias Waldau
2002-03-02 22:41           ` Chris Hecker
2002-03-03 15:56             ` Vitaly Lugovsky
2002-03-04  9:57           ` Sven
2002-03-04 12:10             ` possible solution to " Dave Mason
2002-03-05  7:58               ` Mattias Waldau
2002-03-05 12:47                 ` Dave Mason
2002-03-04 12:20     ` Jacques Garrigue
2002-03-11  4:28 Mark D. Anderson
2002-03-11  7:12 ` Mattias Waldau
2002-03-11 12:15 ` Gerd Stolpmann
2002-03-12  0:19   ` Jeff Henrikson
2002-03-12 22:00     ` Gerd Stolpmann
2002-03-20 11:20       ` Fergus Henderson
2002-03-20 11:43         ` Jacques Garrigue
2002-03-20 17:16           ` Fergus Henderson
2002-03-20 12:53         ` Gerd Stolpmann
2002-03-20 13:05           ` Johan Georg Granström
2002-03-20 13:40             ` Gerd Stolpmann
2002-03-20 19:46               ` Alain Frisch
2002-03-20 20:39               ` Xavier Leroy
2002-03-20 21:16                 ` Markus Mottl
2002-03-21  9:07                 ` Warp
2002-03-21 10:18                 ` Christopher Quinn
2002-03-21 18:13                   ` Xavier Leroy
2002-03-21 14:13                 ` Jeff Henrikson
2002-03-21 18:10                   ` Xavier Leroy
2002-03-21 18:39                     ` Sven
2002-03-21 19:22                     ` james woodyatt
2002-03-21 19:43                     ` Jeff Henrikson
2002-03-22  2:02                     ` Brian Rogoff
2002-03-22 10:11                     ` Warp
2002-03-21 18:50                 ` Sven
2002-03-22 10:14 Dave Berry
2002-03-22 10:24 Dave Berry

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.SOL.4.44.0203021512370.22250-100000@clipper.ens.fr \
    --to=frisch@clipper.ens.fr \
    --cc=caml-list@inria.fr \
    --cc=mattias.waldau@abc.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).