[cmake-developers] Generator expressisons in target properties

[Brad King]

On 10/27/2012 2:00 PM, Stephen Kelly wrote:
> I think in order to finish this feature, I'll need to know more about why 
> the direct and indirect dependencies need to be kept separate. Can you give 
> more information?

Read the comments in "cmComputeLinkDepends.cxx" and look through
the implementation.  The entire approach is dependent on knowing
what was directly specified as dependencies of each target.

> My goal is for this to work on all platforms and all Qt configurations:
> 
>  find_pacakge(Qt5Widgets REQUIRED)
>  add_executable(foo WIN32 main.cpp)
>  target_link_libraries(foo Qt5::Widgets)
> 
> However, the default configuration of Qt requires that 
> POSITION_INDEPENDENT_CODE is ON. I would want that to be part of the 
> interface of Qt5::Widgets

Good example.  Basically -fPIE and -DFOO=1 are equally possible
usage requirements.

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

> compile. (As a side note, I'd also like to extend try_compile so that it 
> really only tries to compile with a COMPILE_ONLY option or so).

That can be approximated in IDEs by making the test project build
only a STATIC library so no linking is needed.

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

> I propose a different algorithm. Something similar to this:
[snip]
> This would mean that either the link libraries may depend on the property, 
> or the property may depend on the link libraries, but not both. 

...and this condition is enforced separately for each property.

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

> Do current generators compute the link closure before or after the 
> INCLUDE_DIRECTORIES or COMPILE_DEFINITIONS?

Since they have not been transitive before it hasn't mattered.  IIRC
the link closures are calculated wherever cmComputeLinkInformation
(which has cmComputeLinkDepends inside it) is used by the generators.

-Brad