Consider undefining new API functions when a user chooses a specific API
- Dominant language
- C
- Stars
- 988
- Forks
- 355
- Avg merge
- 4d 2h
- Merged PRs (30d)
- 12
Description
**Is your feature request related to a problem? Please describe.**
I was compiling an old package that uses some hybrid between HDF5 1.6 and 1.10 ....
they define the API version to be 1.6, but then they go on to use macros that were only defined in 1.10. This made me have to define a few extra "hand crafted" definitions in:
https://github.com/conda-forge/libmed-feedstock/pull/50/files#r1375528698
For example, they would define:
```
-DH5_USE_16_API
```
but go on to use part of the `H5O` API which was defined in 1.8.
**Describe the solution you'd like**
Potentially just undefining the parts of new API to avoid users using this quirt to "mix" API version.
**Describe alternatives you've considered**
Ignoring it. But it makes it difficult for new users to then "trust" these kinds of macros to "freeze" an API version, while recompiling with a newer HDF5 library.
**Additional context**
Was helping somebody over at conda-forge learn about these macros:
https://github.com/conda-forge/hdf5-feedstock/pull/209
and then found that their library was using strange ABIs
https://github.com/conda-forge/libmed-feedstock/pull/50
Contributor guide
Assessment
This issue has not been assessed yet.