mirror of
https://github.com/HDFGroup/hdf5.git
synced 2026-09-25 04:09:44 +03:00
Scot Breitenfeld
e4c16e9fca
All #cmakedefine01 CMAKE_H5_* blocks used a five-line pattern: #cmakedefine01 CMAKE_H5_HAVE_FOO #if CMAKE_H5_HAVE_FOO == 0 #undef H5_HAVE_FOO #else #define H5_HAVE_FOO #endif This is exactly what #cmakedefine H5_HAVE_FOO does: it emits #define H5_HAVE_FOO (no value) when the CMake variable is truthy and /* #undef H5_HAVE_FOO */ when falsy. The CMAKE_H5_* intermediate variables in fortran/src/CMakeLists.txt were only needed to feed these blocks and are no longer required. Replace all such blocks with #cmakedefine H5_HAVE_FOO, using the H5_* variable directly. MPI_LOGICAL_KIND retains its value via #cmakedefine H5_MPI_LOGICAL_KIND @H5_MPI_LOGICAL_KIND@. This also fixes a real bug: H5_FORTRAN_C_BOOL_IS_UNIQUE was emitted as #define H5_FORTRAN_C_BOOL_IS_UNIQUE 0 when C_BOOL and default LOGICAL are the same kind (e.g. Apple PowerPC ABI). #ifdef only tests whether a macro is defined, not its value, so the guard in H5_test_buildiface.F90 was always true and verify_c_bool was written into tf_gen.F90 regardless, causing an "Ambiguous interfaces" build failure on that platform.