Brad King wrote: > On 02/09/2013 06:24 AM, Stephen Kelly wrote: >> The approach that I took was to not expose the feature through the cmake >> language, and instead make the use of CMakeExpandImportedTargets >> obsolete, and make try_compile directly handle CMAKE_REQUIRED_LIBRARIES >> containing IMPORTED targets. (This also means that try_compile will >> compute the link information for the targets correctly now - the macro >> didn't do that). >> >> It's in the updated try_compile_targets branch. Will I merge it to next? > > The branch looks like a great start! However, I do not think looking for > > -DLINK_LIBRARIES:STRING= > > as a literal will be reliable. There is no reason projects have to > include > the :STRING part. I'd rather this be made a first-class keyword argument > to try_compile or something like that.
Yes, that's how I had implemented it before. One of the reasons I implemented it by reading from the LINK_LIBRARIES was for source compatibility. The CMAKE_REQUIRED_LIBRARIES populates that. One way to make it a first-class keyword would be to introduce a CMAKE_REQUIRED_TARGETS that the macros use, or updating the macros to be more modern and take them in a TARGETS section of their arguments, but that also raises source compatibility concerns. I wanted to make it so that people can use the new interfaces without having to split their libraries from their targets and set multiple variables. 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. So, I still think it is best to process targets from LINK_LIBRARIES. I can make the processing smart enough to detect the optional STRING part. > It could also be useful for the > full-project form of the command in addition to the single-source form. We can in addition to the above add a TARGETS parameter for this. I'm not really sure it's necessary (the full project form can use find_package), and I wonder if we can detect dangerous code: export(TARGETS foo bar NAMESPACE exp_) try_compile( ... TARGETS exp_foo exp_bar) which obviously won't work. Maybe export sets can be checked to see if they contain the named target and throw an error. 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
