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

From: Török Edwin <[email-masked]>
Date: Thu, 11 Nov 2010 14:11:44 +0200

Hi,

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.

Tried a 'make clean', but it doesn't fix it, rerunning configure
doesn't fix it either.
Only a 'make distclean' and rerunning configure fixes it.

Versions:
autoconf (GNU Autoconf) 2.67
automake (GNU automake) 1.11.1
ltmain.sh (GNU libtool) 2.2.6b
gcc version 4.4.5 (Debian 4.4.5-6)

Minimal example attached as automake-move-bug.tar.gz, here are the
steps to reproduce the bug:

# Build initially, all good
autoreconf -fvi && ./configure && make
# Clean and rebuild, all good
make clean && make
# Move file around
mkdir test2
mv test1/Foo.c test2/Foo.c
mv test1/foo1.h test2/foo1.h
sed -ie 's/test1/test2/' Makefile.am
# Regen, and rerun configure, good so far
autoreconf -fvi && ./configure
# This one fails, but should work:
make || echo "Make failed, but should have worked!"
# Lets try cleaning and making again, fails too
# However I think 'make clean' should fix this as last resort, not
# distcheck. 
make clean && make || 
echo "Make clean, and remake failed, but should have worked!"
# Lets try distclean, this finally works
make distclean && ./configure && make

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

I think that:
 - make clean should remove the dependency files if they're out of
   date/wrong
 - rerunning configure or config.status should regen the dependencies
   properly, and not rely on some old, out-of-date dependencies

Best regards,
--Edwin