Re: RMIC dependency

[Nicholas Christopher <nw...@flashcom.net>]

Stefan Bodewig wrote:
> 
> Elardus Viljoen <el...@ucs.co.za> wrote:
> 
> > Stefan Bodewig wrote:
> >
> >> > Maybe it'a a problem that I'm using ant 1.1 and not 1.2?
> >>
> >> Could be. There have been some changes to Rmic after the 1.1
> >> release, maybe one of them fixed the behavior you have seen.
> >
> > Unfortunately, not the solution...  Is the easiest way to write my
> > own task that does a timestamp comparison?
> 
> No! Sorry, didn't want to shout.
> 
> The best - though maybe not easiest - you can do, is to find out why
> it doesn't work (if you look at the code you'll see it *does* perform
> timestamp comparisons).
> 
> I've never used rmic myself, if you could provide me with a simple
> test environment (a couple of source/class files and a build file)
> that shows this behavior, I'd be happy to help you nail down and fix
> the bug.
> 
> But I'll need your help here as I don't really know how to set up an
> environment like this.
> 
> Stefan


I've had the same problem. What I found was that javac/jikes was touching the
.class files every time.  For example:

$ ls *.java
Foo.java
$ javac *.java
$ # wait 10 minuites - do nothing to Foo.java
$ javac *.java

Foo.class will have the newer timestamp.  This is on Linux and javac and jikes
both do it.  So since the .class is always touched rmic always builds.  That's
my bet.
#wait ten minutes

Re: RMIC dependency

[Stefan Bodewig <bo...@apache.org>]

Nicholas Christopher <nw...@flashcom.net> wrote:

> Stefan Bodewig wrote:
>> 
>> Nicholas Christopher <nw...@flashcom.net> wrote:
>> 
>> > What I found was that javac/jikes was touching the .class files
>> > every time.  For example:
>> >
>> > $ ls *.java
>> > Foo.java
>> > $ javac *.java
>> > $ # wait 10 minuites - do nothing to Foo.java
>> > $ javac *.java
>> >
>> > Foo.class will have the newer timestamp.
>> 
>> Sure, javac has compiled it again, so what would you expect? While
>> Ant's <javac> task will only recompile files that have changed,
>> command line javac does not perform a similar check AFAIK.
>> 
>> Stefan
> 
> The way I'm used to seeing things done is to first javac everything
> that might need it and then to rmic things.

And if you do so in Ant, Ant is supposed to only compile (<javac>) the
files that have changed (which works if your environment has been set
up correctly) and <rmic> will only compile those classes that have
changed. The latter case should work in Ant 1.2 unless you say
stubversion=1.2, the CVS version is supposed to work for this as well.

> If javac restamps everything it's not clear how rmic can know when
> things are unchanged.

When using Ant's <javac>, the source files that have not changed will
not be passed to javac/jikes at all.

Stefan

Re: RMIC dependency

[Nicholas Christopher <nw...@flashcom.net>]

Stefan Bodewig wrote:
> 
> Nicholas Christopher <nw...@flashcom.net> wrote:
> 
> > What I found was that javac/jikes was touching the .class files
> > every time.  For example:
> >
> > $ ls *.java
> > Foo.java
> > $ javac *.java
> > $ # wait 10 minuites - do nothing to Foo.java
> > $ javac *.java
> >
> > Foo.class will have the newer timestamp.
> 
> Sure, javac has compiled it again, so what would you expect? While
> Ant's <javac> task will only recompile files that have changed,
> command line javac does not perform a similar check AFAIK.
> 
> Stefan

The way I'm used to seeing things done is to first javac everything that might
need it and then to rmic things. If javac restamps everything it's not clear how
rmic can know when things are unchanged.  I'd assumed that things had to be
handled properly upstream and to facilitate that javac/jikes would not rebuild
what didn't need it. Naive I guess.

Re: RMIC dependency

[Stefan Bodewig <bo...@apache.org>]

Nicholas Christopher <nw...@flashcom.net> wrote:

> What I found was that javac/jikes was touching the .class files
> every time.  For example:
> 
> $ ls *.java
> Foo.java
> $ javac *.java
> $ # wait 10 minuites - do nothing to Foo.java
> $ javac *.java
> 
> Foo.class will have the newer timestamp.

Sure, javac has compiled it again, so what would you expect? While
Ant's <javac> task will only recompile files that have changed,
command line javac does not perform a similar check AFAIK.

Stefan

Re: RMIC dependency

[Nicholas Christopher <nw...@flashcom.net>]

Stefan Bodewig wrote:
> 
> Nicholas Christopher <nw...@flashcom.net> wrote:
> 
> > I've had the same problem. What I found was that javac/jikes was
> > touching the .class files every time.  For example:
> 
> Should have reported here that Elardus had found a bug that was
> triggered when you set stubversion to 1.2. This version of rmic won't
> create _Skel files but Ant would still try to find them - and as they
> couldn't be found, Ant concluded it needed to recompile the class.
> 
> Has been fixed in CVS a few days ago.
> 
> Stefan

That didn't seem to help with me. Though stubversion="1.2" is far quicker than
stubversion="compat" but that is likely unrelated.

Re: RMIC dependency

[Stefan Bodewig <bo...@apache.org>]

Nicholas Christopher <nw...@flashcom.net> wrote:

> I've had the same problem. What I found was that javac/jikes was
> touching the .class files every time.  For example:

Should have reported here that Elardus had found a bug that was
triggered when you set stubversion to 1.2. This version of rmic won't
create _Skel files but Ant would still try to find them - and as they
couldn't be found, Ant concluded it needed to recompile the class.

Has been fixed in CVS a few days ago.

Stefan