emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#9928: closed (AM_SILENT_RULES breakage with old ma


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#9928: closed (AM_SILENT_RULES breakage with old make(1))
Date: Fri, 30 Dec 2011 12:54:02 +0000

Your message dated Fri, 30 Dec 2011 13:50:04 +0100
with message-id <address@hidden>
and subject line Re: bug#10237: bug#9928: AM_SILENT_RULES does not work with 
NonStop make
has caused the debbugs.gnu.org bug report #9928,
regarding AM_SILENT_RULES breakage with old make(1)
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
9928: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9928
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: AM_SILENT_RULES breakage with old make(1) Date: Tue, 01 Nov 2011 00:37:23 -0400
Hello list,

I've recently encountered some breakage in building a package with
Automake 1.11.1's new silent-rules feature enabled, on a VM install of
NeXTSTEP 3.3. An example:

    $ make
    make  all-am
    ))  source='../pcre_compile.c' object='pcre_compile.lo' libtool=yes  
DEPDIR=.deps depmode=none /usr/local/bin/bash ../depcomp /usr/local/bin/bash 
./libtool )) --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I.. -O2 -c -o 
pcre_compile.lo ../pcre_compile.c
    sh: syntax error at line 1: `)' unexpected
    *** Exit 2
    Stop.
    *** Exit 1
    Stop.

I tracked this down to the variable-variable-name constructs used to
implement silent rules; this old version of make(1) doesn't parse them
correctly. I added the line

    echo "AM_V_CC = '$(AM_V_CC)'" # for automake debugging

to the .c.lo rule to see what was going on:

    $ make
    make  all-am
    echo "AM_V_CC = '))'" # for automake debugging
    AM_V_CC = '))'
    ))  source='../pcre_compile.c' object='pcre_compile.lo' libtool=yes  
DEPDIR=.deps depmode=none /usr/local/bin/bash ../depcomp /usr/local/bin/bash 
./libtool )) --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I.. -O2 -c -o 
pcre_compile.lo ../pcre_compile.c
    sh: syntax error at line 1: `)' unexpected
    *** Exit 2
    Stop.
    *** Exit 1
    Stop.

    $ make V=0
    make  all-am
    echo "AM_V_CC = '@echo "  CC    " pcre_compile.lo;)'" # for automake 
debugging
    AM_V_CC = '@echo  CC  pcre_compile.lo;)'
    sh: syntax error at line 1: `)' unexpected
    *** Exit 2
    Stop.
    *** Exit 1
    Stop.

    $ make V=1
    make  all-am
    echo "AM_V_CC = ')'" # for automake debugging
    AM_V_CC = ')'
    )  source='../pcre_compile.c' object='pcre_compile.lo' libtool=yes  
DEPDIR=.deps depmode=none /usr/local/bin/bash ../depcomp /usr/local/bin/bash 
./libtool ) --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I.. -O2 -c -o 
pcre_compile.lo ../pcre_compile.c
    sh: syntax error at line 1: `)' unexpected
    *** Exit 2
    Stop.
    *** Exit 1
    Stop.

I fiddled around with the assignments where $(AM_DEFAULT_VERBOSITY) and
$(V) are used. Turns out that if you change these assignments from e.g.

    AM_V_CC = $(am__v_CC_$(V))
    am__v_CC_ = $(am__v_CC_$(AM_DEFAULT_VERBOSITY))

to curly-braces-in-parens...

    AM_V_CC = $(am__v_CC_${V})
    am__v_CC_ = $(am__v_CC_${AM_DEFAULT_VERBOSITY})

or parens-in-curly-braces...

    AM_V_CC = ${am__v_CC_$(V)}
    am__v_CC_ = ${am__v_CC_$(AM_DEFAULT_VERBOSITY)}

...then the variable references are processed correctly, and the silent-
rules feature works as advertised.


--Daniel


-- 
Daniel Richard G. || address@hidden
My ASCII-art .sig got a bad case of Times New Roman.



--- End Message ---
--- Begin Message --- Subject: Re: bug#10237: bug#9928: AM_SILENT_RULES does not work with NonStop make Date: Fri, 30 Dec 2011 13:50:04 +0100
On 12/28/2011 09:19 PM, Stefano Lattarini wrote:
>
> I did some testing on Debian unstable, Solaris 10, NetBSD 5.1 and Cygwin 1.5 
> (in
> part by running the relevant test cases from the automake testsuite, in part
> trying out the build system of GNU coreutils).   Everything seems fine so far.
> I want to do some small improvements to the documentation, then I say we are
> ready to merge the 'silent-fixes' branch into maint.
>
I've just re-read Paul's changes to the manual, and on a second thought, I think
they are definitely good enough as they are.  I've thus merged the 
'silent-fixes'
branch into maint, and pushed.  I'm thus closing the bugs #9928 and #10237.

Thanks,
  Stefano


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]