Some Macos build patches

[rhoneyager-tomorrow]

Description

Hi guys. I recently tried to build ioda-converters using spack-stack 2.1 on an arm64 mac laptop. I'm not trying to build one of the heavier environments / this was a test of a more limited package subset. I encountered some errors when building & linking oops and ioda, and here are two potential patches.

The oops change

The oops patch is an easy one. It is backported from JCSDA/oops@f378c46, and this change was made in response to ecmwf/atlas#307.

The underlying bug was never incorporated into a stable JCSDA tag of oops. It only affects the code around spack-stack's 2025-08-27 oops commit.

Users might wonder why using int64_t in oops triggers this compiler-time bug. This is because int64_t is a typedef to a fundamental C++ type, and depending on the platform it may point to either long or long long. It doesn't matter that long and long long are frequently the same size nowadays. They are distinct types.

The ioda change

The initial filter_file command can't find the target file. ioda-import.cmake isn't always installed into lib64/cmake/ioda/, and there is likely a lib vs lib64 platform-specific issue.

The patch file is a bit terse, so here's an explanation of the problematic code in cmake/ioda-import.cmake.in:

# Export ioda YAML validation files directory
if( IS_ABSOLUTE "@CMAKE_INSTALL_DATADIR@")
	set( IODA_YAML_ROOT "@CMAKE_INSTALL_DATADIR@/ioda/yaml" )
else()
	if ( DEFINED _IMPORT_PREFIX )
		# We are in a CMake install tree
		set( IODA_YAML_ROOT "${_IMPORT_PREFIX}/@CMAKE_INSTALL_DATADIR@/ioda/yaml" )
	else()
		# We are in a CMake build tree. Ergo, we can use the variable set in
		# IODA's top-level CMakeLists.txt that points to the YAML root path
		# in the source tree.
		#
		# Note: a small downside of this approach is that a source tree path is hardcoded
		# in the ioda-post-import.cmake file, even if it is never again used. Some
		# tools (like Spack) will complain about this path and may indicate that ioda
		# is a non-relocatable package, even though it is completely relocatable.
		set( IODA_YAML_ROOT "@IODA_YAML_ROOT@" )
	endif()
endif()

IODA_YAML_ROOT is set in ioda's share/CMakeLists.txt file to ${CMAKE_CURRENT_BINARY_DIR}/test/testinput/. If you're in a build mode (i.e. not install mode), ioda-import.cmake should be placed in at the top of the project's build tree, so IODA_YAML_ROOT can always point to ${CMAKE_CURRENT_LIST_DIR}/share/test/testinput/.

I'm redoing my stack, so I haven't tested this in a bundle build and can't recall whether ecbuild is forcing the *-import.cmake files to be placed in CMAKE_BINARY_DIR or PROJECT_BINARY_DIR. That might change the patch slightly, but you should get the gist.

One other issue with scipy (not addressed here)

spack-stack doesn't seem to pin a specific py-scipy version. Someone should review that recipe, as not all patches apply to py-scipy@1.16.0. Some of the files to be patched have moved or no longer exist.

Dependencies

None

Issues addressed

None

Applications affected

None operational. This is mostly for macs.

Systems affected

Macos systems

Testing

• CI: Note whether the automatic tests (GitHub actions tests that run automatically for every commit) pass or not
  • GitHub actions CI tests pass
  • GitHub actions CI tests do not pass (provide explanation)
  • GitHub actions CI tests skipped (provide explanation if necessary)
• New tests added: List and describe any new tests added to GitHub actions
  • ...
• Additional testing: Add information on any additional tests conducted
  • ...

Checklist

• This PR addresses one issue/problem/enhancement or has a very good reason for not doing so.
• These changes have been tested on the affected systems and applications.
• All dependency PRs/issues have been resolved and this PR can be merged.
• All necessary updates to the documentation (spack-stack wiki) will be made when this PR is merged

[climbfuji]

@rhoneyager-tomorrow Thanks for contributing these updates. We will want to test those thoroughly, especially the IODA patch change. I put that in place so that we can run the unit tests in spack as part of the build.

I noticed that your changes are for release/2.1. I suggest redirecting them to develop; the JEDI packages are not a supported feature in release/2.1. Also note that I will be adding new versions for all these packages in the next weeks (one set of interim versions and the versions from the recent JEDI release).

[climbfuji]

The modified IODA logic does not work, because the build directory (not the install directory) ends up in the ioda-converters test path.

At least when running spack install --test=root ioda-converters against this change.

196/197 Test #374: iodaconv_validate_testoutput_viirs_jpss1_oc_l3.nc ................................***Failed    0.03 sec
test 375
        Start 375: iodaconv_validate_testoutput_wmo_raob_double.nc4

375: Test command: /home/dom/work/spack-stack/spst-ryan-oops-ioda/envs/ne-oneapi-2025.3.0-build/install/__spack_path_placeholder__/__spack_path_placeholder__/__spack_path_placeholder__/__spack_path_placeholder__/__spack/intel-oneapi-compilers/2025.3.0/ioda-2.9.0.20250826-n4txycc/bin/ioda-validate.x "--ignore-warn" "--ignore-error" "/home/dom/work/spack-stack/spst-ryan-oops-ioda/envs/ne-oneapi-2025.3.0-build/install/__spack_path_placeholder__/__spack_path_placeholder__/__spack_path_placeholder__/__spack_path_placeholder__/__spack/intel-oneapi-compilers/2025.3.0/ioda-2.9.0.20250826-n4txycc/lib64/cmake/ioda/share/test/testinput//validation/ObsSpace.yaml" "/home/dom/work/spack-stack/spst-ryan-oops-ioda/cache/build_stage/spack-stage-ioda-converters-0.0.1.20250830-3ku2x2766x4svs2hrj3rs2quuudjkhhp/spack-src/test/testoutput/wmo_raob_double.nc4"
375: Working Directory: /home/dom/work/spack-stack/spst-ryan-oops-ioda/cache/build_stage/spack-stage-ioda-converters-0.0.1.20250830-3ku2x2766x4svs2hrj3rs2quuudjkhhp/spack-build-3ku2x27/test
375: Environment variables:
375:  ECKIT_COLOUR_OUTPUT=1
375:  OMP_NUM_THREADS=1
375: Test timeout computed to be: 1500
375: Reading YAML from /home/dom/work/spack-stack/spst-ryan-oops-ioda/envs/ne-oneapi-2025.3.0-build/install/__spack_path_placeholder__/__spack_path_placeholder__/__spack_path_placeholder__/__spack_path_placeholder__/__spack/intel-oneapi-compilers/2025.3.0/ioda-2.9.0.20250826-n4txycc/lib64/cmake/ioda/share/test/testinput/validation/ObsSpace.yaml
375: Exception: Cannot open /home/dom/work/spack-stack/spst-ryan-oops-ioda/envs/ne-oneapi-2025.3.0-build/install/__spack_path_placeholder__/__spack_path_placeholder__/__spack_path_placeholder__/__spack_path_placeholder__/__spack/intel-oneapi-compilers/2025.3.0/ioda-2.9.0.20250826-n4txycc/lib64/cmake/ioda/share/test/testinput/validation/ObsSpace.yaml  (No such file or directory)
375: Cannot open /home/dom/work/spack-stack/spst-ryan-oops-ioda/envs/ne-oneapi-2025.3.0-build/install/__spack_path_placeholder__/__spack_path_placeholder__/__spack_path_placeholder__/__spack_path_placeholder__/__spack/intel-oneapi-compilers/2025.3.0/ioda-2.9.0.20250826-n4txycc/lib64/cmake/ioda/share/test/testinput/validation/ObsSpace.yaml  (No such file or directory)

[rhoneyager-tomorrow]

Huh. Then the comments in the initial ioda-import.cmake file are erroneous, and the We are in a CMake install tree vs build tree check is not working properly. I'll take a deeper look.