Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 93012 invoked from network); 20 Nov 2001 20:58:37 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 20 Nov 2001 20:58:37 -0000 Received: (qmail 17412 invoked by uid 97); 20 Nov 2001 20:58:39 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 17396 invoked by uid 97); 20 Nov 2001 20:58:38 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 17346 invoked from network); 20 Nov 2001 20:58:38 -0000 From: "Rob Oxspring" To: "Ant Developers List" Subject: RE: Smarter Javac Date: Tue, 20 Nov 2001 20:58:35 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200111200158.fAK1wHu27101@mail012.syd.optusnet.com.au> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > -----Original Message----- > From: Peter Donald [mailto:peter@apache.org] > Sent: Tuesday, November 20, 2001 1:15 AM > To: Ant Developers List > Subject: Re: Smarter Javac >=20 >=20 > On Tue, 20 Nov 2001 11:52, Rob Oxspring wrote: > > > I think you missed my point ;) You have to cache information = per-file > > > because for some reason you may always compile file X with > > > debugging, while Y > > > with no debugging. This does not mean you can't aggregate the > > > files during > > > compiler execution > > > > > > javac -g Bar.java Baz.java > > > > > > etc > > > > How would you go about this in Ant? Surely in current ant this=20 > would have > > to be split into two invocations of the javac task?=20 >=20 > right. >=20 > > In which case, the colour need only be cached on a per task basis. >=20 > If every task operated on the same set of data everytime then that = would=20 > work. The problem is that the source files for each task may=20 > change each run. Does this occur a lot? - I can't remember bumping into cases of the = fileset contents changing, without it implying that uptodate was false = anyway - though admittedly most of my ant usage is with small projects. I would have thought that storing the colour information accurately per = file would require a cache with size of the order of BUILDFILE_SIZE * = NO_FILES which is going to be pretty big no matter how you choose to = split store it. >=20 > > The issue of cache size / > > read speed should be mute here, since a single aggregated cache=20 > file would > > have a size roughly proportional to the build file. >=20 > I think you are trying to treat it in the same fashion as the c=20 > world treats=20 > autoconf values ?=20 Hmm, you've reached the end of my C knowledge I'm afraid. I've seen = that autoconf files exist and heard the name before but haven't = investigated them (yet). Do I assume that the C world treats them badly? >Essentually you would have a "config.cache"=20 > file that lists=20 > all these values yer? Thats about the size of it. >=20 > Iwas thiking about integrating it more into runtime like .deps files = are=20 > handled in c world.=20 Again - my C was fairly rudimentry and self taught and in this case I = don't know anything about .deps files. I think I'll try and read up on = automake (right?) a bit and get a handle on what it does and why. A = summary of the pitfalls would be handy though... >=20 > Thoughts? >=20 > > In short: The same colour applies to all files processed by a given = task > > invocation, therefore the colour is defined purely by the attributes = (+ > > inner elements) of the task. >=20 > It is up to the task to determine which parameters are relvent -=20 > this may or=20 > may not be related to attributes/elements of task. Point taken. I was expecting that task writers would be able to supply = some calculateColor() method to optimise for the specific task, although = since all options affect the build somehow (why have them otherwise) I = would have thought that this implementation would be a good defensive = default. >=20 > > An ant file build.xml: > > > > > > > > > > > > > > > > > > > > > > > > Would just have a file build.color: > > > > > > > > > > > > > > > > > > > > This way you could also regard the configuration colour to have = changed > > even when the only thing to have changed is the depends attribute of = the > > containing target. (Can't quite think whether this is useful=20 > or not though > > - its late) >=20 > interesting. Something to think about. >=20 > > If the colour is calculated at the getting and setting stage=20 > (i.e. only the > > attributes explicitly set in the XML file) then the colouring would = be > > immediately available to all tasks. The tasks themselves could=20 > be changed > > to take advantage of this new information as necessary. > > > > Please shout me down if I'm being daft and missing points here. >=20 > actually your proposing a different interpretation (ie autoconf=20 > style) than=20 > what I had been thinking. >=20 > --=20 > Cheers, >=20 > Pete >=20 > --------------------------------------------------- > "Therefore it can be said that victorious warriors=20 > win first, and then go to battle, while defeated=20 > warriors go to battle first, and then seek to win."=20 > - Sun Tzu, the Art Of War > --------------------------------------------------- >=20 > -- > To unsubscribe, e-mail: = > For additional commands, e-mail: = >=20 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: For additional commands, e-mail: