Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Large projects in OCaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jacques GARRIGUE <garrigue@k...>
Subject: Re: [Caml-list] Large projects in OCaml
From: Jon Harrop <jdh30@cam.ac.uk>

> On Thursday 20 May 2004 22:41, you wrote:
> > ...There is no link phase (except linking
> > to external c libraries) at the start of an Ocaml program.
> 
> Sure, so if someone buys my lib (in the form of .cmo and .mli files), writes 
> their own code and compiles it into an executable then it should work 
> forever.
> 
> 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 
> 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...

There has been some discussion about how bad it is, but my view is
that this .cmi/.cmx compatibility problem is so bad that it makes
binary only distribution of libraries a nightmare for both the
provider and the user. Basically, any bug fix in the compiler (not
even a new feature) may break the compatibility.
If you are going to make binary only distribution, then you should
guarantee to your user that you are ready to provide them new versions
when needed. A terrible pain for both of you.
(At some time Ensemble was binary-only for licensing reasons. It was a
huge discomfort.)

Honestly, what is so bad about providing the source under a NDA?
This has been the standard way to proceed on Unix for a long time,
just because people may need to patch and fix the system, and you
don't wan't to have to go to your provider every time something
changes.
I suggest you rather think in that direction, since it would save you
lots of trouble.

Jacques Garrigue

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