bug#7374: Automake bug when moving files to different directory

[Ralf Wildenhues]

Hi Török,

thanks for the bug report.

* Török Edwin wrote on Thu, Nov 11, 2010 at 01:11:44PM CET:
> Whenever I move a C/C++ file from a directory to another (and update
> Makefile.am), a subsequent 'make' fails because it is looking for the
> file in the old place (the .Plo dependency file actually).
> 
> For exampling moving test1/Foo.c to test2/Foo.c results in this error:
> make: *** No rule to make target `test1/Foo.c', needed by `Foo.lo'.
> Stop.

Confirmed.  This is the "deleted header file" problem (discussed in the
list archives, and in the manual), except that for you it applies to the
primary source file, not included headers.

For the headers we work around the issue by adding
  header.h:

lines in the .Po files for each included header (non-ancient gcc
versions do this for us, for other compilers depcomp does it).  We don't
do this for the primary source files.  I think this is so that we get a
sensible error from make when some primary source file isn't present
(haven't checked archives on this yet, though).

> This is a bit annoying when it happens, because it breaks our
> buildbots, and have to login to each one and run make distclean
> manually (or zap the builddir) to fix it.

How come this happens at all for your buildbots?  Do they do incremental
builds only, rather than full rebuilds from scratch?  I'd expect bots to
mostly do the latter, unlike developers while hacking.

> Fortunately we don't move
> around files that much (this is only 2nd time it occured in a few
> years, and 1st time I wrote a testcase, but forgot to file the
> bugreport).

Good.  So this isn't a pressing issue.

> I think that:
>  - make clean should remove the dependency files if they're out of
>    date/wrong

That is unfortunately not possible, because make will barf if files
included from the Makefile are missing.  GNU make has '-include' for
this, but there is no equivalent of that for portable make.

This is the reason that config.status produces stub .Po files when they
are not present.

>  - rerunning configure or config.status should regen the dependencies
>    properly, and not rely on some old, out-of-date dependencies

Oh, we really believe in tracking dependencies on the fly for
compilation, i.e., we try to avoid extra invocations of the compiler in
order to compute dependency information (at least with capable
compilers).

Hope that helps.

Cheers,
Ralf