cmake: seed BTAS_ASSERT_POLICY once from TA_ASSERT_POLICY - #588
Merged
Merged
Conversation
…ached option Replace the TA_BTAS_ASSERT_POLICY_FOLLOWS_TA option and the TA_BTAS_ASSERT_POLICY_SEEN marker (#587) with the plain CMake idiom: if BTAS_ASSERT_POLICY is not in the cache yet, seed it from TA_ASSERT_POLICY, without FORCE. The first configure of a build directory aligns BTAS with TA, an explicit -DBTAS_ASSERT_POLICY (from the user or a parent project) is already in the cache and wins, and a later change of TA_ASSERT_POLICY does not re-seed it (set BTAS_ASSERT_POLICY explicitly, or use a fresh build directory), which is how every cached option behaves. CMake cannot distinguish an explicit -D from a stale cache entry, so the removed machinery could only approximate that, with a corner case per approximation.
There was a problem hiding this comment.
🟢 Approval recommended
The changes are fully reviewed and have no unresolved blocking issues.
Pull request overview
Updates BTAS assertion-policy forwarding to seed BTAS_ASSERT_POLICY once from TA_ASSERT_POLICY, while preserving explicit overrides.
Changes:
- Removes follow/seen tracking variables.
- Documents cache and reconfiguration behavior.
File summaries
| File | Summary |
|---|---|
INSTALL.md |
Documents BTAS assertion-policy cache semantics. |
cmake/modules/FindOrFetchBTAS.cmake |
Implements one-time policy seeding. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This file contains hidden or 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
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.
Follow-up to #587. The forwarding of
TA_ASSERT_POLICYto a BTAS built from source is reduced to the plain CMake idiom for a cached option: ifBTAS_ASSERT_POLICYis not in the cache yet, seed it fromTA_ASSERT_POLICY(THROW/ABORT/IGNOREmap one-to-one), withoutFORCE. TheTA_BTAS_ASSERT_POLICY_FOLLOWS_TAoption and theTA_BTAS_ASSERT_POLICY_SEENmarker from #587 are removed.Rationale: CMake cannot distinguish an explicit
-DBTAS_ASSERT_POLICY=Xfrom a cache entry that already holdsX, so any scheme that re-derives on reconfigure while honoring explicit overrides can only approximate that, and each approximation in #587 had a corner case. Seeding once is exactly how every cached option behaves: the first configure of a build directory aligns BTAS with TA, an explicit-D(from the user or a parent project) wins, and a later change ofTA_ASSERT_POLICYdoes not re-seed (setBTAS_ASSERT_POLICYexplicitly, or use a fresh build directory).INSTALL.mdsays so.Verification (configure-only, BTAS
52aadfe54from source, RelWithDebInfo unless noted):-DTA_ASSERT_POLICYBTAS_ASSERT_POLICYTA_ASSERT_POLICY=TA_ASSERT_IGNOREBTAS_ASSERT_POLICY=BTAS_ASSERT_IGNORETA_ASSERT_POLICY=TA_ASSERT_ABORTBTAS_ASSERT_POLICY=BTAS_ASSERT_ABORTCMAKE_BUILD_TYPE=Release BUILD_TESTING=OFFNo
FOLLOWS_TA/_SEENentries remain in any cache. Companion: ValeevGroup/SeQuant#616 uses the same idiom forTA_ASSERT_POLICYandBTAS_ASSERT_POLICY.