.deps/ handling for the changed objects from parent directory

[Alexey Mahotkin]

Hello,

I believe I've found a bug in Automake 1.5 (and in current versions
from CVS, because that code hasn't changed.

The essence of the bug is that when the Automake is trying to recreate
a .o file from the parent directory, it uses wrong .deps/ directory:
it simply prepends it to the file name, while it should be a bit
smarter.

Suppose we have a simple hello world program, with 'hello.c' in the
top dir, and the main.c in the sdir/.  Program from sdir/ depends on a
.o file from the top dir.

We 'make' everything from the top dir, the we remove the hello.o file
(or somehow else make it obsolete wrt hello.c).   Then we go to the
sdir/ and try to build the program.  Note the erroneous $depfile
value: it actually should be depfile=../.deps/hello.Po. 

### Making hello.o obsolete, and rebuilding from sdir/
source='../hello.c' object='../hello.o' libtool=no \
depfile='.deps/../hello.Po' tmpdepfile='.deps/../hello.TPo' \
depmode=gcc /bin/sh ../depcomp \
gcc -DPACKAGE=\"alexm-bug\" -DVERSION=\"0.01\"  -I. -I.     -g -O2 -c `test -f 
../hello.c || echo './'`../hello.c
gcc  -g -O2   -o hello-bug  main.o ../hello.o 
gcc: ../hello.o: No such file or directory
make: *** [hello-bug] Error 1


You now see the hello.Po file in the sdir/ subdirectory.  And whoa,
the hello.o is in the subdirectory, too!  This is a bug.


It now bites me full-time :)  

Solution: the regex in line 34 of lib/depcomp should somehow be fixed
to take into account the additional subdirectories.

I've attached a tiny sample reproducing this bug (yes, the library
file is in the top directory, and the executable is in subdirectory:
in my case that's src/ and src/tests/).

To reproduce it, do the

   $ ./configure
   $ ./reproduce.sh

and look into the sdir/ to see the hello.* there.


Please keep me in Cc: because I'm not subscribed to this list.  Feel
free to contact me if more details needed.


Thanks,

--alexm

alexm-bug-0.01.tar.gz
Description: Binary data