On 12/26/11 13:35, Stefano Lattarini wrote:
> testing on non-Linux systems (*BSD and Solaris at least, hopefully also
> Cygwin or MinGW).
I tested it on Solaris 8 and that test worked fine.
I used Autoconf 2.63, GNU m4 1.4.13, and the system-supplied 'make'.
Some of the other tests failed, e.g.,
On 12/26/2011 07:09 PM, Paul Eggert wrote:
> On 12/26/11 09:42, Stefano Lattarini wrote:
>> And here is the follow-up tweaking for the test cases I had
>> promised. I will push in a couple of days if there is no objection.
>
> Thanks, that looks good to me; please push it as soon as you like.
>
D
On 12/26/11 09:42, Stefano Lattarini wrote:
> And here is the follow-up tweaking for the test cases I had
> promised. I will push in a couple of days if there is no objection.
Thanks, that looks good to me; please push it as soon as you like.
tags 10237 + patch
tags 9928 + patch
thanks
On 12/25/2011 07:04 PM, Paul Eggert wrote:
> On 12/23/11 00:50, Stefano Lattarini wrote:
>> could you apply the patch *not to maint nor to master*, but to a *new*
>> branch (say `silent-fixes' or `silent-portability') based off of maint,
>> and push that
On 12/23/11 00:50, Stefano Lattarini wrote:
> could you apply the patch *not to maint nor to master*, but to a *new*
> branch (say `silent-fixes' or `silent-portability') based off of maint,
> and push that new branch to the public automake repo?
OK, done, as 'silent-fixes', with your recent nit-f
[adding automake-patches -- which I should have done before]
On 12/22/2011 10:56 PM, Paul Eggert wrote:
> On 12/21/11 04:21, Stefano Lattarini wrote:
>> Hi Paul, thanks for the respin. My comments and objections are inlined.
>
> Thanks, I have a patch updated with all those comments in mind.
> O
On 12/21/11 04:21, Stefano Lattarini wrote:
> Hi Paul, thanks for the respin. My comments and objections are inlined.
Thanks, I have a patch updated with all those comments in mind.
One followup:
> AM_AM_DEFAULT_VERBOSITY ?
I changed that to AM_DEFAULT_V, as that seems to fit into the naming
co
Hi Paul, thanks for the respin. My comments and objections are inlined.
On 12/21/2011 02:30 AM, Paul Eggert wrote:
> On 12/11/11 01:42, Stefano Lattarini wrote:
>
>> I was asking for a test case that simulates the presence of a
>> make implementation unable to grasp nested variable expansions
>
On 12/11/11 01:42, Stefano Lattarini wrote:
> I was asking for a test case that simulates the presence of a
> make implementation unable to grasp nested variable expansions
Ah, OK, revised patch enclosed below. This patch should address
your other comments too. Thanks for the careful review.
>
Hi Paul.
On Saturday 10 December 2011, Paul Eggert wrote:
> On 12/06/11 11:02, Stefano Lattarini wrote:
> > If you are interested in accomodating this fringe situation, I will
> > then accept a patch on the lines Paul has proposed (with a mandatory
> > testcase, otherwise it would be far too easy
On 12/06/11 11:02, Stefano Lattarini wrote:
> If you are interested in accomodating this fringe situation, I will
> then accept a patch on the lines Paul has proposed (with a mandatory
> testcase, otherwise it would be far too easy to regress in such a
> almost-never-excercised corner case).
OK, a
On Tue, 2011 Dec 6 20:23-0700, Eric Blake wrote:
>
> Yes, use of $(${}) is specifically unspecified by POSIX 2008, and use
> of that extension means you are on unportable ground. The goal is
> that POSIX 201x will require it, and that eventually make
> implementations will catch up to POSIX, but
On 12/06/2011 08:20 PM, Daniel Richard G. wrote:
>> I wanted a solution that worked
>> on any POSIX platform -- POSIX 2008 says that
>> $(aaa${bbb}) is just as unspecified as
>> $(aaa$(bbb)) is, and I wanted to play it safe.
>>
> As I see it, the only real way to play it safe here, per POSIX, is to
On 12/06/2011 08:10 PM, Daniel Richard G. wrote:
> On Tue, 2011 Dec 6 16:26-0700, Eric Blake wrote:
>>
>> Yes, since we already do other configure checks for make capabilities,
>> and substitute that into Makefile.in when producing Makefile. And no
>> one said we have to run all the checks on all
On Tue, 2011 Dec 6 16:15-0800, Paul Eggert wrote:
> On 12/06/11 15:16, Daniel Richard G. wrote:
>
> > (Paul: Does $({}) work on NonStop?)
>
> I don't know, sorry.
>
> I wanted a solution that worked
> on any POSIX platform -- POSIX 2008 says that
> $(aaa${bbb}) is just as unspecified as
> $(aaa$
On Tue, 2011 Dec 6 16:26-0700, Eric Blake wrote:
>
> Yes, since we already do other configure checks for make capabilities,
> and substitute that into Makefile.in when producing Makefile. And no
> one said we have to run all the checks on all the platforms - it may
> be sufficient to detect multi
On 12/06/11 15:16, Daniel Richard G. wrote:
> (Paul: Does $({}) work on NonStop?)
I don't know, sorry.
I wanted a solution that worked
on any POSIX platform -- POSIX 2008 says that
$(aaa${bbb}) is just as unspecified as
$(aaa$(bbb)) is, and I wanted to play it safe.
Part of this is my experience
On 12/06/2011 04:16 PM, Daniel Richard G. wrote:
> Replacing a few parens with curly-braces on all platforms is ugly, but
> running an additional configure check on all platforms is nice?
Yes, since we already do other configure checks for make capabilities,
and substitute that into Makefile.in wh
On Tue, 2011 Dec 6 11:48-0700, Eric Blake wrote:
>
> Personally, I'm in favor of the idea. It seems very simple at being
> able to address the non-POSIX concern that Ralf first expressed when
> silent make was introduced - it gives us a working solution on the few
> platforms that don't do nested
reopen 10237
tags 10237 - wontfix
thanks
On Tuesday 06 December 2011, Eric Blake wrote:
>
> >> I'm extremely reluctant to add yet more complexity to automake
> >
> > I don't see this change as adding much complexity. It should be
> > pretty simple, and it shouldn't affect Automake much. So I gu
On 12/06/2011 11:40 AM, Paul Eggert wrote:
> On 12/06/11 10:19, Stefano Lattarini wrote:
>> which will also very likely be in the next POSIX standard, if I'm not
>> mistaken)
>
> Do you have a reference for that? That would allay some of
> my concerns in this area, moving forward.
http://austing
On 12/06/11 10:19, Stefano Lattarini wrote:
> which will also very likely be in the next POSIX standard, if I'm not
> mistaken)
Do you have a reference for that? That would allay some of
my concerns in this area, moving forward.
> I'm extremely reluctant to add yet more complexity to automake
I
tags 10237 wontfix
close 10237
thanks
Hi Paul, thanks for the report.
On Tuesday 06 December 2011, Paul Eggert wrote:
> If AM_SILENT_RULES is used, Automake generates Makefile.in
> files with lines like this:
>
> AM_V_CC = $(am__v_CC_$(V))
> am__v_CC_ = $(am__v_CC_$(AM_DEFAULT_VERBOSITY))
>
If AM_SILENT_RULES is used, Automake generates Makefile.in
files with lines like this:
AM_V_CC = $(am__v_CC_$(V))
am__v_CC_ = $(am__v_CC_$(AM_DEFAULT_VERBOSITY))
and these are copied into Makefile unchanged. Unfortunately, as
the Automake documentation notes, these lines do not conform to
th
24 matches
Mail list logo
