CMake: keep derived AMReX options in sync on re-configure

[ax3l]

Several AMReX options that WarpX derives from its own options were only assigned in their "on" branch, or through a non-forcing set(... CACHE BOOL "") that is a no-op once the cache entry exists, so re-configuring an existing build directory silently kept the old value. Most visibly, switching CMAKE_BUILD_TYPE from Debug to Release left AMReX_ASSERTIONS and AMReX_FPE on, so a "Release" build still paid for assertions and floating-point exception trapping.

• rebase after Dependencies: AMReX CUDA CMake 3.25+ #7202

Details

Option	Derived from	Stale symptom
AMReX_ASSERTIONS, AMReX_FPE	CMAKE_BUILD_TYPE	Debug → Release keeps assertions and FPE trapping on
AMReX_BUILD_SHARED_LIBS	WarpX_PYTHON, WarpX_LIB	ON → OFF keeps AMReX a shared library
AMReX_ASCENT, AMReX_CATALYST, AMReX_CONDUIT	WarpX_ASCENT, WarpX_CATALYST	on-only assignment
AMReX_SENSEI	WarpX_SENSEI	on-only assignment

The options fall into two groups, handled differently.

Purely derived values — AMReX_ASCENT, AMReX_CATALYST, AMReX_CONDUIT, AMReX_SENSEI — are assigned unconditionally from their WarpX counterpart. These stay CACHE INTERNAL, which already implies FORCE, so the fix for them is a second assignment rather than an added FORCE.

Caller-facing options — AMReX_ASSERTIONS, AMReX_FPE, AMReX_PIC, AMReX_BUILD_SHARED_LIBS — are set as normal variables instead of cache entries. With CMP0077 NEW, which we already request here, AMReX's option() honors a normal variable and skips creating the cache entry, so the derivation re-evaluates on every configure and leaves nothing behind for the next one. AMReX_ASSERTIONS and AMReX_FPE are guarded by if(NOT DEFINED ...), so an explicit -DAMReX_ASSERTIONS=ON is a cache entry that keeps winning; AMReX_PIC and AMReX_BUILD_SHARED_LIBS apply unconditionally, since a Python build genuinely requires them.

AMReX_INSTALL keeps working: it is derived from if(DEFINED AMReX_BUILD_SHARED_LIBS), and DEFINED is true for a normal variable, so a Python configure still gets AMReX_INSTALL=ON and downstream install(EXPORT ...) is generated. This is what ImpactX's Python bindings need when they add WarpX/ABLASTR as a subdirectory.

Internal: drops a duplicated AMReX_PIC assignment whose condition is a strict subset of the preceding one. AMReX_PIC itself was not observably stale, since ABLASTR_POSITION_INDEPENDENT_CODE defaults to ON and keeps the condition true.

Two consequences worth knowing. A build directory configured by an earlier version still carries its old cache entries and is not healed by this change — one --fresh clears it permanently. And these options no longer appear in ccmake/cmake-gui as tweakable knobs in the common case, though -D still works and now sticks across re-configures.

Testing

Configured, then re-configured the same directory with the opposite settings, and compared each result against a fresh configure of the same command line. Probed the effective values plus the resulting amrex_3d target TYPE and POSITION_INDEPENDENT_CODE, since the fix intentionally keeps these values out of the cache.

Scenario	AMReX_ASSERTIONS	AMReX_FPE	amrex_3d
fresh Release + WarpX_PYTHON=OFF	OFF	OFF	STATIC, PIC ON
Debug+ON → re-configure Release+OFF	OFF	OFF	STATIC, PIC ON
fresh Debug + WarpX_PYTHON=ON	ON	ON	SHARED, PIC ON
Release+OFF → re-configure Debug+ON	ON	ON	SHARED, PIC ON

Both directions match their fresh reference. A caller's -DAMReX_ASSERTIONS=ON in a Release build also survives a later re-configure.

Also checked the ImpactX superbuild against this branch, since ImpactX sets these options before adding WarpX/ABLASTR as a subdirectory: ImpactX_PYTHON=ON gives AMReX shared and position-independent with AMReX_INSTALL=ON and no install(EXPORT "pyAMReXTargets" ...) error, and its ON → OFF re-configure matches a fresh OFF configure.

Same class of issue as AMReX_GPU_RDC/AMReX_CUDA_LTO/AMReX_IPO in #7202, and mirrored on the ImpactX side in BLAST-ImpactX/impactx#1637.