-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unused parameter warnings should not cause errors on non-release builds #450
Comments
In my opinion we should be strict but we can provide an override. Would this solve your use case? # Error on all warnings
set(DEFAULT_COMPILE_OPTIONS "-Wall -Wextra -Werror -pedantic" CACHE STRING "Default compile options")
if(NOT CMAKE_BUILD_TYPE STREQUAL "Release")
add_compile_options(${DEFAULT_COMPILE_OPTIONS})
endif() |
Yes, that would work, though I think we should be more strict for CI builds (error on all warnings) and less strict for default builds (warnings are just warnings); that way developers are just notified of warnings, but PRs with warnings aren't allowed to be merged. Why is the default build type |
In my experience, developers get annoyed if their stuff fails in CI when they had ensured that it worked fine locally :-) This selection of defaults (e.g. |
How about a # Error on all warnings
if(NOT CMAKE_BUILD_TYPE STREQUAL "Release")
add_compile_options(-Wall -Wextra -pedantic)
if(NOT CMAKE_BUILD_TYPE STREQUAL "Debug")
add_compile_options(-Werror)
endif()
endif() |
Isn't it exactly in a developer environment that you should want to see all warning that could cause failures later on, e.g. in CI? That's when you are in the mindset and environment where you are most likely to have introduced them and can fix them. I kinda feel that we shouldn't change defaults because of a specific testing/development strategy (disabling part of the code), done by an experienced developer (you) where we have identified a workaround. The defaults should be to 'strongly encourage' developers to fix warnings right from the start. But I'm just one person here and we have a disagreement, so let's maybe see what @veprbl @sly2j think about this (also since it probably is good to be consistent in some of the other code repositories). |
Not setting At first glance, I only see |
My take on
As far as local development goes, it probably falls close enough to apply rule 2. The remaining warnings can be brushed up once PR is submitted. |
Is your feature request related to a problem? Please describe.
Treating all warnings as errors may not be the best approach for productivity. Sometimes I turn on/off certain parts of the code, which often triggers
unused parameter
warnings (treated as errors), which are tedious to resolve.Describe the solution you'd like
Consider mofifying
epic/CMakeLists.txt
Lines 26 to 29 in d14e80b
Should we be less strict for non-release builds?
The text was updated successfully, but these errors were encountered: