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 20:58:35 GMT

> -----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.

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>


Mime
View raw message