[PATCH 3/7] tests: remove dead code from t/make-dryrun.tap

Signed-off-by: Stefano Lattarini --- t/make-dryrun.tap | 2 -- 1 file changed, 2 deletions(-) diff --git a/t/make-dryrun.tap b/t/make-dryrun.tap index 208b421..a7597a3 100755 --- a/t/make-dryrun.tap +++ b/t/make-dryrun.tap @@ -38,8 +38,6 @@ echo AC_OUTPUT >> configure.ac cat > Makefile.am <<'EN

[PATCH 0/7][PATCH 0/7] Fix automake bug#12554.

Reference: I will apply this series in a couple pf days, barring objections. Feedback and testing is welcome Stefano Lattarini (7): tests: expose bug#12554 (false positives for presence of '-k' make option) header-vars: new variable $(am__r

[PATCH 7/7] tests: avoid a spurious error with Solaris make

* t/make-keepgoing.tap (Makefile.am): Here. Signed-off-by: Stefano Lattarini --- t/make-keepgoing.tap | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/make-keepgoing.tap b/t/make-keepgoing.tap index a81bf6c..a71d2d0 100755 --- a/t/make-keepgoing.tap +++ b/t/make-keepgoing.ta

[PATCH 6/7] subdirs: don't return false positives for the '-k' option's presence

This change fixes automake bug#12554. The old implementation of the code descending into $(SUBDIRS) entries used the following snippet to decide whether make is running with the '-k' a.k.a. '--keep-going' option, and thus whether a failure in a subdirectory should prevent the descent in the follow

[PATCH 5/7] header-vars: recognize more make flags ('-k' in particular)

* lib/am/header-vars.am (am__running_with_option): Here. Few improvements to comments, while at it. (am__make_keepgoing): New, tell whther make is being runt with the '-k' option. * t/make-keepgoing.tap: New test. * t/list-of-tests.mk: Add it. * t/make-dryrun.tap: Minor edits to keep it more in syn

[PATCH 4/7] header-vars: simplify how make flags are determined

Actually, son far only the '-n' option ("dry mode") was detected, but this change will allow us to soon detect more options. * lib/am/header-vars.am (am__running_with_option): Even when $MAKEFLAGS appears to contain definition of variables with embedded whitespace, use simple textual pre-processin

[PATCH 1/7] tests: expose bug#12554 (false positives for presence of '-k' make option)

The current implementation of the code descending into $(SUBDIRS) entries uses the following snippet to decide whether make is running with the '-k' a.k.a. '--keep-going' option, and thus whether a failure in a subdirectory should prevent the descent in the following ones: fail= failcom='exit

[PATCH 2/7] header-vars: new variable $(am__running_with_option)

This is a preparatory refactoring, needed by later patches. No semantic change is intended. * lib/am/header-vars.am (am__running_with_option): New, contains shell code that determines whether the current make instance is running with a given one-letter option (e.g., -k, -n) that takes no argument.

Re: bug#12554: Checking MAKEFLAGS with RECURSIVE_TARGETS

severity 12554 minor tags 12554 + patch thanks On 10/01/2012 11:52 PM, Michael Daniels wrote: > Hello, > Hi Michael, sorry for the delay. > automake 1.11.3 > make 3.81 > Linux 3.2.0-23-generic x86_64 > > Just to get some initial context, automake is generating this code for > recursive targets:

[FYI] {branch-1.13.2} sync: update files from upstream with "make fetch"

* lib/config.guess: Likewise. * lib/config.sub: Likewise. Signed-off-by: Stefano Lattarini --- lib/config.guess | 14 -- lib/config.sub | 6 +++--- 2 files changed, 15 insertions(+), 5 deletions(-) diff --git a/lib/config.guess b/lib/config.guess index f475ceb..2055429 100755 ---

[FYI] {branch-1.13.2} maintcheck: remove outdated whitelisting

* syntax-checks.mk (sc_tests_overriding_macros_on_cmdline): Here. The test 'make-dryrun.sh' has been since long rewritten as the TAP test 'make-dryrun.tap', and no longer spuriously triggers this maintainer check. Signed-off-by: Stefano Lattarini --- syntax-checks.mk | 10 ++ 1 file chan

Re: bug#13588: Pax hangs in case big UID

On 04/29/2013 08:11 AM, Pavel Raiskup wrote: > Hi! > >> I have re-introduced the line removed by mistake. > > It seems to be completely OK now, > Thanks, I will push shortly then, barring further objections. > thanks a LOT for your patience. > I think you and the other reviewers should be thanke