-
Show log
Commit
-
Hash : 08849db8
Author :
Date : 2015-01-03T01:33:45
deps: fix corner-case "make distclean" bug Assume we have package satisfying the following conditions: (1) automatic dependency tracking is enabled; (2) the 'subdir-objects' Automake option is enabled; (3) the package uses a recursive make setup. Also assume that: (a) a subdir Makefile declares a foo_SOURCES variable containing a source file in the parent directory; (b) that parent Makefile declare a compiled program itself. Then BSD and Solaris make used to fail when running "make distclean", because the 'distclean' target of the subdir Makefile removed the whole '.deps' directory before the parent Makefile was done with the included '.Po' makefile fragments in that directory. This issue was revealed by failures in the 'subobj-vpath-pr13928.sh' test when those make implementations were used. We fix the issue by ensuring the 'distclean' target of any Makefile only removed the '.Po' makefile fragments included by it, rather than the whole '.deps' directory where such files resides. This change should be the last step in fixing automake bug#13928 for good. * bin/automake.in (handle_languages), lib/am/depend.am: Adjust to implement the new 'distclean' logic. * t/pr224.sh: Adjust to avoid a spurious failure. * PLANS/subdir-objects.txt: Update. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
-
Properties
-
README
-
"Plans" for future or on-going Automake development. The contents is meant to help ensure a more controlled and smooth development and evolution for Automake, in several ways. - Having the plans clearly spelled out should will avoid messy roadmaps with no clear way forward or with muddy or ill-defined aims or purposes; a trap this is too easy to fall into. - Keeping planned changes cooking and re-hashed for a while should ensure rough edges are smoothed up, transitions are planned in a proper way (hopefully avoiding debacles like the AM_MKDIR_PROG_P deprecation and the AM_CONFIG_HEADER too-abrupt removal), and "power users" have more chances of getting informed in due time, thus having all the time to prepare for the changes or raise objections against them. - Having the plans clearly stated and registered in a "centralized" location should make it more difficult to them to slip through the cracks, getting forgotten or (worse) only half-implemented. - Even for discussions and plans registered on the Bug Tracker as well, a corresponding entry in the PLANS directory can help in keeping main ideas summarized, and consensus and/or objections registered and easily compared.