[Top][All Lists]
[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 19:02:55 +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:
> 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
- Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script., (continued)
- Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script., Ralf Wildenhues, 2010/09/16
- Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script., Peter Rosin, 2010/09/17
- Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script., Stefano Lattarini, 2010/09/17
- Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script., Peter Rosin, 2010/09/21
- Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script., Stefano Lattarini, 2010/09/21
- Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script., Peter Rosin, 2010/09/21
- Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script., Stefano Lattarini, 2010/09/21
- Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script., Peter Rosin, 2010/09/21
- Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script.,
Stefano Lattarini <=
- Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script., Ralf Wildenhues, 2010/09/15
- Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script., Stefano Lattarini, 2010/09/15
- Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script., Ralf Wildenhues, 2010/09/16
- Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script., Peter Rosin, 2010/09/16
- branches, and, well, more branches (was: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script.), Ralf Wildenhues, 2010/09/16
Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script., Peter Rosin, 2010/09/15