Also nuke the old value out of the cache if it's there, otherwise
it could lead to problems when the project increases the standard
and the developer just runs the "make/ninja" program.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Wow, that was quick, thanks!
I played with it a bit locally and it seems to solve this problem. I have one comment about the fatal error, but otherwise LGTM.
llvm/CMakeLists.txt | ||
---|---|---|
71 | I tried to give it an explicit -DCMAKE_CXX_STANDARD=14 and it will warn and reset it to 17, but not error. It's an improvement over silently using 14 which we do now, but even with the warning it might be slightly surprising? Personally I think you can just get rid of this check. |
I myself stumbled upon this caching behavior, and although I knew that the minimum required standard has changed, it was surprising to notice that the project is still being built with -std=c++14.
Nevertheless, I don't find this change necessary. The minimum requirement does not change often (is this the second time?).
People will eventually clear the cache, as they once did. Active developers are already aware of the change and it will not take long for them to realize what is the cause of the issue.
I don't have strong objections, only that this slightly complicates already complex build system, and only needed once in a decade.
llvm/CMakeLists.txt | ||
---|---|---|
68 | This resets the cache variable in the main project, but what about subprojects? Will they also be affected? |
I agree with a lot of this. Maybe the right thing is to just check if CMAKE_CXX_STANDARD is lower than the required and skip the whole cache check. Since this is a user-configurable setting it would be good to make sure we don't hand the user a foot-gun.
llvm/CMakeLists.txt | ||
---|---|---|
68 | It should be reset for every other subproject that's included with ENABLE_PROJECTS - but with runtimes I am not sure what makes it re-gen the cache there which will be needed. |
After a bit of thinking - I think we should merge this as it is now and we can always revert it later in a few weeks if we want - but for now it would self-heal a lot of local setups and bots.
This resets the cache variable in the main project, but what about subprojects? Will they also be affected?