On 1/18/2012 4:24 PM, Alexander Neundorf wrote:
On Wednesday 18 January 2012, Alexander Neundorf wrote:
Hi,
the variable CMAKE_REQUIRED_LIBRARIES is used by several of the
check-modules for listing additional libraries which should be linked.
It is common to use variables set by Find-modules for this, e.g.
set(CMAKE_REQUIRED_LIBRARIES ${JPEG_LIBRARIES} )
Now, if the module did not simply set JPEG_LIBRARIES to the full path, but
instead created an imported target, e.g. FindJPEG::libjpeg, this leads to a
problem.
The check-modules will simply append this to the linker command, so there
will be -lFindJPEG::libjpeg, which will not work.
This actually happened in KDE the first time more than 2 years ago.
On cmake stage there is now a branch HandleTargetsInCMakeRequiredLibraries,
where I ported the solution from KDE to CMake and applied it to all places
where CMAKE_REQUIRED_LIBRARIES is used.
I did not test it yet (but it should work, since it is exactly the same as
in KDE).
Please have a look at it.
It's here:
http://cmake.org/gitweb?p=stage/cmake.git;a=log;h=refs/heads/HandleTargetsInCMakeRequiredLibraries
When inspecting the IMPORTED_CONFIGURATIONS, rather than choosing the first
one might you honor CMAKE_TRY_COMPILE_CONFIGURATION?
Does it handle link-interface libraries recursively?
I think a full solution to this will end up duplicating a lot of the logic
that CMake already has in its C++ code for link dependency analysis. I
wonder if instead you could modify the signature of try_compile to accept
the LINK_LIBRARIES as a formal argument. Then teach the C++ code to
resolve the imported targets and take care of the link interfaces.
-Brad
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
