automake-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script.


From: Peter Rosin
Subject: Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script.
Date: Tue, 21 Sep 2010 11:54:55 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2

Den 2010-09-17 11:58 skrev Stefano Lattarini:
> On Friday 17 September 2010, Peter Rosin wrote:
>> Den 2010-09-16 20:03 skrev Ralf Wildenhues:
>>>> +
>>>> +      if (! $seen_ar)
>>>> +  {
>>>> +    msg ('portability', $where,
>>>> +         "`$onelib': linking libraries requires "
>>>> +         . "`AM_PROG_AR' in `$configure_ac'")
>>>
>>> I'm kinda wondering whether and how we can make this a bit less
>>> daunting for the user.  Not sure whether to invent another
>>> warning category, or mention "w32" here, or something else that
>>> makes it clear that the world isn't going to end.  Below too, of
>>> course.
>>
>> But w32 is wrong too, since it doesn't affect GNU on w32. But I see
>> your point, you want it to be just a hint, not a warning. Maybe it
>> should just be a diagnostic message which doesn't cause automake
>> -Wall -Werror to fail at all?
> Or what about doing somethins similar to what gcc does, and add a new 
> `-Wextra' category whose warnings are *not* enabled by `-Wall', but 
> which, when enabled, still causes `automake -Werror' to fail?  This 
> (assuming your warning will become an "extra" one) would also have the 
> positive collateral effect of not forcing you to change *any* existing 
> test.  WDYT?

I'm not too thrilled if there would be no sign of a needed
AM_PROG_AR when "automake -Wall" is used.  I'm not sure if
anybody will ever add AM_PROG_AR without a poke if it's that
invisible.  But as always in these decisions, I'm biased so
take this with a grain of salt...

Cheers,
Peter



reply via email to

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