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

[Stefano Lattarini]

On Tuesday 21 September 2010, Peter Rosin wrote:
> 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.
Yes, that was I meant and what I thought you meant.  Sorry that I 
failed to understand you correctly, my english is still pretty shaky.
> Which is exactly what you wrote below, with a few more words.
At least I managed to make myself understood.
 
> >> 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.

> > 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'.
> 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.
 
> >> 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 ;-).
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 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.

> > 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.
> 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.
 
> >> 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.
 
> 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.
Yes.  Luckily, we are not dealing with them here :-)

> >> -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.
Yes, like `-Wall' is.
> I didn't get that, but it doesn't change much either.
OK.
 
> >>>> 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 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?

Regards,
   Stefano