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

[Fergus Henderson <fjh@cs.mu.OZ.AU>]

On 20-Mar-2002, Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> wrote:
> From: Fergus Henderson <fjh@cs.mu.OZ.AU>
> 
> > Adding new functions to a module ought not break binary backwards
> > compatibility.  If it does, then you lose many of the benefits of
> > separate compilation.
> 
> Could you specify what benefits?

For example, the ability to install a new version of a library
(with some new functions) without having to recompile everything
that references that library.

This includes the ability to use version N+1 of library `foo' with
version M of library `bar', even though the binary that you have for
version M of library `bar' was build using version N of library `foo'
rather than version N+1.

Binary distributions of libraries is very difficult if you have to
upgrade them all in lock-step anytime a base library changes.

> The current situation in OCaml is that you have to recompile all
> dependencies everytime you change anything in the interface.
> If you use a Makefile, even changing a comment will trigger a
> recompilation.

If you're sure nothing important changed, you can always use
`touch 01010101 filename' to mark that file as old.

> But, in my experience most C makefiles are written in the same way
> meaning that you have to recompile everytime a header changes.

Most C makefiles are written so that dependencies on third-party
library header files are not included in the Makefile dependencies.
(And there are good reasons for this; including such
dependencies can cause as many problems as it solves...)
That imples that if you install a new version of a third-party
library, and then rerun make, it won't recompile your sources.

Also, the issue of makefiles is irrelevant in the case of binary
library distributions, as in the example above with `foo' and `bar'.

> The real problem is about how to check that binary (and semantics)
> compatibility is satisfied.

Sure it would be *nice* if the system checked that automatically,
and handled library major/minor revision numbers accordingly.

But the programmer can also check this manually when
releasing a new version of a library, by comparing the
interface with that of the previous version (e.g. using `cvs diff').
That's what C and C++ programmers have to do, after all.

There are really two issues here.  One is that the language and/or
implementation should give guarantees about what kinds of changes
will preserve binary compatibility, including at a minimum the
requirement that adding new functions should not break binary
compatibility.  The second issue is that it's desirable to have
type-safe linking.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
-------------------
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