[cmake-developers] Generator expressisons in target properties

[Stephen Kelly]

Brad King wrote:

> On 10/27/2012 2:00 PM, Stephen Kelly wrote:
>> Another related thing I would like to be able to do is this:
>>  
>>  try_compile(_compile_result ${CMAKE_BINARY_DIR}
>>     "#include <QGlobal>\n int main(int,char**) { return 0; }"
>>     TARGETS Qt5::Core
>>     OUTPUT_VARIABLE _compile_output_var)
>> 
>> That is, add a TARGETS component to the try_compile signature to specify
>> the contents of the target_link_libraries line in the code generated by
>> try
> 
> Extending try_compile to allow more to be specified about what to
> put in the test project is easy.  The hard part is getting the info
> about imported targets into the test project.  Perhaps your work in
> porting work to cmGeneratorTarget can help.  Ideally the configuration
> process inside CMake would occur on a stack of configurations.  A
> try_compile would push a new scope on the stack, configure additional
> targets *as if they were in the outer project*, generate them, build,
> and then pop off the stack as if nothing happened.  That would allow
> any "will _this_ work here" kind of test.

Ok, I'll keep this in mind for the future.

> 
>> In KDE, a try_compile like that is used to determine if Qt is compiled
>> with hidden visibility.
> 
> Why shouldn't Qt just publish this information?  In your Qt5 cmake
> packaging you could record it.

Yes, with Qt 5 there is a variable for that information. 

However, with Qt 4 it is not available, and that shows that there may be 
uses for similar approaches with other modules which are not Qt 5. 

>> by simply setting the property explicitly, thus breaking the cycle:
> [snip]
>> I think this is the best compromise.
> 
> Yes.  This allows the motivating cases to work in the expected way.
> The cycle errors will really be saying "this is ambiguous so please
> tell me what to do by setting a property explicitly".

Ok, so I'll see if I can make an approach like this work.

Thanks,

Steve.