John,
Fantastic information, thanks! I spent much of yesterday stumbling
around with this, trying to achieve the expected behavior on Windows,
Linux and OSX with the same CMakeLists.txt syntax. I just
double-checked the NO_MODULE argument and it worked as expected;
embarrasing, but this is the danger of having too many terminal windows
open at once. I expect I probably ran 'cmake' from a terminal
unassociated with the emacs session.
We are preparing the 4.3.0 release, and this should hopefully let me
clean up the CMakeLists.txt file. It has grown more-or-less
organically, and should really be tightened up a bit. Thanks for your
feedback/investigation on this. I've received a lot of feedback from our
community (yourself, Pedro Vicente, many others) when it comes to the
CMake integration, which has been very helpful!
Thanks again, have a great day,
-Ward
On 4/25/13 1:36 AM, Biddiscombe, John A. wrote:
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
