Den 2010-09-21 14:35 skrev Stefano Lattarini: > On Tuesday 21 September 2010, Peter Rosin wrote: >> Den 2010-09-21 12:46 skrev Stefano Lattarini: >>> Now, many projects might not care at all to support this building >>> environment, while still wanting to use `-Wall' to catch common >>> pitfalls; in this scenario, a warning triggered by `-Wall' about >>> missing AM_PROG_AR would be just an annoyance. Worse again, the >>> use of `-Wall -Werror' would *force* the use of AM_PROG_AR and >>> ar-lib, and the developers of aforementioned projects might see >>> this forced additions as useless bloat. >> >> Aha, but now you are taking the position that the only way to not >> have it invisible > I guess you're meaning "the only way to have it invisible", right?
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. Which is exactly what you wrote below, with a few more words. >> 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? > 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. 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. >> 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). I just added a little twist to it, namely that -Wall without -Wextra would print the -Wextra messages as info but not trigger -Werror. > 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 some people say that Windows sucks? Does that mean we should just give up? >> 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. 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. >> -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. I didn't get that, but it doesn't change much either. >>>> 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. I asked in what manual, not in what part of the Automake manual. Cheers, Peter
