[SERVER-51178] Add ability to disable specific compiler warnings-as-errors from SCons Created: 28/Sep/20 Updated: 27/Oct/23 Resolved: 27/Oct/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Build |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Ryan Egesdahl (Inactive) | Assignee: | [DO NOT ASSIGN] Backlog - Server Development Platform Team (SDP) (Inactive) |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Server Development Platform
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
We currently have only two ways to disable compiler warnings-as-errors: either make none of them errors using --disable-warnings-as-errors or disable all errors with a compiler flag. There is no way to disable specific warnings-as-errors from the SCons command line due to the order of the compiler flags. This matters sometimes when we have a new issue pop up (such as in a new compiler version) where we want to see the warning but not fail the build. |
| Comments |
| Comment by Andrew Morrow (Inactive) [ 06/Jan/21 ] |
|
ryan.egesdahl - Generally, I don't like providing --option-to-do-something-to-flags when the same effect can be achieved by simply adding FLAG=value to the command line. Build system users in general (i.e. not just us) expect to be able to provide these sorts of flags via the usual command line mechanisms (CFLAGS, etc.). To the extent possible, we should be encouraging people to use them. The existence of --disable-warnings-as-errors is a consequence of the ordering bug around how we inject -Wall and -Werror. If we fixed that bug, we wouldn't actually need --disable-warnings-as-errors at all, because saying CCFLAGS=-Wno-error or the Windows analogue would achieve the same effect. My suggestion is that we should in fact fix that bug, now, rather than trying to introduce a smart facility that "knows" even more about certain compilers and their options. |
| Comment by Ryan Egesdahl (Inactive) [ 05/Jan/21 ] |
|
acm - For your second point, the -Wall flag should only be in CCFLAGS (which is where we have it now) because CCFLAGS automatically applies to all stages of the compiler, which is what we want error and warning flags to do. To your first point, I don't think we actually need to work so hard to make this happen. I would prefer not to be teaching SCons about any of these flags. I originally imagined this as simply copying the flag name from the appropriate part of the error code into the list of suppressed errors and then constructing the correct arguments accordingly before inserting them into the right place in the compiler command. Clang, GCC, and MSVC should all have the property that the error message tells you what flag to use, and the flags are all fairly regular in their construction. If you get the argument(s) wrong, the compiler is going to be plenty verbose about what you did. I don't think SCons needs to be in the way here, and it's better to be simple where we can be. To your third point - we can simply have another argument with a similar structure that issues a -Wno-XXX (or similar for MSVC) if we really want it. But I am not so sure we should be controlling such things via the compiler command like that. Suppressing an error is one thing, but telling the compiler we're smarter than it is strikes me as the wrong thing to do. I would much rather wait until we actually need that functionality for some reason before we add it. I don't expect it would be complicated if we get error suppression right. |
| Comment by Andrew Morrow (Inactive) [ 05/Jan/21 ] |
|
Some background on this that I'm transferring from I wrote:
And ryan.egesdahl replied:
I'll admit I find the proposed solution (--disable-warnings-as-errors=range-loop-analysis) appealing, but there are a few things that give me pause:
In general, I have a preference for treating flags to the control the compiler as passthroughs from the user to the extent that we can. Users of the build system need to be aware of how to use the command line ability to control C and C++ flags to achieve their aims. So, having thought about it, my preference would be that we repair the issue with where -Wall and -Werror appear on the command line so that overrides provided on the command line work as expected. |