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))
>
On 12/06/11 09:36, Jim Meyering wrote:
> I am very reluctant to
> sacrifice the above default solely to accommodate that system.
Yes, the "make" chatter is annoying, but on the other
hand being portable is pretty important too. It's not just
NonStop; NextStep 'make' has a similar problem, and I w
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
On Tue, Dec 6, 2011 at 11:11 AM, Stefano Lattarini
wrote:
> Hi Adam.
>
> On Tuesday 06 December 2011, Adam Spiers wrote:
>> On Mon, Dec 5, 2011 at 7:28 PM, Stefano Lattarini
>> > Ping? I will push this by tomorrow if there is no review by then, since
>> > having a suboptimal and/or confusing word
Hi Adam.
On Tuesday 06 December 2011, Adam Spiers wrote:
> On Mon, Dec 5, 2011 at 7:28 PM, Stefano Lattarini
> > Ping? I will push this by tomorrow if there is no review by then, since
> > having a suboptimal and/or confusing wording on the main webpage is
> > still better that having lots of bro
16 matches
Mail list logo
