"Dan Kegel" dank@kegel.com 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.