cmake: forward TA_ASSERT_POLICY to BTAS built from source

[evaleev]

Problem

TA_ASSERT_POLICY was not forwarded to BTAS when BTAS is built from source, so BTAS fell back to its own default (throwing BTAS_ASSERT whenever BUILD_TESTING=ON, regardless of NDEBUG). Since BUILD_TESTING is ON in a normal TA developer configure, BTAS_ASSERT threw even where TA_ASSERT aborts or is a no-op, e.g. a Release build with TA_ASSERT_IGNORE still got throwing BTAS asserts.

Change

• BTAS now has the same three assertion modes as TA: BTAS_ASSERT_POLICY = BTAS_ASSERT_{THROW,ABORT,IGNORE}, none affected by NDEBUG (BTAS_ASSERT_POLICY: real THROW / ABORT / IGNORE modes BTAS#188, merged as 52aadfe54). The BTAS tag is bumped to that commit (own commit, per the dependency-pin rule).
• cmake/modules/FindOrFetchBTAS.cmake, on the from-source path only, derives BTAS_ASSERT_POLICY from TA_ASSERT_POLICY 1:1:

TA_ASSERT_POLICY	BTAS_ASSERT_POLICY
TA_ASSERT_THROW	BTAS_ASSERT_THROW
TA_ASSERT_ABORT	BTAS_ASSERT_ABORT
TA_ASSERT_IGNORE	BTAS_ASSERT_IGNORE

• TA_BTAS_ASSERT_POLICY_FOLLOWS_TA (default ON) is the opt-out. While ON, BTAS_ASSERT_POLICY is re-derived on every configure, so changing TA_ASSERT_POLICY keeps BTAS in sync. An explicit BTAS_ASSERT_POLICY that differs from the value TA last acknowledged (INTERNAL cache entry TA_BTAS_ASSERT_POLICY_SEEN) is honored and turns the option OFF; turning it back ON resumes following. CMake cannot distinguish an explicit -DBTAS_ASSERT_POLICY=<X> from a cache entry already holding <X>, so pinning BTAS to a value TA derived earlier requires -DTA_BTAS_ASSERT_POLICY_FOLLOWS_TA=OFF as well; INSTALL.md says so.
• INSTALL.md's TA_ASSERT_POLICY entry documents the forwarding and the override variable.

History: the first commit (091de97) forwarded the deprecated boolean BTAS_ASSERT_THROWS because BTAS had no abort mode at the time; the later commits switch to the three-mode policy once BTAS#188 landed.

Verification

Configure-only (nothing built): cmake -S <tree> -B <scratch> -G Ninja -DTA_PYTHON=OFF -DCMAKE_BUILD_TYPE=RelWithDebInfo with MADNESS/BTAS supplied via FETCHCONTENT_SOURCE_DIR_{MADNESS,BTAS} (BTAS at 52aadfe54), reconfiguring the same scratch tree in sequence and reading TA_ASSERT_POLICY, BTAS_ASSERT_POLICY, TA_BTAS_ASSERT_POLICY_FOLLOWS_TA from CMakeCache.txt (prefixes dropped below).

Tree A:

step	extra -D	TA	BTAS	FOLLOWS	check
1	—	THROW	THROW	ON	default derived
2	TA_ASSERT_POLICY=TA_ASSERT_ABORT	ABORT	ABORT	ON	re-derived on reconfigure
3	TA_ASSERT_POLICY=TA_ASSERT_IGNORE BTAS_ASSERT_POLICY=BTAS_ASSERT_THROW	IGNORE	THROW	OFF	explicit value honored, following stops
4	TA_ASSERT_POLICY=TA_ASSERT_THROW	THROW	THROW	OFF	user value kept
5	TA_ASSERT_POLICY=TA_ASSERT_ABORT TA_BTAS_ASSERT_POLICY_FOLLOWS_TA=ON	ABORT	ABORT	ON	following resumed
6	TA_ASSERT_POLICY=TA_ASSERT_IGNORE	IGNORE	IGNORE	ON	still following

Tree B (fresh):

step	extra -D	TA	BTAS	FOLLOWS	check
1	BTAS_ASSERT_POLICY=BTAS_ASSERT_ABORT (first configure)	THROW	ABORT	OFF	explicit value on first configure honored
(fresh) 2	—	THROW	THROW	ON	default derived
3	TA_ASSERT_POLICY=TA_ASSERT_ABORT BTAS_ASSERT_POLICY=BTAS_ASSERT_THROW	ABORT	ABORT	ON	the ambiguous case (explicit value equals the cached one): indistinguishable, re-derived, as documented
4	same plus TA_BTAS_ASSERT_POLICY_FOLLOWS_TA=OFF	ABORT	THROW	OFF	the documented opt-out pins it

Tree C (fresh; first configure opts out without an explicit value):

step	extra -D	TA	BTAS	FOLLOWS	check
1	TA_BTAS_ASSERT_POLICY_FOLLOWS_TA=OFF	THROW	THROW (BTAS's default)	OFF	not following; BTAS's default acknowledged
2	TA_ASSERT_POLICY=TA_ASSERT_ABORT TA_BTAS_ASSERT_POLICY_FOLLOWS_TA=ON	ABORT	ABORT	ON	opt-in resumes following
3	TA_ASSERT_POLICY=TA_ASSERT_IGNORE	IGNORE	IGNORE	ON	still following

The acknowledged value (TA_BTAS_ASSERT_POLICY_SEEN) was read back at every step and always equals the BTAS column.

Notes

• Companion PR on the SeQuant side (forwards SEQUANT_ASSERT_BEHAVIOR to TA_ASSERT_POLICY and BTAS_ASSERT_POLICY): cmake: forward SEQUANT_ASSERT_BEHAVIOR to TiledArray and BTAS built from source SeQuant#616. It becomes fully effective for BTAS once SeQuant's TA pin moves past this PR.

[evaleev]

BTAS now has BTAS_ASSERT_POLICY (ValeevGroup/BTAS#188, merged as 52aadfe54): daedd95 bumps the BTAS tag and b4dafc8 forwards TA_ASSERT_POLICY as BTAS_ASSERT_POLICY (all three modes map 1:1) instead of the deprecated boolean BTAS_ASSERT_THROWS.

[Copilot]

🟡 Changes recommended

The BTAS policy implementation/documentation mismatch and stale cache behavior must be corrected before approval.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Updates TA’s from-source BTAS integration to forward assertion policies, refreshes the BTAS revision, and documents the configuration.

Changes:

• Updates the BTAS source revision.
• Adds assertion-policy forwarding.
• Documents the forwarding behavior.

File summaries

File	Summary and findings
INSTALL.md	Documents forwarding behavior. Nit (1 vote): correct the variable and policy mapping documentation.
external/versions.cmake	Updates the BTAS source revision.
cmake/modules/FindOrFetchBTAS.cmake	Adds policy forwarding. Critical (2 votes): implementation and pin use BTAS_ASSERT_POLICY rather than the documented BTAS_ASSERT_THROWS behavior. Moderate (1 vote): cached derived values can remain stale after policy changes.

Review details

Suppressed comments (3)

INSTALL.md:427

• The documentation repeats the wrong variable and claims BTAS has the same three policy modes. BTAS consumes BTAS_ASSERT_THROWS (a boolean); document the TA_ASSERT_THROW → ON and the other modes → OFF mapping and the correct override variable.

* `TA_ASSERT_POLICY` -- Set to `TA_ASSERT_IGNORE` to disable `TA_ASSERT` assertions, `TA_ASSERT_THROW` to cause `TA_ASSERT` assertions to throw, `TA_ASSERT_ABORT` to cause `TA_ASSERT` assertions to abort. The default is `TA_ASSERT_IGNORE` if CMake uses a single-configuration generator and`CMAKE_BUILD_TYPE` is set to `Release` or `MinSizeRel`, else the default is `TA_ASSERT_THROW`. This is also forwarded to BTAS, as `BTAS_ASSERT_POLICY` (`TA_ASSERT_THROW`/`TA_ASSERT_ABORT`/`TA_ASSERT_IGNORE` map onto `BTAS_ASSERT_THROW`/`BTAS_ASSERT_ABORT`/`BTAS_ASSERT_IGNORE`), when BTAS is built from source; set `BTAS_ASSERT_POLICY` explicitly to override.

cmake/modules/FindOrFetchBTAS.cmake:41

• These assignments create a persistent BTAS_ASSERT_POLICY cache entry, so after the first configure this NOT DEFINED guard is false. Reconfiguring the same build tree with a different TA_ASSERT_POLICY therefore leaves BTAS at the old derived policy unless the BTAS cache entry is manually removed or overridden. Please track whether the cache value was auto-derived, or otherwise refresh only non-user values, so changing TA's policy keeps both dependencies synchronized.

  if (NOT DEFINED BTAS_ASSERT_POLICY)
    if (TA_ASSERT_POLICY STREQUAL TA_ASSERT_THROW)
      set(BTAS_ASSERT_POLICY BTAS_ASSERT_THROW CACHE STRING "Controls the behavior of BTAS_ASSERT")
    elseif (TA_ASSERT_POLICY STREQUAL TA_ASSERT_ABORT)
      set(BTAS_ASSERT_POLICY BTAS_ASSERT_ABORT CACHE STRING "Controls the behavior of BTAS_ASSERT")

cmake/modules/FindOrFetchBTAS.cmake:35

• This configures BTAS_ASSERT_POLICY, but the fetched BTAS CMake option is BTAS_ASSERT_THROWS; the new cache variable is therefore ignored and BTAS will continue selecting its behavior from BUILD_TESTING. Set BTAS_ASSERT_THROWS instead, enabling it only for TA_ASSERT_THROW and disabling it for the other two TA modes.

  # forward TA's assertion policy to BTAS, else BTAS picks its own default
  # (BTAS_ASSERT_THROW whenever BUILD_TESTING=ON, no matter what TA_ASSERT does).
  # BTAS_ASSERT_POLICY has the same three modes as TA_ASSERT_POLICY, and
  # like it is not affected by NDEBUG.
  # N.B. only if the user did not ask for a specific BTAS_ASSERT_POLICY, hence a

• Files reviewed: 3/3 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟡 Changes recommended

Explicit BTAS overrides must remain authoritative across reconfiguration.

Get a fresh assessment by requesting another Copilot review.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

Cache-marker persistence and first-configure opt-out handling have unresolved issues.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (1)

cmake/modules/FindOrFetchBTAS.cmake:61

• If TA_BTAS_ASSERT_POLICY_FOLLOWS_TA=OFF is used on the first configure without also setting BTAS_ASSERT_POLICY, this block runs before FetchContent_MakeAvailable(BTAS) and therefore records no SEEN value; BTAS creates its default policy only afterward. On the next configure, turning FOLLOWS_TA back ON sees that cached default with no marker and immediately turns the option OFF again, so the documented opt-in cannot resume. Record the BTAS value after the source project has initialized its default (while retaining the prior marker for the pre-fetch comparison).

  if (DEFINED BTAS_ASSERT_POLICY)
    # the value TA acknowledged (derived, or explicit); turning the option back ON with this value still in the cache resumes following
    set(TA_BTAS_ASSERT_POLICY_SEEN ${BTAS_ASSERT_POLICY} CACHE INTERNAL "BTAS_ASSERT_POLICY last acknowledged by TiledArray")

• Files reviewed: 3/3 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🟢 Approval recommended

All reviewed changes are covered with no unresolved blocking issues.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 0 new
• Review effort level: Lite