I would recommend to try moving towards a static configuration that does not rely on a build system at all, i.e., to have the ability to just compile a set of C files without any need of external software needed for configuration (such as bash or cmake ). That makes it much easier to integrate HDF5 into other software packages with their own build systems.
This would pretty much require some compiler-specific “#ifdef”-battle in a pre-defined, “standard” H5configure.h header file that comes right with the HDF5 distribution instead of one generated dynamically by the build system, may it be autoconf or CMake. With #ifdef’s a lot of cases can already be identified by the compiler, without relying on external software creating a header file.
Particularly, modern C preprocessors offer the __has_include directive:
So probably we can get away with all kind of external checking for the existence of header files or particular OS features. The vision is to be able to just use a set if .c and .h files, drag them into some application-specific built system and compile it.
This would also have the advantage that exactly the same source code directory can be used for different platforms, like compiling a windows and a linux version from the same source directory (provided of course that the built system places binaries in platform-specific directories instead of the source code directory, but that should be done anyway).
Maybe there would be a “minimal” configure for use-defined settings, like the options on the current configure scripts, such as the mentioned H5feature.h . But those options can reside in a minimal user-config.h header file, and possibly just a handful of such defines are actually needed. The benefit is that this one single, platform-independent user-config.h header file would then be valid for all platform-specific compilations from the same source tree, and re-compilation is automatically triggered when this one header file is modified.
Currently such a use case is not possible as the dynamically created, platform-specific configure file is placed in the HDF5 source code directory.
Beside the configure header files, also H5libsettings and H5detect are two components that hinder static configurations. Particularly H5detect is created by a binary that is run during the build process. Here the question is whether we can get away with this mechanism, either by also using #ifdef compiler-specific definitions, or by providing platform-specific pre-configurations for known platforms.
For unknown or too complex platforms, using the current configure / cmake mechanims would still be available. But it would be good to at least trying to go into the direction of a static configuration as much as possible such to cover the most frequently used platforms.