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

Enable compiler warnings. #1792

Closed
wants to merge 1 commit into from
Closed

Conversation

binary1248
Copy link
Member

Title says it all.

Currently not expected to build since the enabled warnings are stricter than the current requirements on the code.

@eXpl0it3r
Copy link
Member

Should we provide separate PR into master and then rebase this PR or how did you imagine to go about solving the produced errors?

@binary1248
Copy link
Member Author

Someone more daring than me should pick a method. 😁

@eXpl0it3r
Copy link
Member

Why might want to update the minimum required version to at least 3.15 or work around this bug: https://gitlab.kitware.com/cmake/cmake/-/issues/18317

Otherwise we'll get a lot of complaints about this warning. 😅

@binary1248
Copy link
Member Author

Why might want to update the minimum required version to at least 3.15 or work around this bug: https://gitlab.kitware.com/cmake/cmake/-/issues/18317

Otherwise we'll get a lot of complaints about this warning. 😅

Should be fixed with the CMAKE_USER_MAKE_RULES_OVERRIDE in the current changeset.

@eXpl0it3r
Copy link
Member

I think it makes the most sense if people would make PRs onto this branch, otherwise they don't actually see whether they've fixed all the issues.
Team members can also directly push to the branch.

@binary1248
Copy link
Member Author

Pushed changeset without /permissive-.

@binary1248
Copy link
Member Author

Added -Wimplicit-fallthrough.

endif()

foreach(WARNING ${FILE_WARNINGS})
set_property(SOURCE ${ARGV} APPEND_STRING PROPERTY COMPILE_FLAGS " ${WARNING}")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could use set_source_files_properties here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

set_property lets us append to the existing property value in a single line.

# https://github.com/lefticus/cppbestpractices/blob/master/02-Use_the_Tools_Available.md

# Helper function to enable compiler warnings for a specific set of files
function(set_file_warnings)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a reason we set the options on a set of files rather than on the targets?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can select precisely for which files we want to enable our strict warnings (which are treated as errors and cause building to fail). There might be cases where we choose to compile some third party source as part of a target and don't want to enable our warnings for upstream code.

@binary1248
Copy link
Member Author

Removed -Wimplicit-fallthrough.

@eXpl0it3r eXpl0it3r added this to Discussion in SFML 2.6.0 via automation Nov 30, 2021
@eXpl0it3r eXpl0it3r added this to the 2.6 milestone Nov 30, 2021
@eXpl0it3r eXpl0it3r moved this from Discussion to Ready in SFML 2.6.0 Nov 30, 2021
@eXpl0it3r
Copy link
Member

Superseded, integrated and merged in #1846

@eXpl0it3r eXpl0it3r closed this Nov 30, 2021
SFML 2.6.0 automation moved this from Ready to Done Nov 30, 2021
@eXpl0it3r eXpl0it3r deleted the feature/compiler_warnings branch November 30, 2021 10:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
SFML 2.6.0
  
Done
Development

Successfully merging this pull request may close these issues.

None yet

4 participants