Re: [Caml-list] Large projects in OCaml

[Ville-Pertti Keinonen <will@exomi.com>]

On May 21, 2004, at 2:28 PM, Jon Harrop wrote:

> But I want them to be able to constantly write new code and recompile 
> it
> (statically linking their .cmo files with mine), forever. If their 
> code and
> my lib depend upon the same object file and it changes, then this will 
> break

Your library version obviously needs to depend on a specific version of 
OCaml as well as specific versions of libraries used by your 
library...but for a commercial library, this should be the case, 
anyhow.  You shouldn't be supporting any versions of OCaml and 
libraries you depend on except the ones you have built and tested 
against.

This isn't specific to OCaml, either.  C is rare in that it has had 
stable and standardized enough ABIs that you can usually get away with 
using different versions of compilers and system libraries.  With other 
libraries, YMMV, but things that break due to version incompatibilities 
aren't rare.

But even with C++, things often aren't that easy.  The commercial 
binary C++ libraries I've used, whether shared or not, are supported 
for only a particular compiler version and particular versions of third 
party libraries.  Usually any third party libraries that are required 
are distributed along with the purchased binary library.

> and the only fix will be for them to get a new lib from me for the new
> version of their object file. If I am right, then I am afraid that 
> this will
> put people off...

But why would your library depend on *their* changing object file, 
unless its a third party library, in which case they should be using 
the same version you built against?

In any case, you really should consider distributing your library in 
source form to licensees.  Given a choice, I'd never purchase a 
binary-only library for any purpose (sadly, I often don't have a 
choice).

Almost all of the problems I've run into with purchased binary 
libraries could've been avoided if I had the source, and I've spent 
unreasonable amounts of time tracking down totally stupid problems 
(mostly due to undocumented assumptions).  I can't think of any binary 
(non-system) libraries that I haven't run into unnecessary problems 
with during the last decade...prior to that, I wasn't used to having 
source code, so I didn't associate problems with binary distributions.

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