Aron Ahmadia <[email protected]> writes: > My instinct is that you should provide a consistent set of > externally-facing symbols for the entire HDF5 library (including shared and > parallel builds), and in situations where the function is not available, > calls to that function should raise an HDF5 not implemented error.
I agree with this, though most "parallel" functions become either very simple or no-ops in the sequential case. I'm in favor of defining the symbols and implementing the serial case when it makes sense. > Jed, how does PETSc handle this? MPI types leak into many PETSc public interfaces, so PETSc uses stubs in the serial case. If MPI could get their act together to define an ABI, we could distribute binaries with weak symbols that would work in parallel if a real MPI became available. The broader issue of different configurations is something that PETSc suffers from in an even more critical way with scalar types. It is a major problem for packaging and binary distribution, but none of the solutions are great. > I don't know how maintainers deal with "light" versions of their > libraries. If the symbols are deprecated but not removed from this version > of HDF5, then the soname version should probably be bumped to reflect > this. Agreed, and this would be a developer option "test that your stack has been upgraded" before the symbols are permanently removed. > That said, I think it's more important that the default/parallel > public APIs to libhdf5.so are identical than that the "light" version > be properly versioned. Yes.
pgpbZ9zy99b1F.pgp
Description: PGP signature
_______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org Twitter: https://twitter.com/hdf5
