On Wed, Mar 16, 2011 at 3:08 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 16 Mar 2011, at 19:51, Frank Loeffler wrote:
Hi,
On Wed, Mar 16, 2011 at 05:27:57PM +0100, Ian Hinder wrote:
What is the reason for requiring the Fortran and C++ bindings to be present in everyones' HDF5 library?
They are not required for everyone. I only changed the option list I use for my laptop (and others also might use for Debian systems) to build the HDF5 library within Cactus. You are free to use another option list, but without this the Einstein Toolkit will not build, as it (still) depends on the Fortran interface of HDF5.
I'm not talking about your commit - it was only your commit which reminded me of the issue. I'm talking about Erik's commit to ExternalLibraries/HDF5 from a while back:
r17 | eschnett | 2010-09-11 01:18:38 +0200 (Sat, 11 Sep 2010) | 4 lines Enable C++ and Fortran support. Do not enable Fortran support if there is no Fortran 90 compiler available.
This commit not only enables C++ and Fortran support, it makes it mandatory in any HDF5 installation used. I am arguing that since it is not needed by all people, it shouldn't be made mandatory.
The HDF5 library is one of the easiest and most robust libraries to build. Newer versions (1.8.5, 1.8.6) have performance improvements, in particular for HPC systems and Lustre file systems. The HDF5 libraries available by default are usually older versions lacking these improvements. I don't know how much these improvements are worth in practice, but I know the people involved in implementing many of them, and (quite unfortunately) before this recent push (that started with 1.8.3 or so), the HDF5 group was not able to invest much manpower into HPC performance. I therefore assume that it makes currently sense to build HDF5 ourselves (either with Cactus or manually) on our production systems.
C++ support in HDF5 is not maintained, and we should move away from it. Fortran support is available on most systems because many people use it (which probably doesn't help you in your particular case).
-erik