Ward
<
Currently, using find_package(HDF5 NO_MODULE) results in Visual Studio
attempting to link against the shared libraries (.dll) themselves, instead of
the associated import libraries (.lib). I'm still trying to figure out why
this is, exactly, but in the mean time I am using the work-around mentioned in
your previous email.
>
Using find_package(HDF5 NO_MODULE) does not do this at all. If you
find_package(HDF5) and allow the FindHDF5.cmake supplied with cmake to run,
then it picks up the dll instread of the lib. I tried this on a new version of
cmake and it appears to be a new 'bug' - but if you use the NO_MODULE approach
then you use on the the hdf-config.cmake supplied when hdf5 is installed and
this does not happen.
If it is happening, then you need to go through your CMakeLists.txt and remove
any ${HDF5_C_LIBRARY} type of references and instead just link to "hdf5", the
target is defined as imported and all these errors go away. I presume this is
the fix you are referring to.
The trouble arises when you must support a cmake version of hdf5 (easy) and an
old style non cmake install of hdf5, (pain in the arse).
AFAICT there is a bug in the findhdf5.cmake supplied with cmake itself which
reports all these libraries as
HDF5_C_LIBRARY C:/Program Files/HDF5/bin/hdf5_D.dll
Instead of
HDF5_C_LIBRARY C:/Program Files/HDF5/bin/hdf5_D.lib
(just tested with cmake 2.8.11-rc3 and hdf5 cmake branch from svn updated a few
minutes ago)
I'm CC'ing the cmake list and Will (the maintainer of the findhdf5) just in
case they have some feedback that's useful.
Looking at the findhdf5 module, it's not obvious to me where this value is set,
so I won't attempt a fix (yet), but it'd be nice if we could get a fix into
cmake before the next release- which is quite soon I guess since they're on rc3.
JB
