You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Marc Luce <ma...@blackbird.net> on 2000/12/05 16:12:44 UTC
Javac dependency checking
I remember that there was some discussion about this but I don't remember
the answer. Is there a way that if I change an inferface that I can
recompile the interface and all of the classes/interfaces that depend on it?
Re: Javac dependency checking
Posted by James Duncan Davidson <du...@x180.net>.
On 12/6/00 1:45 AM, "Stefan Bodewig" <bo...@apache.org> wrote:
> Wrong list for this discussion.
Oops.. Moved. I dump all Ant mail into the same mailbox so didn't notice..
:)
> 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.
Ok -- I can see that. As part of the roll up of tasks to Ant 2, we should
revisit this.
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: Javac dependency checking
Posted by 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()
Re: Javac dependency checking
Posted by 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
Posted by Stefan Bodewig <bo...@apache.org>.
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.
Stefan
Re: Javac dependency checking
Posted by James Duncan Davidson <du...@x180.net>.
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?
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: Javac dependency checking
Posted by Stefan Bodewig <bo...@apache.org>.
James Duncan Davidson <du...@x180.net> wrote:
> On 12/5/00 8:23 AM, "Stefan Bodewig" <bo...@apache.org> wrote:
>> put a
>>
>> <depend srcdir="${sourcedir}" destdir="${classes}"
>> cache="dep.cache" />
>>
>> right in front of
>>
>> <javac srcdir="${sourcedir}" destdir="${classes}" />
>>
> Cool enough -- but here's where I'll go against my minimalist grain
> -- why shouldn't it be part of the javac task?
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".
Stefan
Re: Javac dependency checking
Posted by James Duncan Davidson <du...@x180.net>.
On 12/5/00 8:23 AM, "Stefan Bodewig" <bo...@apache.org> wrote:
> It is not documented at the moment, you can search the archives for
> Conor's original mail on this task at
> <http://marc.theaimsgroup.com/?l=ant-dev&r=1&w=2>. Basically you put a
>
> <depend srcdir="${sourcedir}" destdir="${classes}" cache="dep.cache" />
>
> right in front of
>
> <javac srcdir="${sourcedir}" destdir="${classes}" />
>
> and this task will remove the .class files for all classes that depend
> on your changed interface - and javac is going to recompile them. The
> cache attribute points to a directory where <depend> caches
> information between builds - and it is optional.
Cool enough -- but here's where I'll go against my minimalist grain -- why
shouldn't it be part of the javac task? Just have it as a flag
"dependencycheck='yes'" or some such? Real dependency checking was *always*
on the want list for the javac task. This would do it.
.duncan
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: Javac dependency checking
Posted by Stefan Bodewig <bo...@apache.org>.
Marc Luce <ma...@blackbird.net> wrote:
> I remember that there was some discussion about this but I don't
> remember the answer. Is there a way that if I change an inferface
> that I can recompile the interface and all of the classes/interfaces
> that depend on it?
There is a new task named <depend> in CVS, it doesn't rely on any
other changes, so you should be able to just pick up the
...optional/depend/ directory and add the task itself via
<taskdef name="depend"
classname="org.apache.tools.ant.taskdefs.optional.depend.Depend" />
It is not documented at the moment, you can search the archives for
Conor's original mail on this task at
<http://marc.theaimsgroup.com/?l=ant-dev&r=1&w=2>. Basically you put a
<depend srcdir="${sourcedir}" destdir="${classes}" cache="dep.cache" />
right in front of
<javac srcdir="${sourcedir}" destdir="${classes}" />
and this task will remove the .class files for all classes that depend
on your changed interface - and javac is going to recompile them. The
cache attribute points to a directory where <depend> caches
information between builds - and it is optional.
Stefan