As I said, I'm convinced, I'm fine with removing the old code Barry
On Dec 7, 2018, at 2:47 PM, Jed Brown <[email protected]> wrote:
"Smith, Barry F." <[email protected]> writes:
On Dec 7, 2018, at 2:25 PM, Jed Brown <[email protected]> wrote:
"Smith, Barry F." <[email protected]> writes:
On Dec 7, 2018, at 8:56 AM, Jed Brown <[email protected]> wrote:
"Smith, Barry F." <[email protected]> writes:
A potential drawback is some users also use HDF5 directly in their code and may be using an older version (people are very slow to change).
The HDF5 developers were very deliberate about this. You can still use the old API in your own code while linking to the new library. See H5_USE_16_API.
https://support.hdfgroup.org/HDF5/doc/RM/APICompatMacros.html
This pages is a firehose. Most people who have HDF5 in their code (that someone else probably wrote) will never get through this page to know what to do.
You literally just compile that old code using -DH5_USE_16_API while using new HDF5 libraries and headers.
Where do you put this -DH5_USE_16_API thing? I literally don't have a clue how my build system works. I would rather just stick to the old version since its worked for the last n years. (This is the average user/developer of package/application A)
I get your point, but instructions are simple and we can't stay in the dark ages forever. I think the HDF5 folks did a good job with their API deprecations. We'd be upset if people were going through pains to support petsc-2.2.
./configure CPPFLAGS=-DH5_USE_16_API