Re: Javac dependency checking

[Peter Donald <do...@apache.org>]

At 10:45  6/12/00 +0100, Stefan Bodewig wrote:
>James Duncan Davidson <du...@x180.net> wrote:
>
>> On 12/6/00 1:20 AM, "Stefan Bodewig" <bo...@apache.org> wrote:
>> 
>>> Because this has been ruled out back in May/June on
>>> ant-dev. Something along the lines of "I don't need it as I use
>>> jikes and doing a clean build is faster than having an explicit
>>> dependency tracker".
>> 
>> That assumes that it can't be turned off. But if there is an
>> attribute that allows it to be turned off for people who don't want
>> it (or is effectively ignored if compilertype="jikes"), then it's
>> not an issue, no?
>> 
>
>Wrong list for this discussion. 
>
>Anyway, I tend to agree with you - and did back in May - but the
>downside is that <depend> relies on a bunch of other classes and that
>would make <javac> more complicated.

+1

It would be very very useful to integrate it for those poor souls who don't
choose to use jikes ;) I would like to see Javac to become a facade for
lower level compilers. ie - instead of having logic for jikes/javac
modern/javac classic/microsoft/gnu/symantec compilers we should instead
place the code for these in seperate places and effectively pass them a
hashmap of properties post resolution in javac task. So once
classpath/bootpath is resolved and any dependencies zapped we should pass
the hashmap with something like

directory = blah
source = blee
files = [ a.java, b.java ... ]
verbose = false
...

What do you think of that ?




Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

Re: Javac dependency checking

[James Duncan Davidson <du...@x180.net>]

On 12/6/00 1:51 AM, "Peter Donald" <do...@apache.org> wrote:

> +1
> 
> It would be very very useful to integrate it for those poor souls who don't
> choose to use jikes ;) I would like to see Javac to become a facade for
> lower level compilers. ie - instead of having logic for jikes/javac
> modern/javac classic/microsoft/gnu/symantec compilers we should instead
> place the code for these in seperate places and effectively pass them a
> hashmap of properties post resolution in javac task. So once
> classpath/bootpath is resolved and any dependencies zapped we should pass
> the hashmap with something like

Righto. I totally agree with you on that. The Javac task would be, in
effect, several (on the order of 10 or so) class files by doing that, but
that would be fine by me if we had a better way of managing all these
options.



-- 
James Duncan Davidson                                        duncan@x180.net
                                                                  !try; do()