English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] Project Proposals
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-05-15 (01:18)
From: Jacques Garrigue <garrigue@k...>
Subject: Re: [Caml-list] OCaml packaging problems
While I was trying to answer on the limitations of the Unix approach,
Gerd Stolpmann posted a much better and well-argument description of
the problem.

To complement this, I would add a suggestion to make the current
scheme work more smoothly.  It takes its inspiration from java's
classpath, which seems to work pretty well:
Couldn't we replace the single directory in OCAMLLIB by a path.
Alternatively, there could be an OCAMLPATH, taking precedence on
This path would replace the current stdlib for everything:
* it would be a default path for searching caml libraries and dlls
* ld.conf's under each of its elements would be read in its order
* +dirname on the command line would expand to elt/dirname for each
  of its elements
* findlib might honour it too

This would in particular solve the current problem with users who do
not have write access on the main library tree, and allow more
flexibility. This is of course orthogonal to the dependency handling
done by findlib.

For library designers, they would just have to honour this
variable by installing by default under the first element of this
path, adding the directory to elt/ld.conf if they also install dlls.

In my opinion simple (one variable), standard (think Java), and clean.

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