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 SAA20910; Sat, 22 Nov 2003 18:49:07 +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 SAA03244 for ; Sat, 22 Nov 2003 18:49:06 +0100 (MET) Received: from mail3.tpgi.com.au (mail.tpgi.com.au [203.12.160.59]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id hAMHn4125253 for ; Sat, 22 Nov 2003 18:49:05 +0100 (MET) Received: from syd-ts18-2600-035.tpgi.com.au (syd-ts18-2600-035.tpgi.com.au [203.58.21.35]) by mail3.tpgi.com.au (8.11.6/8.11.6) with ESMTP id hAMHn0A11186 for ; Sun, 23 Nov 2003 04:49:01 +1100 Subject: Re: [Caml-list] Building large and portable projects From: skaller Reply-To: skaller@ozemail.com.au To: caml-list@inria.fr In-Reply-To: <20031122170852.GA15144@davidb.org> References: <20031120195614.GB441@gallu.homelinux.org> <000f01c3afd1$30033c90$0274a8c0@PWARP> <20031121052549.GA8599@davidb.org> <008301c3aff3$1030e760$0274a8c0@PWARP> <20031121064950.GA836@gallu.homelinux.org> <1069431167.5426.45.camel@pelican> <20031122170852.GA15144@davidb.org> Content-Type: text/plain Message-Id: <1069519719.6703.127.camel@pelican> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 23 Nov 2003 03:48:39 +1100 Content-Transfer-Encoding: 7bit X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 ozemail:01 1100,:01 hashes:01 ocamlc:01 ocamlopt:01 usr:01 usr:01 mount:01 mount:01 interfere:01 lookups:01 foo:01 subdirectory:01 kpathsea:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sun, 2003-11-23 at 04:08, David Brown wrote: > On Sat, Nov 22, 2003 at 03:12:48AM +1100, skaller wrote: > > > For example .c -cc--> .o -link--> exe, we can > > use the cached .o instead of running cc on the > > .c provided the .c is older. > > Older is incorrect, as well. The program should run cc on the .c > provided that the .c is different than the one used to produce the .o. > Timestamps are useful as a cache, but a proper tool will need to use > file hashes, or something to properly detect a file changing. Yeah, that's a good point. > An unrelated annoyance I've found is that ocamlc doesn't allow for the > objects to be stored in a separate directory from this source. This > makes things, such as multiple configurations, multiple targets > difficult. Since ocamlopt doesn't currently support cross compilation, > anyway, this is less of an issue. It is still an issue if you have multiple Ocaml installations: I actually ought to have 3 of them: (a) the standard one my Linux came with (b) the lastest release (c) the CVS version I need (a) to run system scripts (/usr) I need (b) to check my code runs for clients (/usr/local), and I need (c) cause I love playing with Ocaml :-))) In addition I have to build my software at least in both binary and bytecode form to check clients on non-Linux platforms have some chance of using my product if they can't get a native code compiler. And then, there are versions of third party libraries ... ouch. I have a starting concept here: I call it 'mount points'. And another called 'mount stacks'. A mount point is a root, specified as an OS native directrory name. Files and directories down from the mount point are always specified using Unix convention (no matter what platform). Then we have stacks. We start at the top mount point of the stack and look for a file, going down until we find it. However we always write on the bottom. Here is a stack: /usr/lib/ocaml /usr/local/lib/ocaml /home/skaller/ocaml The idea is you had hide *some* files with an updated file, but don't need to hide them all with a completely new distribution. [A variant would just use patch files] Additionally, writes (of object files etc) are always most local and so don't interfere with administrator installed compiled versions. Another key part of it is relative file lookups. The relativity is to a directory stack NOT a particular directory so eg C #include "foo.h" inside the file "bar.h" will follow the same stack search algorithm except it will look in the mount point of the stack + the subdirectory of the file "bar.h". A path is a sequence of stacks of mount points. [It is also worth studying Kpathsea here ..] ------------------- 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