[cmake-developers] Depends information in buildsystem files

[Brad King]

On 02/07/2013 09:02 AM, Stephen Kelly wrote:
> A concern though is this in CMakeExpandImportedTargets.cmake:            
> 
>  get_target_property(_linkInterfaceLibs "${_CURRENT_LIB}" 
>    IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} )
> 
> That macro won't work if the IMPORTED_LINK_INTERFACE_LIBRARIES_ has 
> generator expressions. Wherever that macro is needed though, cmake should 
> probably be updated to have built-in support for imported targets probably.

There was extensive discussion of this when that macro was first added.
The try_compile projects are their own projects.  I said at the time
that those projects should have to import any targets they want to use
just like the containing project does.  The problem is that means the
CMake-provided macros like check_symbol_exists cannot be used on the
imported libraries.

The full solution is to refactor things enough that a new kind of
try_compile can be implemented.  It should push the configuration
process state on a stack, run more CMake code in the isolated state
to add some targets, and then generate the build system for them
directly out of the temporary configuration state.  Finally the
configuration stack would be popped back to the try_compile call and
the result variable would be set.  This would allow the full state
of the main project to be used for generation of a try_compile,
including imported targets.

Achieving this will require making the entire configuration state
read-only during generation.  Currently the generators do destructive
updates in a few cases.  That would have to be fixed.  A start to this
is cmGeneratorTarget, but until export() is generate-time-only we
cannot fully move to that.

Meanwhile, fixing the macro will require a CMake-language interface
for immediate evaluation of generator expressions.  Of course that
would introduce a new case like the configure-time export() which
we want to drop so much :(

-Brad