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
