[cmake-developers] Support for imported targets in CMAKE_REQUIRED_LIBRARIES

[Alexander Neundorf]

On Friday 20 January 2012, Brad King wrote:
> On 1/19/2012 11:49 AM, Alexander Neundorf wrote:
> > On Thursday 19 January 2012, Brad King wrote:
> >> 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.
> > 
> > I'll have a look at that too.
> > What things exactly do you have in mind additionally ?
> 
> Rather than jumping to an implementation of my proposal let's think through
> the interface.  The src-file signature of try_compile is currently:
> 
>   try_compile(RESULT_VAR <bindir> <srcfile>
>               [CMAKE_FLAGS flags...]
>               [COMPILE_DEFINITIONS flags...]
>               [OUTPUT_VARIABLE <var>]
>               [COPY_FILE <fileName>])
> 
> The CMakeLists.txt it generates includes the line
> 
>    TARGET_LINK_LIBRARIES(cmTryCompileExec ${LINK_LIBRARIES})
> 
> so right now one uses the CMAKE_FLAGS option to pass -DLINK_LIBRARIES=...
> to specify link libraries.  The try_compile command has no chance to
> recognize which options are libraries.  Instead, let's add a LINK_LIBRARIES
> option to try_compile:
> 
>   try_compile(RESULT_VAR <bindir> <srcfile>
>               ... [LINK_LIBRARIES libs...] ...)
> 
> Then the implementation of the command can evaluate the "libs..." arguments
> in a context where imported targets are known.  Loop over each library.
> For those that this->Makefile->FindTargetToUse() returns a target, verify
> that it is IMPORTED, and then call target->GetLinkInformation(config),
> where config is the try-compile's configuration.  The return value of
> that will be a cmComputeLinkInformation object from which you can query
> the link line.


I'm getting there.
To get the link line I moved code from cmLocalGenerator::OutputLinkLibraries() 
into a separate function GetLinkLine(cmTarget, cmComputeLinkInformation).
But before I get there I get a segfault:
#0  0x0821f1d7 in std::vector<std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::allocator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > >::begin() const ()
#1  0x0827f733 in cmTarget::ComputeLinkClosure(char const*, 
cmTarget::LinkClosure&) ()
#2  0x0827f594 in cmTarget::GetLinkClosure(char const*) ()
#3  0x0827f44a in cmTarget::GetLinkerLanguage(char const*) ()
#4  0x0832a29a in 
cmComputeLinkInformation::cmComputeLinkInformation(cmTarget*, char const*) ()
#5  0x08286f1b in cmTarget::GetLinkInformation(char const*) ()
#6  0x082bf5ab in cmCoreTryCompile::CreateProject(std::basic_string<char, 
std::char_traits<char

Still figuring out what's going wrong there...
It crashes in cmTarget::ComputeLinkClosure() because 
mTarget::GetLinkImplementation() returns 0 for imported targets. It probably 
should not get there at all, since calling GetLinkerLanguage() always leads to 
that path.
Well, enough for today...

Alex