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

[Peter Rosin]

Den 2010-09-21 19:02 skrev Stefano Lattarini:
> On Tuesday 21 September 2010, Peter Rosin wrote:
>>>> is if it doesn't show up with -Wall and that it doesn't trip up
>>>> -Wall -Werror.
>>>
>>> Yes, sorry for not pointing it out explicitly.  This is a clean
>>> and clear behaviour, which we should not change IMO.
>>>
>>>> What is the problem with inventing a new warning class that
>>>> prints an informational messages but that doesn't trigger
>>>> -Werror?
> IMVHO, the problem is that it introduces exceptions and 
> inconsistencies that spoil the "clean and clear" behaviour
> I referred to above.

Yes, I never really liked the suggestion with messages sometimes
triggering -Werror and sometimes not.  But it's better than hiding
the messages from -Wall, methinks.

>>> The problem IMHO is that the semantic would become uselessly
>>> complex this way.
>>
>> If you want it easy and clean, I would argue that -Wportability
>> should trigger a portability warning, thank you very much.
> While still defending my position, I admit you have a point here.
> But then, please let `-Werror' fail even with the warning caused
> by a lacking `AM_AR_PROG', and forget about `-Wextra' and
> `-Wno-extra'.

(It's AM_PROG_AR)

Yes, that's what I want to do, and what the proposed patch does.

>> Otherwise it would become uselessly complex.  I think you should
>> think hard about exactly why you think you need different levels
>> of portability.  I guess I just don't see the problem with adding
>> it as a portability warning, other than the fact that lots of the
>> testsuite needs fixing, that it.
> This is not a problem per se; but it shows that we could have a
> potential problem "in the real world" -- we are breaking backward 
> compatibility, and all projects using automake for building static 
> libraries will need the tweaking our testsuite needed -- even if they 
> are not interested at all in building with MS tools.  All in all,
> this is not a very big deal (c'mon, it's just an added line in 
> configure.ac!), but needs to be accounted for.

If someone has put -Wall -Werror in AUTOMAKE_OPTIONS (or equivalent)
then they presumably want to know if they don't get the most out of
Automake.  By "hiding" this new warning in a new -Wextra class, we
are breaking backwards compatibility for all the projects that indeed
do want to know about everything in that they must suddenly add
-Wextra.

To be honest it's more than one line in configure.ac, it's also a new
file (ar-lib).

>>>> Then you could have the -Wextra option that turns the
>>>> informational messages into "real" warnings that trigger
>>>> -Werror (and -Wno-extra would silence the messages altogether).
>>>>  Or something.
>>>
>>> That sounds very confusing to me.
>>>
>>> Currently we just have:
>>>  -Werror => turns *all* enabled warnings into errors
>>>  -Wno-error => do not treat *any* warning as an error
>>>  -Wwarning-category => enable warnings of the given category
>>>  -Wno-warning-category => disable warnings of the given category
>>>
>>> Your proposal would introduce even more semantic differences
>>> for special values of "warning-category" (the new special value
>>> being "extra").  To be honest, if not for backward-compatibility
>>> (and consistency-compatibility with gcc) I'd even like to rename
>>> `-Werror' as e.g. `--warnings-are-errors' or something like that.
>>
>> To be honest, you introduced -Wextra with a semantic difference
>> (i.e. -Wall would no longer print *all* warnings).
> Well, it would print all the warnings it did before ;-).

Haha.

> And GCC behaves this way too (`-Wall' do not activate really *all* the 
> warnings, some are activated only by `-Wextra')
> But again, you have a point; if my proposal is accepted, we might
> add a notice that `-Wall' will add new backward-incompatible warnings
> in the next automake versions, and then, in those version, rename the
> old `-Wall' to `-Walmost-all' and old `-Wextra' to `-Wall'.  Not 
> pretty, admittedly, but could work.  But this is mostly bikeshedding 
> IMVHO.

I don't agree that a new warning is backwards incompatible.  Would you
object to any other new warning on the grounds that it will "break"
projects with the habit of using -Wall -Werror?

BTW, shuffling the names of these options after introducing them seems
like a sure way to create confusion.

>> I just added a little twist to it, namely that -Wall without
>> -Wextra would print the -Wextra messages as info but not
>> trigger -Werror.
> That's exactly what I find ugly and confusing.

I never liked it either, it was just a suggestion trying to move
this forward.  That failed, so let's drop it.

>>> My proposal avoids the semantic complication and keep the
>>> consistency compatibility with gcc; on the downside, it doesn't
>>> make msvc-related warnings stick out so clearly as the other
>>> ones, but this is a fair price to pay IMO (and with a very easy
>>> workaround: put `-Wextra' in AM_INIT_AUTOMAKE or
>>> AUTOMAKE_OPTIONS).
>>>
>>>> I.e. four states: silence, info, warning, error.
>>>>
>>>>> On the other hand, if we add a new warning class (say `-Wwin32'
>>>>> or `-Wwindows-portability') we'd allow the developers
>>>>> interested in porting to Windows to enable the relevant
>>>>> warnings (for now only the warning about missing AM_PROG_AR,
>>>>> but new ones can be added in the future), without hassling the
>>>>> developers interested in supporting only "true" Unix
>>>>> platforms.
>>>>
>>>> I don't like the special casing of Windows at all.
>>>
>>> But Windows is a special case... Luckily ;-)
>>
>> And that's the kind of thinking that cements it.  Why is it such a
>> special case?
> Because it's so different from other posixy systems, especially when 
> trying to use Microsoft development tools.  And I think this is a 
> fact, not an opinion.

Huh?  It has a compiler, a linker, and some tools to dig in object
files.  Etc.  Same sh*t, different name.  How can you say that the
tools are "so different" when you below claim to never have used them?

>> Because some people say that Windows sucks?
> I truly don't know whter it sucks or not; I never use it, so I can't 
> meaningfully tell.
>> Does that mean we should just give up?
> No, otherwise I'd have stated that plainly and explicitly.  When I 
> wrote in a previous message that I find your work useful, I really 
> meant that.

Ok.

>>>> Would you have suggested it for any other platform?
>>>
>>> The other platforms we support are not as different among them as
>>> they are different from Windows (at least from an Automake and
>>> Autoconf perspective, not sure about Libtool, but that shouldn't
>>> matter here).
>>
>> But if you just *decide* on how to handle it, it need not be all
>> that different, methinks.  I think the main problem is that noone
>> is willing to put in the effort.  That and the fact that people are
>> used to their way of handling Windows, so anything that makes some
>> corner case just a teeny weeny bit more difficult for someone is
>> seen as a major showstopper.  Combine that with the fact that many
>> people need to handle Windows and the corner cases start to pile
>> up, leading to a huge initial investment for anyone daring to try
>> to do something good.
> 
>> Oh, and people dare not think that Windows
>> could be handled just like any other platform, because they think
>> it shirley must be hard.  People also know, by heart, that Windows
>> is so horrible and broken that they will not bother to try to fix
>> problems properly.
> I'm not saying or thinking any of this.

No, I'm not saying that you are, but when you read between the lines
in virtually all FOSS forums, the above seems to describe the status
pretty well.

>>>>>> I'm not sure if anybody will ever add AM_PROG_AR without a
>>>>>> poke if it's that invisible.
>>>>>
>>>>> Hmmm... you have a point here, but I still hold my position.
>>>>> Maybe we should point clearly to the new
>>>>> `-Wwindows-portability' warning class in key places of the
>>>>> Automake manual (with proper examples)?  Or even add a whole
>>>>> new section about "building on Windows"?
>>>>
>>>> I'm not sure in what manual that section should be in though.
>>>
>>> Me neither; but "2.2 Use Cases for the GNU Build System" seems
>>> a good place (a new subsection "Build under Windows"?)
>>> Also, the section "8.2 Building a library" should be adjusted
>>> to account for your introduction.
>>>
>>> BTW, I think these documentation improvements would be valuable
>>> regardless of which proposal w.r.t. `-Wextra' is finally
>>> accepted.
>>>
>>>> I don't think having it spread out in all of autotools is the
>>>> most helpful way to do it.
>>>
>>> Sorry, I don't understand what you're meaning here :-(
>>
>> You are limiting your thinking to Automake.
> Yes, and admittedly so.
>> I asked in what manual, not in what part of the Automake manual.
> Well, I think that the explanations of how to portably build a
> static library with automake and the description of how automake
> can help porting posixy software to windows both pertains to the
> automake manual.

I was referring to your remark about a section on "building on Windows"
which perhaps should not be in the Automake manual.  The Automake
manual should of course cover the nitty details, but a general
section about "building on Windows" would perhaps fit better in
one of the tutorials on how to use Autotools in general.

> -*-*-
> 
> I think we have both managed to make our points and preferences clear 
> now; both our proposals have merits IMHO, and the final descision 
> (again IMHO) comes down to a matter of taste.  Let's wait for what 
> Ralf has to say, OK?

Agreed, I would also like Ralf's input on this.  So far he only said
that the warning message should be a little less daunting which
needless to say, is not the same as hiding it altogether.

Cheers,
Peter