Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Completeness of "Unix" run-time library
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Fernando Alegre <fernando@c...>
Subject: Re: [Caml-list] Modules and namespaces
On Fri, Mar 19, 2004 at 11:45:14AM +0100, Sven Luther wrote:
> On Fri, Mar 19, 2004 at 10:19:31AM +0000, Richard Jones wrote:

> > It would be quite possible for someone else to write a Dbi module
> > located in the -I +anotherdbi directory.  No conflict would arise
> > unless some strange person wanted to use both types of Dbi module
> > in their program - an unlikely occurrence presumably.
> 
> You can achieve this by using the -pack option when creating libraries.
> Sure it has still some problems, but it is the way to go to solve this
> problem.
> 
> What is really missing is support for more than one OCAMLLIBDIR, in
> order to be able to easily separate the libraries installed by your
> package manager (/usr/lib/ocaml/3.07 for debian), by the one installed
> locally by the sysadmin (/usr/local/lib/ocaml/3.07 for debian), and the
> user specific ones (less important though, but still usefull).

It seems that you both also miss the -pre_open and -stdlib switches in
the compiler.

A pre_open switch would take care of 2 modules called Dbi without modifying
them:

(* wrapper1.ml *)

module DbiVendor1 = Dbi

====

(* wrapper2.ml *)

module DbiVendor2 = Dbi

===

ocamlc -c -I path_to_vendor1 wrapper1.ml -I path_to_vendor2 wrapper2.ml ...

===

A stdlib switch is what Sven is asking above.

Both switches, along with pack, is all we need to create our custom
packaging/namespace management systems independently of INRIA. What do you
think?

These switches would also be policy-neutral, so that nobody is _forced_ to
use GODI, debian packages or any other middleware if they do not fit their
environment, but still allow people to use external libraries without fear
of namespace clashes.

Fernando


-------------------
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