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
