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: Stefano Lattarini
Subject: Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script.
Date: Tue, 21 Sep 2010 14:35:42 +0200
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

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

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 ;-)
> 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).
> -Wextra is much better.
Oh, but in my proposal `-Wwindows-portability' would definitely be 
enabled by `-Wextra'.
 
> >> 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 :-(

> Cheers,
> Peter

Regards,
   Stefano



reply via email to

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