Skip to content
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

Open
c-dilks opened this issue Jun 20, 2023 · 7 comments
Open

Comments

@c-dilks
Copy link
Member

c-dilks commented Jun 20, 2023

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

# Error on all warnings
if(NOT CMAKE_BUILD_TYPE STREQUAL "Release")
add_compile_options(-Wall -Wextra -Werror -pedantic)
endif()

Should we be less strict for non-release builds?

@wdconinc
Copy link
Contributor

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() 

@c-dilks
Copy link
Member Author

c-dilks commented Jun 22, 2023

Yes, that would work, though -DCMAKE_BUILD_TYPE=Release also solves my use case without any changes.

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 RelWithDebInfo more strict than Release?

@wdconinc
Copy link
Contributor

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. RelWithDebInfo) was to support developers as they develop and have a need to debug. Do you want to change the default to Release and then only run with something lower in CI?

@c-dilks
Copy link
Member Author

c-dilks commented Jun 22, 2023

How about a Debug build type, which just keeps -Werror off?

# 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()

@wdconinc
Copy link
Contributor

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).

@c-dilks
Copy link
Member Author

c-dilks commented Jun 22, 2023

Not setting -Werror means all warnings will still appear, they just won't be converted to errors; that is all the above proposed non-default Debug build type would do.

At first glance, I only see -Werror used for epic and juggler, so we're the odd ones out here. But there are some cases where -Werror is applied for CI jobs, e.g., ACTS.

@veprbl
Copy link
Member

veprbl commented Jun 22, 2023

My take on -Werror is:

  1. It should always be enabled on CI
  2. It doesn't make sense to push it onto the end users who may have a different version of a compiler that was not tested

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants