"Dan Kegel" <[EMAIL PROTECTED]> writes: > Agreed, to an extent. A user who is trying to compile with a really > whacky toolchain (say, a C compiler on an Amiga, a mainframe, or a wristwatch) > should expect some errors, and we should not try to avoid those if they > reflect > real problems that need to be solved before wine can run properly.
You don't need a wacky toolchain. All you need is a slightly old gcc, or a platform that not everybody has access to, like Mac OS. I periodically build on Mac OS and check for warnings, and there are always a few that creep in, like size_t printf formats. Do you really think Wine would be better off if it failed to build on Mac 90% of the time? Is printing a size_t with %d really so dangerous that it needs to break the build? > And I also feel pretty strongly that compiler warnings have > some value, and we should pay attention to them. Right > now we're plugging our ears and going "la la la la la I can't hear you", > and that seems a bit careless. As Wine aims for higher and > higher quality levels, eventually we will have to change our ways here. That's absolutely not true. We are trying very hard to avoid warnings, I don't commit patches that add warnings, and many people are sending fixes when they find warnings on their platform. That doesn't mean they should break the build. > If we do it in the right way, it could end up increasing > our code quality quite a bit without inconveniencing any users. It wouldn't make any difference to code quality, since we are already warnings-free on most standard builds. > The right way is to slowly fix all the warnings -- like Andrew Talbot > is doing -- > and slowly encourage all wine developers to crank up their warning > levels to the max. Once we've voluntarily cleared out nearly all the > warnings, we can then have a flag day to clean out all the rest, > and switch -Werror on. That will keep errors from creeping back in. Everybody is free to build their tree with -Werror, but there's no way that it will become the default. -- Alexandre Julliard [EMAIL PROTECTED]
