CMake: Always Register Export Set

[ax3l]

Summary

Always register AMReX targets in CMake install export set. Before, they were only set with AMReX_INSTALL, which causes errors in superbuilds (e.g., pyAMReX, WarpX, ImpactX) w/ static libs.

Additional background

Seen with ImpactX build with -DAMReX_BUILD_SHARED_LIBS=OFF.

Checklist

The proposed changes:

• fix a bug or incorrect behavior in AMReX
• add new capabilities to AMReX
• changes answers in the test suite to more than roundoff level
• are likely to significantly affect the results of downstream AMReX users
• include documentation in the code and/or rst files, if appropriate

[WeiqunZhang]

Codex:

Findings

• Tools/CMake/AMReXInstallHelpers.cmake:39 – Moving the whole install(TARGETS … EXPORT AMReXTargets …) block outside if(AMReX_INSTALL) means the libraries, headers, and runtime files are now installed even when the documented AMReX_INSTALL=OFF option is supplied. That option is advertised as “Generate Install Targets = YES/NO” (Docs/sphinx_documentation/source/BuildingAMReX.rst:545) and was explicitly respected by CMake: Fix export with AMReX_INSTALL=OFF #2838. After this change, projects that vendor AMReX and intentionally disable its install rules (so their own top-level cmake --install doesn’t pull in AMReX artifacts) can no longer do so; AMReX’s install() rules will run regardless and drop files into ${CMAKE_INSTALL_PREFIX}/lib, ${PREFIX}/include, etc., which is a regression. Could we keep the registration (install(TARGETS … EXPORT …)) conditional or provide a separate toggle so AMReX_INSTALL=OFF still means “don’t emit install rules”? Right now the flag effectively does nothing for the core libraries.

Context

• Patch only needs the export-set registration to happen unconditionally so superbuilds can reference AMReXTargets. Installing the targets and CMake package files themselves can still stay behind AMReX_INSTALL, otherwise users lose the ability to opt out of installing AMReX when embedding it inside another project.

[ax3l]

Yeah for some reason it did not work if moved only one of those... I remember tweaking around this before...

Can check again next week, not super urgent but part of my investigation to why AMReX as static lib does not work for our Python layer.