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

[Török Edwin]

On Thu, 11 Nov 2010 20:42:05 +0100
Ralf Wildenhues <address@hidden> wrote:

> 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.

They do incremental builds to save some time, there are parts of the
code that rarely change.
Bots aren't the only ones affected, team members and some git users too.
Have to tell them "automake bug, run 'make distclean'".
Some people know to retry running 'make clean', or rerunning
configure. distclean is not very popular.

> 
> > 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.

OK, then how about:
 - make clean deletes .Po/.Plo files, and invokes config.status with
   proper flags to produce the stub .Po files?

Having the old .Po files around after a make clean isn't going to help
speed up the build anyway since all the obj files are gone.

> 
> >  - 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).

See above, it could just generate the dummy .Po files.
But of course that would mean that updating Makefile.am/configure could
result in rebuild of entire project, which is not good.

If there was some way to check that .Po files are still valid, then
config.status could do that, and replace them with dummy ones if
they're not valid. 
Like checking if the source file declared in the .Po file still exists.
Not sure how easy or hard that would be to do in portable shell
programming. Probably not impossible though ;)

Best regards,
--Edwin