ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Smarter Javac
Date Wed, 21 Nov 2001 00:12:52 GMT
On Wed, 21 Nov 2001 07:58, Rob Oxspring wrote:
> 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.

yep. However it is usally not the size of the files that causes the slow down 
when reading (writing is a different matter), the access time to open the 
files is the real killer. (At least thats my experience from the makefile 
style system with large c/c++ builds).

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

basically they store "configuration" information that is local to your own 
system. In java terms they would store information like
* location of jar support libraries
* presence of libraries 
* and thus whether you should compile the optional parts of code base (ie 
don't compile TestCases if junit is not present)
* whether compiler should compile in debug/optimize/whatever mode

Sometimes the configure scripts will prompt users with questions (ie Do you 
want to enable feature X? Wheres location of library Y?) but more often than 
not it will try to auotmagically figure out answers based on environment and 
passed in switches.

Anytime you needed to change one of these values you reran configure which 
would regenerate config.cache again (which would usually trigger make to do a 
rebuild all next time it ran).

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

I don't know if auotmake generated this (I always used handcrafted makefiles) 
but it was convention that you generate dependency information about a file 
and store it in a .dep file. 

Each .dep file was basically another little make file.. It ended up looking 
something like

com/biz/ com/biz/ com/biz/ com/biz/

Which basically saids recompile if any of the other files change 
timestamps. We could go one better and only do recompiles if the relevent 
interface changed (ie public vs protected vs package access "interfaces" into 
an object).

Some times there would be one .dep file for whole project but more often than 
not in small-medium projects you would have one .dep file for every source 
file. These would sometimes be "massaged" by sed to include the coloring 
information from config.cache in large projects (so that changing 
config.cache didn't cause a rebuild all if config parameter only effected a 
small subset of files).

During the startup of make it would suck all these mini make files into 
itself to work out dependencies and all that. Everytime a file was recompiled 
it's dependencies were updated.

This system worked great if you were 
* using GNUMake
* had a fast filesystem
* had long recompile times and big project

As it stands now, ant only works in large java projects because compilers 
like jikes can do fastish recompiles. I have a suspicion it would completely 
fail in c/c++ areas without proper dependency generation etc.

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

maybe. Not sure it would work with current ant tasks ... it would be 
interesting to test it out ... actually I may play with that tonight ;)



"Sometimes its better to keep your mouth shut and 
let people think your an idiot, than to open it 
and remove all doubt." 

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message