ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Magesh Umasankar" <umag...@rediffmail.com>
Subject Re: Smarter Javac
Date Mon, 19 Nov 2001 15:45:50 GMT



On Mon, 19 Nov 2001 Peter Donald wrote :
> On Sat, 17 Nov 2001 19:18, Magesh Umasankar wrote:

> CONS can do it at the command line level as each command line execution is 
> compilation for one "source" file. Ant aggregates the command line and thus 
> has a slightly harder time.

I will discuss this in the context of colorings below...


> The problem is that we need to cache the information on a per file basis. 

Not necessarily - One should identify the arguments that truly change the
color of the command - for example, let me use a task with 'CacheId' Foo, 
during its first run did something equivalent to:

javac -g Bar.java

and in its second run did

javac -g -classpath FooBar.jar Bar.java

and in its third run did

jikes FooBar.java

In this case, only the attributes to this task, javac (compiler) and 
-g (debug) make it to the coloring - claspath and files may be 
safely ignored.  What I mean is that the first two runs are identical
in 'color' while the third run is not.  What makes a color list is 
those attributes that changes the outcome of the command in a 
fundamental manner.

Note here, that I am not trying to solve dependency checking.  So when a 
check is made to see if the coloring has changed, it sets a flag which states
whether all files are to be recompiled or whether whatever used to happen 
earlier should keep happening.  The reason why source files don't matter
is that the task, as it is currently written, is anway going to process it.

> This can a significant overhead to the compilation step and the exact 

Not necessarily.  You load the command cache when ant starts up.  This cache
would contain chacheId-checksum pairs.  Checksum calculation and comparison
is the only overhead - both of which don't access the disk.  Saving the
cache back would access the disk, but then we could do lazy saving.

> For small projects it is almost always easier and faster just to do a rebuild 
> all every time (assuming of course that you use jikes).

Yup.  And thats what they do now to overcome these drawbacks.

> I guess we need to identify the types of "dependency" information. The two 
> that we identified last time where 
> 1. structural
> 2. coloring

Nice terms ;-)

But they don't have to be tightly coupled.  Coloring refers to the state of
the 'command' while structural refers to the state of the fileset that the 
command works with.  One can exist with or without the other?

> (2) Coloring includes those things you talked about (ie compiler, debug 
> status optimizations turned on, etc). It would be up to the javac task to 
> identify the "relevent" parameters and chuck them in cache aswell.

Yes.  A task that can be 'colored' implements the Colorable interface which
has a method getColorableCommand which would return that specific portion
of the overall command that may or may not be colored.  This has to be
compared against the command that is currently generated.

> Now how to store this information? There is two extremes. One extreme saids 
> use a single cache for whole project while the other extreme saids have a 
> single dependency cache file per source file. There are also inbetween styles 
> (ie cache per package or perhaps per hierarchy). 

If we store the cache at a task level and assuming not all tasks are going
to support Colorable, we will have only a few entries in the cache on a 
per project basis.  But...

> However we need to leave it up to the build writer how to store this cache 

...the user may specify it as well?

> It would be nice to have a utility object that could do all this for us. So 
> in javacs case you could do something like
> 
> DependencyScanner ds = ...;
> 
> if( cachePerFileStrategy ) ds.setCacheStrategy( DependencyScanner.PER_FILE );
> else ds.setCacheStrategy( DependencyScanner.PER_DIR ); 
> 
> ds.addColoring( "debug", "true" );
> ds.addColoring( "compiler", "jikes" );
> ds.addColoring( "optimize", "false" );
> ds.addFileSet( sources1 );
> ds.addFileSet( sources2 );
>
> File[] filesToCompile = ds.scan();
> 
> doCompile( filesToCompile );

What if we decouple these functions?  Something like:

if (getColorableCommand().equals(prevRunsCommandLine)) {
	DependencyScanner ds = ...;
	
	if( cachePerFileStrategy ) ds.setCacheStrategy( DependencyScanner.PER_FILE );
	else ds.setCacheStrategy( DependencyScanner.PER_DIR ); 

	ds.addFileSet( sources1 );
	ds.addFileSet( sources2 );
}

> Unfortunately that only works if all the files were compiled successfully. If 
> not you have to figure out which ones were updated and which failed and 
> update dependency scanner/cache appropriately.

This would become mute if we throw the files out of the picture.  But again,
my fundamental idea of not considering files may be dead wrong. ;-)  So, please
provide your views.

> However this level of sophistication may have to wait till ant2 because it is 
> a lot of work.

:-(

Magesh

 


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