From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id OAA30240; Fri, 21 May 2004 14:49:05 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id OAA30430 for ; Fri, 21 May 2004 14:49:03 +0200 (MET DST) Received: from oxy.exomi.com (fa-3-0-0.fw.exomi.com [217.169.64.99]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i4LCn2SH012491 for ; Fri, 21 May 2004 14:49:02 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by oxy.exomi.com (Postfix) with ESMTP id E52A620F245; Fri, 21 May 2004 15:49:03 +0300 (EEST) In-Reply-To: <200405211228.34673.jdh30@cam.ac.uk> References: <20040519172442.30413.qmail@web14522.mail.yahoo.com> <200405202204.27693.jdh30@cam.ac.uk> <71024598-AAA6-11D8-A7CF-000A95A1E69A@csun.edu> <200405211228.34673.jdh30@cam.ac.uk> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3CCE10AB-AB25-11D8-8E42-000393863F70@exomi.com> Content-Transfer-Encoding: 7bit Cc: caml-list@inria.fr From: Ville-Pertti Keinonen Subject: Re: [Caml-list] Large projects in OCaml Date: Fri, 21 May 2004 15:49:02 +0300 To: Jon Harrop X-Mailer: Apple Mail (2.613) X-Miltered: at concorde with ID 40ADFABE.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 statically:01 purchase:99 binary-only:01 avoided:01 stupid:01 undocumented:01 compiler:01 anyhow:01 cmo:01 compilers:01 standardized:01 ocaml:01 ocaml:01 recompile:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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