Remove CACHE FORCE arguments from CMAKE_CXX_FLAG on colored terminal output

alexcani commented 4 years ago

Summary

By using CACHE STRING "" FORCE on 'set' command this updated CMAKE_CXX_FLAG on any parent directory, thus leaking internal configuration into external projects that may be using cucumber-cpp through add_directory.

Details

An example is -Werror -Wall -Wextra flags set on "Generic Compiler Flags". In a Unix + Ninja + GCC environment those flags would leak into parent directories

Motivation and Context

How Has This Been Tested?

Types of changes

[x] Bug fix (non-breaking change which fixes an issue).
[ ] New feature (non-breaking change which adds functionality).
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected).

Checklist:

[x] It is my own work, its copyright is implicitly assigned to the project and no substantial part of it has been copied from other sources (including Stack Overflow). In rare occasions this is acceptable, like in CMake modules where the original copyright information should be kept.
[x] I'm using the same code standards as the existing code (indentation, spacing, variable naming, ...).
[ ] I've added tests for my code.
[x] I have verified whether my change requires changes to the documentation
[x] My change either requires no documentation change or I've updated the documentation accordingly.
[x] My branch has been rebased to master, keeping only relevant commits.

coveralls commented 4 years ago

Coverage remained the same at 62.47% when pulling c8a35c329da42ac3c6bb92f18cc641fa4fb49e51 on alexcani:fix_cxx_flag_leak into dd424c1a900cb41c5db9d481714eb3471ce195e3 on cucumber:master.

jermus67 commented 3 years ago

@muggenhor, (if you're still reading along and can find some time) can you elaborate on why the CACHE STRING "" FORCE was part of setting the CMAKE_CXX_FLAGS?

I somehow cannot deduce from the the cmake documentation that this bleeds into the external / calling project, but that may be an implicit property of a cached variable (i.e. always being set at the highest level and not for the current directory only).

aslakhellesoy commented 3 years ago

Hi @alexcani,

Thanks for your making your first contribution to Cucumber, and welcome to the Cucumber committers team! You can now push directly to this repo and all other repos under the cucumber organization! 🍾

In return for this generous offer we hope you will:

✅ Continue to use branches and pull requests. When someone on the core team approves a pull request (yours or someone else's), you're welcome to merge it yourself.
💚 Commit to setting a good example by following and upholding our code of conduct in your interactions with other collaborators and users.
💬 Join the community Slack channel to meet the rest of the team and make yourself at home.
ℹ️ Don't feel obliged to help, just do what you can if you have the time and the energy.
🙋 Ask if you need anything. We're looking for feedback about how to make the project more welcoming, so please tell us!

On behalf of the Cucumber core team, Aslak Hellesøy Creator of Cucumber

muggenhor commented 3 years ago

@muggenhor, (if you're still reading along and can find some time) can you elaborate on why the CACHE STRING "" FORCE was part of setting the CMAKE_CXX_FLAGS?

I somehow cannot deduce from the the cmake documentation that this bleeds into the external / calling project, but that may be an implicit property of a cached variable (i.e. always being set at the highest level and not for the current directory only).

Just noticed this message now (ever since our company switched to GitHub I get swamped in GH mails).

Anyway, I'm pretty sure this was a copy paste error on my side because a few other CMake projects that I used at the time injected CMAKE_*_FLAGS via the cache, so this was the only way to affect a change there. That wouldn't have applied here, but it affected my approach to thinking about CMake at the time.

cucumber / cucumber-cpp