Fix the CI build tests

[DavidHuber-NOAA]

Build tests are not currently possible because GSI-utils makes use of both the real4 and real8 ip modules, but in different executables. Thus, both ip_4 and ip_d have to be installed. However, when spack installs into the GitHub runner, it does so in common include_4 and include_d spaces. When compiling, -I flags are passed to the compiler for both locations, meaning both the ip_4 and ip_8 modules are available for the compiler to choose from. For some executables, this means that the wrong ip module is being referenced, causing type mismatches.

[DavidHuber-NOAA]

@AlexanderRichert-NOAA would you be able to help with this?

FYI @RussTreadon-NOAA @aerorahul

[AlexanderRichert-NOAA]

Yes-- Can you give an example of a file/target in GSI-utils where it needs one version or the other? Then I can poke around a bit. I suspect the solution will be to refine which CMake targets/files get which ip-related flags.

I forget, are you getting build errors for the type mismatches? Hopefully that's the case as opposed to it quietly using the wrong routines...

[DavidHuber-NOAA]

Yeah, one such problematic target is getsfcnstensupdp which requests both the ip_d and bacio_4 libraries:

GSI-utils/src/EnKF/gfs/src/getsfcnstensupdp.fd/CMakeLists.txt

Lines 15 to 23 in 7b7fb72

	add_executable(getsfcnstensupdp.x ${SRCS})
	target_compile_definitions(getsfcnstensupdp.x PRIVATE "_REAL8_")
	target_link_libraries(getsfcnstensupdp.x PRIVATE NetCDF::NetCDF_Fortran)
	target_link_libraries(getsfcnstensupdp.x PRIVATE MPI::MPI_Fortran)
	target_link_libraries(getsfcnstensupdp.x PRIVATE bacio::bacio_4)
	target_link_libraries(getsfcnstensupdp.x PRIVATE w3emc::w3emc_d)
	target_link_libraries(getsfcnstensupdp.x PRIVATE nemsio::nemsio)
	target_link_libraries(getsfcnstensupdp.x PRIVATE sfcio::sfcio)
	target_link_libraries(getsfcnstensupdp.x PRIVATE ip::ip_d)

Here is an example build failure: https://github.com/NOAA-EMC/GSI-utils/actions/runs/16205341115/job/45755933045#step:5:542

[AlexanderRichert-NOAA]

I can confirm that the problem here is that when, say, bacio_4 and ip_d are used, then this will lead to -I/path/to/include_4 -I/path/to/include_d being used, which will cause /path/to/include_4/ip_mod.mod to be used, which is not correct.

We don't usually run into this because we mostly install and access packages modularly rather than in a common bin/ lib/ include/ directory structure.

The possible solutions I can identify are:

• Don't use environment views in the CI; install/access the packages modularly (happy to help with this)
• We could create library-specific include directories: include/{ip,bacio}/{d,4,8}/, include/{ip,bacio}_{d,4,8}/, or include_{ip,bacio}_{d,4,8}/ (I think the first is the cleanest). We could make this change in the CMake, and patch prior versions through Spack. There would be no drawback to also using this directory structure when doing modular installations.
• We could look into deeper structural changes to these libraries so that the different build versions aren't needed (e.g., use Fortran interfaces containing procedures with the various combinations of data types), but this is not currently planned and in any case would not happen soon.