Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Best way to choose an implementation of a lib ?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-12-01 (01:06)
From: Jacques Garrigue <garrigue@m...>
Subject: Re: [Caml-list] How to compile different implementations of the same lib
From: Daniel Bünzli <>

> Le 30 nov. 05 à 15:38, Daniel Bünzli a écrit :
> > Le 30 nov. 05 à 13:19, Jacques Garrigue a écrit :
> >
> >> Note that with native code you must be careful to compile without any
> >> .cmx around (only .cmi's), as this would induce dependencies on a
> >> specific version. This also means that you lose inlining (one major
> >> advantage of native code.)
> >
> > I don't understand this. Careful to compile what without which cmx  
> > around ? And where do you lose inlining ?
> Now I think I understand this. You mean when you compile client code  
> against the library. Then functions from the lib will not  
> be inlined in client code. This allows to switch implementations of  
> the library without recompiling More precisely, if you  
> statically link with the lib you only need to relink and if you  
> dynamically link you don't even need to do anything, you can just  
> play with CAML_LD_LIBRARY_PATH. Right ?

Yes, that's the idea.
I should have been more specific:
In order to create a clean separation between the library and the
client, such that you will be able to change the implementation of the
library, you must write .mli's for all the modules the library
exports, and compile the client with only the .cmi's in the path.
Note of course that the .mli/.cmi must also be copied to the directory
where you compile the library (the compiler only looks for them there
when compiling the .ml).

A result is that there cannot be any inlining between client and
library. Actually, this is even worse than that: this also prevents
direct function calls, as the concrete information about functions is
also in the .cmx. All calls will have to go through closures. Just
like when you call a function received as parameter, or inside a

This suggests the other evident alternative: write the client as a
functor. This will not be slower! But this can be more painful if
there are several modules in the client...

Jacques Garrigue