ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Oxspring" <roxspr...@yahoo.com>
Subject RE: Smarter Javac
Date Tue, 20 Nov 2001 23:12:40 GMT


> -----Original Message-----
> From: Rob Oxspring [mailto:roxspring@yahoo.com]
> Sent: Tuesday, November 20, 2001 8:59 PM
> To: Ant Developers List
> Subject: RE: Smarter Javac
> 
> 
> 
> > -----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
> > 
> > 
> > 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 
> > would have
> > > to be split into two invocations of the javac task? 
> > 
> > right.
> > 
> > > In which case, the colour need only be cached on a per task basis.
> > 
> > If every task operated on the same set of data everytime then 
> that would 
> > work. The problem is that the source files for each task may 
> > 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.

Scratch that - it's when you use antcall (and templating I guess) that the contents can be
radically different isn't it? I think I'll have to go back to the drawing board if antcall
is going to be handled nicely...

Rob

> 
> 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.
> 
> > 
> > > The issue of cache size /
> > > read speed should be mute here, since a single aggregated cache 
> > file would
> > > have a size roughly proportional to the build file.
> > 
> > I think you are trying to treat it in the same fashion as the c 
> > world treats 
> > autoconf values ? 
> 
> 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" 
> > file that lists 
> > all these values yer?
> Thats about the size of it.
> 
> > 
> > Iwas thiking about integrating it more into runtime like .deps 
> files are 
> > handled in c world. 
> 
> 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...
> 
> > 
> > Thoughts?
> > 
> > > 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.
> > 
> > It is up to the task to determine which parameters are relvent - 
> > this may or 
> > 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.
> 
> > 
> > > An ant file build.xml:
> > > <project name="xyz" basedir=".">
> > > 	<target name="init"><property file="defaults.props"/></target>
> > > 	<target name="compile" depends="init">
> > > 		<javac debug="${debugmode}" src="..."/>
> > > 		<javac debug="${debugmode}" src="...">
> > > 			<fileset .../>
> > > 			<fileset .../>
> > > 		</javac>
> > > 	</target>
> > > </project>
> > >
> > > Would just have a file build.color:
> > > <project color="MD5-012335765342">
> > > 	<target name="init" color="MD5-012335765342">
> > > 		<property color="MD5-012335765342"></target>
> > > 	<target name="compile" color="MD5-1231345345">
> > > 		<javac color="12341234"/>
> > > 		<jaavc color="57473982"/>
> > > 	</target>
> > > </project>
> > >
> > > 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 
> > or not though
> > > - its late)
> > 
> > interesting. Something to think about.
> > 
> > > If the colour is calculated at the getting and setting stage 
> > (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 
> > be changed
> > > to take advantage of this new information as necessary.
> > >
> > > Please shout me down if I'm being daft and missing points here.
> > 
> > actually your proposing a different interpretation (ie autoconf 
> > style) than 
> > what I had been thinking.
> > 
> > -- 
> > Cheers,
> > 
> > Pete
> > 
> > ---------------------------------------------------
> > "Therefore it can be said that victorious warriors 
> > win first, and then go to battle, while defeated 
> > warriors go to battle first, and then seek to win." 
> >               - Sun Tzu, the Art Of War
> > ---------------------------------------------------
> > 
> > --
> > To unsubscribe, e-mail:   
<mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
> 


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message