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 LAA02030; Thu, 21 Mar 2002 11:18:45 +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 LAA04361 for ; Thu, 21 Mar 2002 11:18:44 +0100 (MET) Received: from t2.fast.net.uk (ns1.fast.net.uk [212.42.162.2]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g2LAIhX10559; Thu, 21 Mar 2002 11:18:43 +0100 (MET) Received: from htec.demon.co.uk (adsl-212-42-169-63.fast.net.uk [212.42.169.63]) by t2.fast.net.uk (8.11.6/8.11.4) with ESMTP id g2LAIZY80253; Thu, 21 Mar 2002 10:18:35 GMT Message-ID: <3C99B37F.9020703@htec.demon.co.uk> Date: Thu, 21 Mar 2002 10:18:39 +0000 From: Christopher Quinn User-Agent: Mozilla/5.0 (compatible; MSIE5.5; Windows 98; X-Accept-Language: en-us, en MIME-Version: 1.0 To: Xavier Leroy CC: caml-list@inria.fr Subject: Re: [Caml-list] The DLL-hell of O'Caml 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > > 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.) Any idea how much improvement would come from hash-consing, as Dave Berry suggested? And only that part of a module's signature which pertained to actual usage would need inclusion, no? And only of those modules externally provided upon which one's project depends, ie. the standard library, not the internal project modules? Inclusion of such signature fragments need only be an optional feature when building distributed libraries, not generally for development (inhabiting every .cmo), so the 'bloat' is at least confined to where it matters, at the boundary. Chris Q. be an optional feature of libraries alone, thus confining any sort of bloat to distributed libs, commercial or otherwise? ------------------- 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