Re: [Caml-list] Large projects in OCaml

[Jon Harrop <jdh30@cam.ac.uk>]

On Friday 21 May 2004 13:49, Ville-Pertti Keinonen wrote:
> 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.

Do you think I should build, test and distribute for a variety of compiler and 
third party library versions then? That would be a set of object files for 
each permutation?

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

Ok, I just want to make sure that I'm providing the best possible service. :-)

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

I meant third party, sorry. I'm using my own version of lablgl as well as 
camlimages. I'll probably open-source an alternative to lablgl (based upon 
Isaac Trott's idlgl) but I'd like to use the standard camlimages.

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

I don't mind distributing the bulk of my code in source form (particularly the 
demos and paraphenalia) but I would like to keep the core closed source, 
unless someone is willing to pay an obscene amount of money for it. :-)

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

Ok, I'll keep considering distributing a source version. Maybe a cut-down 
version...

Cheers,
Jon.

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