.DEFAULT: rule

.DEFAULT: rule

[Andrew Cagney]

A heads up (and of course better solution welcome).

Automake's generated dependencies cause a build to fail when a file is 
removed.  This occures because the generated .Po file retains references 
to the removed files and make aborts the build with file not found.

I've now added this:
+.DEFAULT:
+       @echo " >>>>> .DEFAULT: $@ <<<<<"
to the build which tells make to ignore missing files.  If a file was 
really needed the build still dies but later when something goes to use 
the file.  If the file really wasn't needed, such as stale references in 
.Po files, the problem gets flushed out.

lets see how it goes,
Andrew

Re: .DEFAULT: rule

[Tom Tromey]

>>>>> "Andrew" == Andrew Cagney <cagney@redhat.com> writes:

Andrew> Automake's generated dependencies cause a build to fail when a file is
Andrew> removed.  This occures because the generated .Po file retains
Andrew> references to the removed files and make aborts the build with file
Andrew> not found.

The dependency file ought to contain dummy targets for all the headers.
See the automake dependency tracking white paper (well, used to be a
white paper, now moved into the manual)

http://sourceware.org/automake/automake.html#Dependency-Tracking-Evolution

If you aren't seeing these dummy targets, something is wrong.

Tom

Re: .DEFAULT: rule

[Andrew Cagney]

Tom,

As in the contents of the .Po file?  Reads gcc man page, the -MP 
option.  This is a typical .Po file:

frysk/proc/Id.o: ../../frysk/frysk-core/frysk/proc/Id.java \
  ../frysk-imports/jline.jar ../frysk-imports/antlr.jar \
  ../frysk-imports/junit.jar ../frysk-imports/getopt.jar \
  ../frysk-imports/jdom.jar ../frysk-imports/cdtparser.jar \
  /usr/share/java/libgcj-4.1.1.jar

below you'll see the rule being used to generate it (had to rewrite 
automake's to to work around gcj bugs).  It includes -MP option to 
generate those phony rules, but they are not there.

Andrew

# Given a .java file convert it to a .o file.
# XXX: GCJ has a bug where it totally scrambles nested classes with
# identical names.  Reject any code with duplicate class names.
# XXX: GCJ has a bug where, when given a -Werror fail, it still exits
# with success.  Hack around this by saving the message in a log file
# and then checking that it is empty.
.java.o:
        dups=`$(JV_SCAN) --list-class $< \
                | tr '[ ]' '[\n]' \
                | sed -n -e 's,^.*$$\([A-Z]\),\1,p' \
                | sort | uniq -d` ; \
        if test x"$$dups" != x ; then echo "Duplicate class names tickle 
a GCJ bug: $$dups" ; exit 1 ; fi
        depbase=`echo $@ | sed 's|[^/]*$$|$(DEPDIR)/&|;s|\.o$$||'`; \
        if $(GCJCOMPILE) -MT $@ -MD -MP -MF "$$depbase.Tpo" -c -o $@ $< 
2>&1 | tee $*.log && test ! -s $*.log ; \
        then mv -f "$$depbase.Tpo" "$$depbase.Po"; else rm -f 
"$$depbase.Tpo"; exit 1; fi
        rm -f $*.log



>
> The dependency file ought to contain dummy targets for all the headers.
> See the automake dependency tracking white paper (well, used to be a
> white paper, now moved into the manual)
>
> http://sourceware.org/automake/automake.html#Dependency-Tracking-Evolution
>
> If you aren't seeing these dummy targets, something is wrong.
>
> Tom
>   

Re: .DEFAULT: rule

[Tom Tromey]

>>>>> "Andrew" == Andrew Cagney <cagney@redhat.com> writes:

Andrew> As in the contents of the .Po file?

Yes.

Andrew> below you'll see the rule being used to generate it (had to rewrite
Andrew> automake's to to work around gcj bugs).  It includes -MP option to
Andrew> generate those phony rules, but they are not there.

Please file a bug report.

Andrew> # Given a .java file convert it to a .o file.
Andrew> # XXX: GCJ has a bug where it totally scrambles nested classes with
Andrew> # identical names.  Reject any code with duplicate class names.
Andrew> # XXX: GCJ has a bug where, when given a -Werror fail, it still exits
Andrew> # with success.  Hack around this by saving the message in a log file
Andrew> # and then checking that it is empty.

You could file these as well.
I have never heard of the second one before.
The first is probably fixed on svn trunk.

Tom