[cmake-developers] Depends information in buildsystem files

[Stephen Kelly]

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.