[cmake-developers] Support for imported targets in CMAKE_REQUIRED_LIBRARIES

[Brad King]

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