Browse thread
[ANN] OCaml Reins 0.1 - Persistent Data Structure Library
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| 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 <sylvain@le-gall.net> wrote: > On 26-09-2007, Daniel Bünzli <daniel.buenzli@epfl.ch> 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 library... Regards, Sylvain Le Gall