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 16:10:41 +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-21 14:35 skrev Stefano Lattarini:
> On Tuesday 21 September 2010, Peter Rosin wrote:
>> Den 2010-09-21 12:46 skrev Stefano Lattarini:
>>> Now, many projects might not care at all to support this building
>>> environment, while still wanting to use `-Wall' to catch common
>>> pitfalls; in this scenario, a warning triggered by `-Wall' about
>>> missing AM_PROG_AR would be just an annoyance.  Worse again, the
>>> use of `-Wall -Werror' would *force* the use of AM_PROG_AR and
>>> ar-lib, and the developers of aforementioned projects might see
>>> this forced additions as useless bloat.
>>
>> Aha, but now you are taking the position that the only way to not
>> have it invisible
> I guess you're meaning "the only way to have it invisible", right?

Nope, read again. I think I had all the negations lined up correctly.

Rephrase: But now you are taking the position that the only way to
have the warning visible is if it shows up with -Wall and trips up
-Wall -Werror.

Which is exactly what you wrote below, with a few more words.

>> 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?
> 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.  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.

>> 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).  I just added a little
twist to it, namely that -Wall without -Wextra would print the
-Wextra messages as info but not trigger -Werror.

> 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 some people say that Windows sucks?  Does that
mean we should just give up?

>> 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.

Besides, the main problems are probably not in the build system,
which is what I'm talking about above.  I'd say that problems are
more often in the code.  At least the difficult problems.

>> -Wextra is much better.
> Oh, but in my proposal `-Wwindows-portability' would definitely be 
> enabled by `-Wextra'.

Ok, so you wanted -Wextra to be a meta-class.  I didn't get that,
but it doesn't change much either.

>>>> 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.  I asked in what
manual, not in what part of the Automake manual.

Cheers,
Peter



reply via email to

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