Re: [Caml-list] The DLL-hell of O'Caml

[Sven <luther@dpt-info.u-strasbg.fr>]

On Wed, Mar 20, 2002 at 09:39:25PM +0100, Xavier Leroy wrote:
> But A.cmo does not contain SIGB -- only a mention of B and a hash of
> SIGB.  The reason is quite simple: A.cmo would be *huge* if it
> included a copy of the signatures of every module it refers, either
> directly or indirectly.  (Think several megabytes.)

Just curious, ...

would it not be enough if A.cmo had the type information of the part of B it
is going to use, and forget about the rest of it ? I remember some papers on
type discipline doing this kind of stuff.

> Having only hashes of signatures, all the linker can check is
> hash(SIGB) = hash(SIGB'), that is SIGB = SIGB'.
> 
> > Anyway, only being able to add functions is not sufficient. There are
> > many possible changes of modules that would not break "source-code 
> > compatibility", but would certainly break binary compatibility, e.g.
> > new optional arguments, new variants, new methods, etc.
> 
> This is another good point: even if we allowed SIGB' <: SIGB at
> link-time instead of requiring SIGB = SIGB', there are many
> "reasonable" changes in a signature that would break subtyping, like
> those you mention above.  And this is inevitable: these changes could
> break type-safety of existing programs.
> 
> To summarize: I believe binary compatibility doesn't really work in a
> strongly, statically-typed language.  It sometimes works for
> dynamically-typed or weakly-typed languages (Perl, C), although
> run-time failures are not unheard of.  Copious link-time
> re-type-checking as in Java makes it work sometimes too, although on
> close examination Java's binary compatibility rules are quite complex
> and restrictive.
> 
> Conclusion for OCaml?  Forget about binary compatibility, binary-only
> distributions, versioning, and all that.  All we need for OCaml
> libraries is source distribution, a standardized re-building procedure,
> and a place to record cross-library dependencies, so that everything
> that needs to be recompiled when something changes can be recompiled
> automatically.  Something like a source RPM or Debian package, or a
> BSD port.

Even for that, it is nice to have propper versioning support, right now, the
policy for debian packagers, is once the ocaml package changes (new upstream
release,, which more often than not breaks binary compatibility, but sometimes
only partially)., then all packagers need to recompile all the ocaml
libraries, and just to be sure, it is best to rebuild the program packages
also. But this needs still human intervention on the part of the developpers
to adapt the package if needed, and a lot of work for all the 8 arches
which will be supported by woody, without even counting all those not yet
fully supported arches which don't have autobuilders.

I would like a lot to have more information on versioning available.

> I believe this is a much more reasonable objective than dreaming about
> binary compatibility and whatnot.  Still, it's not trivial:
> the authors of existing OCaml libraries (myself included) have some
> work to do to implement fully automatic build of their libraries...

:)))

Friendly,

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