#1158: ExternalLibraries/HDF5 should change the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN to "no". ------------------------------------+--------------------------------------- Reporter: knarf | Owner: Type: defect | Status: confirmed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+--------------------------------------- Changes (by hinder):
* status: new => confirmed
Comment:
I'm not sure what caused my link error, but updating macports and installing the C++/Fortran variant of the port fixed the problem. If you ask for C++ and Fortran in your optionlist, but your HDF5 installation doesn't have them, a link error seems reasonable.
I just spoke with David Radice, and he informs me that while the ET does not require the Fortran HDF5 bindings, there are many Cactus users with codes which are not part of the ET which do require these bindings. If we disable them by default, they will have to use customised optionlists, which will likely annoy them, so I don't want to do that. The C++ bindings are not used, to his knowledge, but if we are going to include the fortran ones, we may as well also require the C++ ones.
I think the most correct solution would be for a thorn to declare in its configuration.ccl file not only that it needs HDF5, but also that it needs HDF5 with fortran. i.e. "variants" for configuration dependencies. This is too much work to add, so we should find a compromise.
At the moment, the HDF5 thorn will only automatically use an HDF5 installation that has the libraries needed. However, if the user specifies HDF5_DIR, but that location doesn't have the bindings, the error comes very late, i.e. at link time. So we could add a check in the configuration script that the libraries exist there. This logic is essentially the same as that used in the probing code, so should be refactored into a common function.
In summary, my proposal is that the defaults for HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN remain "yes", but an additional check is added to the HDF5 configure script in the case that HDF5_DIR is set by the user that the required libraries actually exist in that location. I have no immediate plans to do this, as it is a low priority, and only affects "advanced" users who manually set HDF5_DIR, and the resulting error message fairly well reflects the actual problem; the only issue is that it is detected late.