--- Begin Message ---
|
Subject: |
Automake bug when moving files to different directory |
|
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
automake-move-bug.tar.gz
Description: GNU Zip compressed data
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#7374: Automake bug when moving files to different directory |
|
Date: |
Thu, 11 Nov 2010 22:49:39 +0200 |
On Thu, 11 Nov 2010 21:38:01 +0100
Ralf Wildenhues <address@hidden> wrote:
> * Török Edwin wrote on Thu, Nov 11, 2010 at 09:10:56PM CET:
> > On Thu, 11 Nov 2010 20:42:05 +0100 Ralf Wildenhues wrote:
> > > * Török Edwin wrote on Thu, Nov 11, 2010 at 01:11:44PM CET:
> > > > 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.
>
> True, but the above sounds quite ugly as well.
>
> Here's a better suggestion: use the subdir-objects automake option
> (you can add it to the options passed to AM_INIT_AUTOMAKE)
Excellent, that does exactly what I wanted! (and my testcase works now)
> and
> configure with --enable-maintainer-mode.
> That way the old .Po file
> will just not be read any more, and the maintainer mode will trigger
> the automake rerun that then causes the rules in Makefile to be
> successfully updated.
Yes, I use maintainer-mode sometimes. For simple edits I tend to just
run 'automake' though, and commit Makefile.in.
>
> Hope that is good enough for you.
Yes, thanks a lot!
We are in code freeze right now, but I'll definetely make that change
after we're done.
We can close this bug now.
Best regards,
--Edwin
--- End Message ---