Brad King wrote:
> On 02/11/2013 01:34 PM, Stephen Kelly wrote:
>> I also considered splitting the targets from the non-targets in the
>> implementation of the macros. That would mean changing the order of the
>> content of target_link_libraries calls generated by cmCoreTryCompile
>> because we would have two lists send from the macros to try_compile (one
>> of libraries, the other of targets). That would maybe need a policy.
>
> I don't think we need to split anything. The macros can pass everything
> in ${CMAKE_REQUIRED_LIBRARIES} to -DLINK_LIBRARIES and take the targets
> out of it to pass to a TARGETS argument for transformation. The latter
> would handle the export/import and the former would work as it does now
> but without CMakeExpandImportedTargets.
I see.
Would cmCoreTryCompile also generate a target_link_libraries line for the
targets after the existing target_link_libraries line?
Otherwise using the raw try_compile would not do what you expect:
try_compile( ... TARGETS foo ...)
# Generates an imported target for foo, but does not link to it.
What effect would the TARGETS parameter have in 'full project' mode?
Thanks,
Steve.
--
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
