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.
-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
