Cool, I will do that. Vaclav
> On 7 Dec 2018, at 23:49, Smith, Barry F. <[email protected]> wrote: > > > 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 >
