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
[ANN] OCaml Reins 0.1 - Persistent Data Structure Library
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-09-26 (16:51)
From: Sylvain Le Gall <sylvain@l...>
Subject: Re: Cherry-picking modules (was Re: [ANN] OCaml Reins 0.1 - Persistent Data Structure Library)
On 26-09-2007, Sylvain Le Gall <> wrote:
> On 26-09-2007, Daniel Bünzli <> wrote:
>> Le 26 sept. 07 à 01:33, Sylvain Le Gall a écrit :
>>> Anyway, embeding any external code into your project is a nightmare  
>>> for
>>> security/maintenance in the long term... I would avoid this  
>>> solution if
>>> i want things that doesn't have problem.
>> As I explained I don't think so. In the best case you delegate the  
>> nightmare to the user. Can you explain exactly where the nightmare is  
>> with embedding ? If the distributed modules you integrate are  
>> labelled with a version, I don't see it. The work needed for  
>> maintenance in the long term is exactly the same, except only the  
>> developer has to care. As for security updates in ocaml, you cannot  
>> anyway rely on dynamic linking. Which I see as a good thing, for  
>> applications dynamic linking creates more problems than it solves and  
>> should be avoided most of the time (except of course for system  
>> libraries).
> OK, let me make myself clear, about the fact that embedding things is
> the worst case. Let consider library libA and program progB, progB
> requires libA:
> * libA is embedded inside progB:
> ** libA do a minor bug correction -> you need to re-release progB even if
>   nothing has changed inside it 
> ** you make a bug correction in libA, as many developers you don't have
>   time to submit bug upstream -> libA upstream and libA embedded begin to
>   be different
> * libA is not embedded inside progB:
> ** libA do a minor bug correction -> progB just need to be recompiled
>    (no release), easy to do automatically with a dependency tracking
> ** you make a bug correction in libA -> you have no choice than to
>    report it to upstream libA, because your bug correction will disappear
>    in next libA release

Forget the best "worst case".

You ship libA -- with a local modification in libB. A developper want to
use libA (original -- no modification) and libB...

Is it possible ?

I think you will have a conflict between the two version (.cmi exists
with different signatures)...

So by shipping libA with modification, you cannot use libA into another

Sylvain Le Gall