bug#17354: distclean fails when source is relatively otherplace

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#17354: distclean fails when source is relatively otherplace

Jan Engelhardt

With automake-1.13.4 & automake-1.14, when there is a _SOURCES =
../blah.c, make does not properly run because .deps is gone too early.


File set:

# Makefile.am
SUBDIRS = b
noinst_PROGRAMS = foo

# configure.ac
AC_INIT([a],[0])
AM_INIT_AUTOMAKE([foreign subdir-objects])
AC_PROG_CC
AC_CONFIG_FILES([Makefile b/Makefile])
AC_OUTPUT

# foo.c
int main(void){return 0;}

# b/Makefile.am
noinst_PROGRAMS = bar
bar_SOURCES = ../foo.c


Observed:

01:43 wrgstfl:/dev/shm/testcase > make distclean
Making distclean in b
make[1]: Entering directory `/dev/shm/testcase/b'
test -z "bar" || rm -f bar
rm -f *.o
rm -f ../*.o
rm -f *.tab.c
test -z "" || rm -f
test . = "." || test -z "" || rm -f
rm -f ../.deps/.dirstamp
rm -f ../.dirstamp
rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
rm -rf ../.deps
rm -f Makefile
make[1]: Leaving directory `/dev/shm/testcase/b'
make[1]: Entering directory `/dev/shm/testcase'
Makefile:348: .deps/foo.Po: No such file or directory
make[1]: *** No rule to make target `.deps/foo.Po'.  Stop.
make[1]: Leaving directory `/dev/shm/testcase'
make: *** [distclean-recursive] Error 1


Expected:

Don't fail.


Additional information:

The problem is also observable without using "..";
foo_SOURCES = b/foo.c, bar_SOURCES = foo.c
also yields the same issue that one .deps is gone before the Makefile of
another directory is executed.



Reply | Threaded
Open this post in threaded view
|

bug#17354: distclean fails when source is relatively otherplace

Colomban Wendling
I just ran into this issue today trying to port a relatively large build
system to use `subdir-objects`.

This is quite annoying as everything else works just fine, but this bug
either prevents me from using `subdir-objects` at all or forces me to
rewrite these parts using a completely different approach.

Also, I would believe it should be relatively easy to fix as distclean
basically just *removes* files anyway.  And the fact the problem here is
that a file is already gone sounds a bit ironic :)



Reply | Threaded
Open this post in threaded view
|

bug#17354: distclean fails when source is relatively otherplace

Stefano Lattarini
In reply to this post by Jan Engelhardt
tags 17354 wontfix
close 17354
stop

On 04/27/2014 01:48 AM, Jan Engelhardt wrote:

>
> With automake-1.13.4 & automake-1.14, when there is a _SOURCES =
> ../blah.c, make does not properly run because .deps is gone too early.
>
>
> File set:
>
> # Makefile.am
> SUBDIRS = b
> noinst_PROGRAMS = foo
>
> # configure.ac
> AC_INIT([a],[0])
> AM_INIT_AUTOMAKE([foreign subdir-objects])
> AC_PROG_CC
> AC_CONFIG_FILES([Makefile b/Makefile])
> AC_OUTPUT
>
> # foo.c
> int main(void){return 0;}
>
> # b/Makefile.am
> noinst_PROGRAMS = bar
> bar_SOURCES = ../foo.c
>
>
> Observed:
>
> 01:43 wrgstfl:/dev/shm/testcase > make distclean
> Making distclean in b
> make[1]: Entering directory `/dev/shm/testcase/b'
> test -z "bar" || rm -f bar
> rm -f *.o
> rm -f ../*.o
> rm -f *.tab.c
> test -z "" || rm -f
> test . = "." || test -z "" || rm -f
> rm -f ../.deps/.dirstamp
> rm -f ../.dirstamp
> rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
> rm -rf ../.deps
> rm -f Makefile
> make[1]: Leaving directory `/dev/shm/testcase/b'
> make[1]: Entering directory `/dev/shm/testcase'
> Makefile:348: .deps/foo.Po: No such file or directory
> make[1]: *** No rule to make target `.deps/foo.Po'.  Stop.
> make[1]: Leaving directory `/dev/shm/testcase'
> make: *** [distclean-recursive] Error 1
>
>
> Expected:
>
> Don't fail.
>
>
> Additional information:
>
> The problem is also observable without using "..";
> foo_SOURCES = b/foo.c, bar_SOURCES = foo.c
> also yields the same issue that one .deps is gone before the Makefile of
> another directory is executed.
>
I would suggest using non-recursive builds, that solves many issues
this kind by giving make a better and complete view of the project
and its interdependencies.

I *might* end up fixing this bug if I manage to rework the dependency
tracking code to use the '-include' directive (which will require
dropping support for all make implementations not supporting such
directive, but I think that would be a good trade-off), but I'm not
making any promise.  You should keep in mind that non-recursive
builds are discouraged (except the very rare cases where the stuff
in a subdirectory is truly and completely independent from *all*
stuff in any other subdirectory), and we'll no longer actively work
on adding features or fixing bugs involving them.

Regards,
   Stefano