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

[Stefano Lattarini]

On Wednesday 06 October 2010, Peter Rosin wrote:
> 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.
Not sure about that.  I think we should go either with my proposal
(-Wextra and -Wwindows) or your original proposal (-Wall also enables 
warnings about windows portability issues, and this warnings turn
into errors if -Werror is used).

Hmm... or maybe we could go with a third option: add a new `windows' 
warning class, which this time is turned on by `-Wall'.  This way, 
developers interested in seeing *all* warnings (and who thus use
`-Wall') would see also the windows-related warnings by default,
while developers not interested in windows porting could still use
`-Wall -Wno-windows' and live happily.  This has also the advantage
of not introducing another warning metaclass (`extra') and keeping
the `all' metaclass true to its name ("all warnings, really all of
them").  WDYT?
 
> >>> 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)
Oops, sorry.
 
> 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.
We are not breaking backwards compatibility; but indeed we are 
breaking a sort of "implicit contract" ("by using `-Wall', you enable 
*all* the warnings"), so you still have a good point.  My new proposal 
above would be immune to this objection, though (I think).
 
> To be honest it's more than one line in configure.ac, it's also a
> new file (ar-lib).
Yes, but the developer has not to care about it, since it's dealed 
with automatically by automake, right?

> [CUT]

> > 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?
Good point.  Still, it *is* backward-incompatible -- but the 
advantages of new warnings usually outweight by far the very minor
incompatibility that is introduced by them.  So you're right in
the end.

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

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

> [[ MEGA CUT ]]

> >> 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.
It should, if it explains *how automake can help* in making packages
build on windows.
> 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.
A *general* section about "building on Windows", yes.  But again,
the autotools' official docs don't have a tutorial among them.
Creating it would be great, but who's gonna to do that?  OTOH, adding
a section to the automake manual, even if non-optimal, would be much 
more feasible in the not-so-long term IMVHO, and still quite useful.

> > 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.
Sorry for my further reply, but I think the proposal I made above is
better than my old `-Wextra' proposal, so I felt the need to put it
forward.

Regards,
   Stefano