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 TAA20882; Thu, 21 Mar 2002 19:49:33 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA20733 for ; Thu, 21 Mar 2002 19:49:32 +0100 (MET) Received: from dpt-info.u-strasbg.fr (dpt-info.u-strasbg.fr [130.79.44.193]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g2LInTX21819; Thu, 21 Mar 2002 19:49:30 +0100 (MET) Received: (from luther@localhost) by dpt-info.u-strasbg.fr (8.9.3/8.9.3) id TAA26450; Thu, 21 Mar 2002 19:50:07 +0100 Date: Thu, 21 Mar 2002 19:50:07 +0100 From: Sven To: Xavier Leroy Cc: Gerd Stolpmann , =?iso-8859-1?Q?Johan_Georg_Granstr=F6m?= , caml-list@inria.fr Subject: Re: [Caml-list] The DLL-hell of O'Caml Message-ID: <20020321195007.B26315@dpt-info.u-strasbg.fr> References: <3C8C9FE1.2060904@gerd-stolpmann.de> <000d01c1c95b$866bc060$0b01a8c0@mit.edu> <20020312230047.M1173@ice.gerd-stolpmann.de> <20020320222038.A3148@hg.cs.mu.oz.au> <3C98863F.6060208@gerd-stolpmann.de> <007601c1d00f$f3b81960$0c6fa8c0@invariant.se> <3C989156.6010906@gerd-stolpmann.de> <20020320213925.A25391@pauillac.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20020320213925.A25391@pauillac.inria.fr>; from xavier.leroy@inria.fr on Wed, Mar 20, 2002 at 09:39:25PM +0100 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Wed, Mar 20, 2002 at 09:39:25PM +0100, Xavier Leroy wrote: > But A.cmo does not contain SIGB -- only a mention of B and a hash of > SIGB. The reason is quite simple: A.cmo would be *huge* if it > included a copy of the signatures of every module it refers, either > directly or indirectly. (Think several megabytes.) Just curious, ... would it not be enough if A.cmo had the type information of the part of B it is going to use, and forget about the rest of it ? I remember some papers on type discipline doing this kind of stuff. > Having only hashes of signatures, all the linker can check is > hash(SIGB) = hash(SIGB'), that is SIGB = SIGB'. > > > Anyway, only being able to add functions is not sufficient. There are > > many possible changes of modules that would not break "source-code > > compatibility", but would certainly break binary compatibility, e.g. > > new optional arguments, new variants, new methods, etc. > > This is another good point: even if we allowed SIGB' <: SIGB at > link-time instead of requiring SIGB = SIGB', there are many > "reasonable" changes in a signature that would break subtyping, like > those you mention above. And this is inevitable: these changes could > break type-safety of existing programs. > > To summarize: I believe binary compatibility doesn't really work in a > strongly, statically-typed language. It sometimes works for > dynamically-typed or weakly-typed languages (Perl, C), although > run-time failures are not unheard of. Copious link-time > re-type-checking as in Java makes it work sometimes too, although on > close examination Java's binary compatibility rules are quite complex > and restrictive. > > Conclusion for OCaml? Forget about binary compatibility, binary-only > distributions, versioning, and all that. All we need for OCaml > libraries is source distribution, a standardized re-building procedure, > and a place to record cross-library dependencies, so that everything > that needs to be recompiled when something changes can be recompiled > automatically. Something like a source RPM or Debian package, or a > BSD port. Even for that, it is nice to have propper versioning support, right now, the policy for debian packagers, is once the ocaml package changes (new upstream release,, which more often than not breaks binary compatibility, but sometimes only partially)., then all packagers need to recompile all the ocaml libraries, and just to be sure, it is best to rebuild the program packages also. But this needs still human intervention on the part of the developpers to adapt the package if needed, and a lot of work for all the 8 arches which will be supported by woody, without even counting all those not yet fully supported arches which don't have autobuilders. I would like a lot to have more information on versioning available. > I believe this is a much more reasonable objective than dreaming about > binary compatibility and whatnot. Still, it's not trivial: > the authors of existing OCaml libraries (myself included) have some > work to do to implement fully automatic build of their libraries... :))) Friendly, Sven Luther ------------------- 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