On 13.12.11 15:59:17, Biddiscombe, John A. wrote:
> Project A creates a target which links to hdf5 using the hdf5 cmake generated
> cmake file which lists the imported location for the debug lib as hdf5d.lib
>
>
>
> SET_TARGET_PROPERTIES(hdf5 PROPERTIES
>
> IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "C"
>
> IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG "kernel32;ws2_32;wsock32;C:/Program
> Files/MPICH2/lib/mpi.lib;C:/Program Files/MPICH2/lib/fmpich2.lib"
>
> IMPORTED_LOCATION_DEBUG "${_IMPORT_PREFIX}/lib/hdf5d.lib"
>
> )
>
>
>
> when project A creates its own install file it generates the target
> properties as follows - using the name hdf5 - not hdf5d.lib
>
>
>
> SET_TARGET_PROPERTIES(A PROPERTIES
>
> IMPORTED_IMPLIB_DEBUG "D:/cmakebuild/test/bin/Debug/A.lib"
>
> IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG "C:/Program
> Files/MPICH2/lib/mpi.lib;hdf5; "
>
> IMPORTED_LOCATION_DEBUG "D:/cmakebuild/test/bin/Debug/A.dll"
>
> )
>
>
>
> and when project B loads the cmake file for project A, it does not pick up
> the correct lib name for the hdf5 library.
>
>
>
> Is there a way to get this right?
Sure, when project A is loaded into project B it either needs to search
and load the hdf5 cmake file or require that to be done in project B
before loading project A. Then the hdf5 target will be known in project
B too and linking will work fine.
If project A does not expose any of the API of hdf5 in its own libraries
and you're using dynamic linking and project B does not use hdf5 itself
then you could also remove hdf5 from the link-interface of project A.
Andreas
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
