Fix(CMake): Resolve MSVC C99 complex check failure on re-configure

[xorespesp]

This is a fix for #6051.
I’ve updated the condition to check whether the fallback types (_FCOMPLEX) were detected in a previous run, ensuring that the safety block executes even if the standard size variable is cached.

---

Important

Fixes MSVC C99 complex type check in ConfigureChecks.cmake by considering fallback types, resolving re-configuration issue #6051.

• Behavior:
  • Fixes MSVC C99 complex type check in ConfigureChecks.cmake by updating condition to check fallback types (_FCOMPLEX, _DCOMPLEX, _LCOMPLEX).
  • Ensures safety block executes if standard size variable is cached.
• Misc:
  • Resolves issue MSVC build fails on CMake re-configure due to cached C99 complex type size (Cache pollution) #6051 related to re-configuration failure.

^{This description was created by for 379aaa7. You can customize this summary. It will automatically update as commits are pushed.}

[hyoklee]

@xorespesp , thank you for the fix!

close #5940

[jhendersonHDF]

Thanks @xorespesp,

probably a bit of a silly question, but have you verified that MSVC builds enable the complex number types after reconfiguration and don't skip/disable them?

[bmribler]

Is it possible to fix by resetting everything back to the original settings? That is, similar to "make distclean" for autotools.

[byrnHDF]

That would be done by deleting the build folder - which is usually the best choice most of the time.

[xorespesp]

While deleting the build folder might be a clean solution when building a library independently, but consider scenarios where HDF5 is consumed via FetchContent in large projects.

Modern IDEs often trigger CMake re-configuration automatically in the background.
If users are forced to wipe the entire build directory every time a project CMake script is modified, it would lead to excessive rebuild times. This significantly degrades the developer experience.

[byrnHDF]

Sorry, not suggesting a "force delete". I don't recall a FetchContent rebuilding something already built, but then I never went looking. My understanding is those Fetched projects should not rebuild without any change to their source. And my understanding is that CMake intention is that those configure cache settings are the intentional function.
Why do you want to force a rebuild, what changed in the main project that would have a bearing on hdf5 being built? The hdf5 configure is inspect system and compiler capabilities, what would be changing in the main project to alter those checks?

[xorespesp]

have you verified that MSVC builds enable the complex number types after reconfiguration and don't skip/disable them?

Yes, I tested this by integrating the patched HDF5 sources into my project using FetchContent_Declare(SOURCE_DIR ...) and triggering a re-configure.

The CMake output confirms that it falls back to the correct MSVC types instead of disabling them. Here is the output log I observed during second run(re-configuration):

...
1> [CMake] -- Checking if complex number support is available
1> [CMake] -- Using MSVC complex number types
...

(Ref)

[byrnHDF]

So regardless of the rebuild discussion, the problem is that the complex check has a unique check on windows?
And the result is that the values or state of configure variables are not cached correctly?

[xorespesp]

the problem is that the complex check has a unique check on windows?

Yes. this issue is specific to the MSVC unique check logic that i mentioned.

and the result is that the values or state of configure variables are not cached correctly?

it's not that the cached values themselves are incorrect, but rather how the script "interprets" their presence during re-configuration.

• When the script sees the cached H5_SIZEOF... variable, it mistakenly assumes standard C99 support was found.
• Consequently, it skips the MSVC unique check logic(safety block) entirely.

This behavior is particularly problematic when using HDF5 via FetchContent. Even if the fetched HDF5 source is unchanged, touching the main project's CMake scripts triggers an automatic re-configuration in the IDE, triggering this issue and causing the build to fail.

[brtnfld]

Must also fix this, should be ${HDF_PREFIX}_SIZEOF__LCOMPLEX

[xorespesp]

Thx, I pushed the update.

[brtnfld]

Should this be removed?

[brtnfld]

and then set cached value based on actual detection

set (H5_HAVE_C99_COMPLEX_NUMBERS 0 CACHE INTERNAL "Using MSVC, no C99 complex" FORCE)

[brtnfld]

Then add (C99 sucess path)
set (H5_HAVE_C99_COMPLEX_NUMBERS 1 CACHE INTERNAL "Using C99 complex" FORCE)

In practice:

First configuration:
Standard types fail -> MSVC types detected
Sets H5_HAVE_C99_COMPLEX_NUMBERS = 0 in cache (FORCE)

Re-configuration:
Variable loads from cache as 0
Never gets set to 1 because optimistic line 896 was removed
Remains 0 (correct)

[xorespesp]

Then add (C99 sucess path)
set (H5_HAVE_C99_COMPLEX_NUMBERS 1 CACHE INTERNAL "Using C99 complex" FORCE)

This part is a bit unclear to me.
If I apply the suggested change, I think the code should be modified like this:

    ...
    if (NOT H5_HAVE_STDC_NO_COMPLEX)
      # Compile simple test program with complex numbers
      HDF_FUNCTION_TEST (HAVE_COMPLEX_NUMBERS)

      if (H5_HAVE_COMPLEX_NUMBERS)
        
+        if (NOT DEFINED H5_HAVE_C99_COMPLEX_NUMBERS)
+          set (H5_HAVE_C99_COMPLEX_NUMBERS 1 CACHE INTERNAL "Using C99 complex" FORCE)
+        endif()

        if (H5_HAVE_C99_COMPLEX_NUMBERS)
          message (STATUS "Using C99 complex number types")
        else ()
          message (STATUS "Using MSVC complex number types")
        endif ()
        ...

Is this what you mean?

[xorespesp]

... Regarding your suggestion, i completely agree. removing the "optimistic initialization" and using cached variables for both the MSVC unique check and the standard success path makes the logic much clearer.

I've updated the code accordingly. could you please take a look?

[jhendersonHDF]

@brtnfld What's the purpose of turning this into a cache variable with set (H5_HAVE_C99_COMPLEX_NUMBERS 1 CACHE INTERNAL "Using C99 complex" FORCE)? The intent was to not pollute the cmake cache with more than is necessary and in this case the variable is only needed to populate values in the features header file used by the library, so there's really no need for it to be a cache variable here. I also find the logic like

if (H5_HAVE_COMPLEX_NUMBERS)
  if (NOT DEFINED H5_HAVE_C99_COMPLEX_NUMBERS)
    set (H5_HAVE_C99_COMPLEX_NUMBERS 1 CACHE INTERNAL "Using C99 complex" FORCE)
  endif ()
endif ()

much more confusing because it's baking in previous assumptions about what the CMake logic did.

[brtnfld]

I'm also okay with not making it a cache variable.

[brtnfld]

@jhendersonHDF The current logic assumes complex type detection is all-or-nothing. Can it be true that on 1 or 2 of the 3 standard types are detected? If so, then the NOT DEFINED hides the complexity

[brtnfld]

LGTM, thanks

[brtnfld]

We can talk about this and get back to you.

[hyoklee]

All tests pass with VS 18 2026:

https://my.cdash.org/viewTest.php?onlypassed&buildid=3220270

[jhendersonHDF]

@xorespesp Could you test my changes over in #6080? I decided that the complex configuration logic needed a bit of an update for clarity anyway while looking at the issue here. The setting of the size macro variables in the "MSVC" block was part of the problem due to using the same name for the C99 type size variables as the final size macro variables. I believe using separate names and some local variables made things a bit easier to read and avoided needing more unnecessary CMake cache variables.