Fix weird edge cases when trying to find_package(Celeritas)
#1586
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was a confluence of a policy overwrite from PTL, CMake policy CMP0102 (where `mark_as_advanced` writes an empty cache variable if a local variable is named), and `find_path` which has some funny logic for pulling from cache/local values (and maybe CMP0126 as well).
This reverts commit 02e4f17.
Test summary 4 219 files 6 521 suites 15m 4s ⏱️ Results for commit 56a3fa1. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
#1573 saw some weird failures against Geant4 11.1 and 11.2 but not 11.0 nor 11.3. The failures occurred in the second invocation of
find_dependency(XercesC)(missingXercesC_INCLUDE_DIR) but went away if we added aREQUIREDargument tofind_package(Celeritas).Ultimately there were several factors at play:
find_dependencycaching suppressed the failing XercesC only whenREQUIREDwas setXercesC_INCLUDE_DIRas non-cache variables, and Geant4 set it as a cache variablemark_as_advancedinFindXercesC.cmaketo write an empty cache variable if a normal variable is setfind_pathcommand to overwrite the normal variable with the empty cache value (on the next call to FindXercesC)cmake_minimum_required(3.8)that reset all the policies to that ancient value. This was fixed in Use CMake version range to support CMake 3.30 and newer jrmadsen/PTL#51 and the fix was merged into Geant4 11.3.I've bypassed the root cause of normal/cache mismatch by propagating the CACHE status to the CeleritasConfig.cmake macro. I also added policy scoping to try to limit the damage the other scripts can do.