Hi,
Currently, the HDF5 thorn within ExternalLibraries provides the C++ interface of the hdf5 library by default. However, nothing within the toolkit makes use of it. The C++ interface is considered deprecated by hdf5 itself. It doesn't work together with parallel hdf5.
Thus, I suggest to not build and look for the C++ interface by default.
The benefit would be that typical system installations (which don't come with the c++ interface) can be used without explicitly specifying flags in the optionlist. Also, parallel hdf5 could be used more easily.
A disadvantage would be of course that it would not be available by default anymore. However, nothing within the Einstein Toolkit actually uses it.
On argument so far had been that the Carpet hdf5 visit reader uses it. However, because of hdf5 version conflicts it is usually better anyway to build the reader against the headers that come with a visit installation. Cactus isn't needed here at all.
The Carpet Visit reader uses the C version instead of C++ of hdf5 by now. I have ported that to C because the VisIt team did not plan to include hdf5-c++ in their release. So in order to get the reader into VisIt, it has to use C.
Christian
Please comment on the corresponding ticket [1] if you have an opinion about this, e.g. if you use the C++ interface. If nobody speaks up the C++ interface will be dropped (by default) in about two weeks. It would still be possible to specify HDF5_ENABLE_CXX=yes in an optionlist to make sure it is present.
Frank Loeffler