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 FAA14249; Mon, 24 May 2004 05:07:23 +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 FAA15216 for ; Mon, 24 May 2004 05:07:21 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i4O379SH028926 for ; Mon, 24 May 2004 05:07:20 +0200 Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3p2-20030924/3.7W) with ESMTP id MAA19350; Mon, 24 May 2004 12:07:03 +0900 (JST) Date: Mon, 24 May 2004 12:07:03 +0900 (JST) Message-Id: <20040524.120703.46614549.garrigue@kurims.kyoto-u.ac.jp> To: jdh30@cam.ac.uk Cc: caml-list@inria.fr Subject: Re: [Caml-list] Large projects in OCaml From: Jacques GARRIGUE In-Reply-To: <200405211228.34673.jdh30@cam.ac.uk> References: <200405202204.27693.jdh30@cam.ac.uk> <71024598-AAA6-11D8-A7CF-000A95A1E69A@csun.edu> <200405211228.34673.jdh30@cam.ac.uk> X-Mailer: Mew version 4.0.64 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 jacques:01 2004:99 mli:01 compiles:01 statically:01 cmx:01 bug:01 terrible:01 binary-only:01 discomfort:99 nda:99 jacques:01 compiler:01 cmo:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Jon Harrop > 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