Bug 3520

Actually, I do not understand in which situation this happens.

If a *.java file is added, it is obligatory to re-run Makefile.gen.sh.
If this were not doen through bootstrap.sh, then the subsequent call to `make'
should trigger reconfigure[1], which in turn should clear the *.Po files.

(The obligation to re-run Makefile.gen.sh might be replaced by someting else in
future, see bug #3475, but that would not change the situation.)

Footnotees:
[1] Supposing our trees are not cursed by AM_MAINTAINER_MODE.

(In reply to comment #1)

Oh, I'm an idiot!

> If a *.java file is added, it is obligatory to re-run Makefile.gen.sh.
[BTW, I should have said "removed" here.]
> If this were not doen through bootstrap.sh, then the subsequent call to `make'
> should trigger reconfigure, which in turn should clear the *.Po files.

This is not true.  Makefile.gen was touched, thus automake is called to refresh
Makefile.in.  Then Makefile has to be remade; but this is done by
   cd $(top_builddir); ./config.status $(subdir)/Makefile

There is no reason to call ``full config.status'', so the `depfiles' commands
are not executed.

One hack comes to my mind:
Makefile.gen could be added to CONFIG_STATUS_DEPENDENCIES, so that each time it
is modified, a reconfigure is forced.

Or, more sensitively and less obscurely:
Whenever Makefile.gen.sh touches Makefile.gen, it would run
   ./config.status depfiles
to clear the *.Po files.

See also: http://sourceware.org/bugzilla/show_bug.cgi?id=3475#c2

> One hack comes to my mind:
> Makefile.gen could be added to CONFIG_STATUS_DEPENDENCIES, so that each time it
> is modified, a reconfigure is forced.
> 
> Or, more sensitively and less obscurely:
> Whenever Makefile.gen.sh touches Makefile.gen, it would run
>    ./config.status depfiles
> to clear the *.Po files.

I'm pretty sure that clearing the .Po files is not sufficient, and is in fact
very dangerous (that path was explored last year by ???).

Scrubbing the .Po file also scrubs valid dependencies that could be calling for
a rebuild.

The current workaround is to scrub the dependencies during:
  make clean
at least that way everything is going to be rebuilt anyway, so the contents of
the .Po file don't matter.

Something in the .Po file to ignore missing files might help - then the valid
dependencies would trigger a rebuild and a .Po file fix.  But that means hacking
the .Po code; oh, Makefile.rules already does that ;-).

BTW, this problem also serves as yet another example of how "The Automake Way"
fails to meet Java's constant file add/remove/rename needs.  While a basic
design flaw, its been ignorable.  With Java, though, it is a constant pain.