This reverts commit 2bee6f5b.

This expression is not used, and has a semantic which is not completely
optimal (namely considering utility targets to be targets, though
usually we are interested in linkable targets).

Remove it so that we have more freedom to define better expressions in
the future.

Conflicts:
        Source/cmGeneratorExpressionEvaluator.cxx
        Tests/CMakeCommands/target_compile_definitions/CMakeLists.txt
        Tests/CMakeCommands/target_compile_definitions/consumer.cpp

This reverts commit 0b92602b.

Conflicts:
	Source/cmGeneratorExpressionEvaluator.cxx
	Tests/CMakeCommands/target_compile_definitions/CMakeLists.txt
	Tests/CMakeCommands/target_include_directories/CMakeLists.txt

This reverts commit 9712362b.

After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a
generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of
its link interface dependencies.

That means that code such as this will result in the 'user' target
using /bar/include and /foo/include:

 add_library(foo ...)
 target_include_directories(foo INTERFACE /foo/include)
 add_library(bar ...)
 target_include_directories(bar INTERFACE /bar/include)
 target_link_libraries(bar LINK_PUBLIC foo)

 add_executable(user ...)
 target_include_directories(user PRIVATE
    $<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>)

Also process the interface include directories from direct link
dependencies for in-build targets.

The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The
include directories related code is currently more complex because
we also need to store a backtrace at configure-time for the purpose
of debugging includes. The compile definitions related code will use
the same pattern in the future.

This is not a change in behavior, as existing code has the same effect,
but that existing code will be removed in follow-up commits.

The LINKED expression is exclusively for handling INTERFACE content
and it does not make sense for utility targets to have INTERFACE
content.

This tracking was added during the development of commit 042ecf04
(Add API to calculate link-interface-dependent bool properties
or error., 2013-01-06), but was never used.

It was not necessary to use the content because what is really
useful in that logic is to determine if a property has been implied
to be null by appearing in a LINK_LIBRARIES genex.

I think the motivating usecase for developing the feature of
keeping track of the targets relevant to a property was that I
thought it would  make it possible to allow requiring granular
compatibility of interface properties only for targets which
depended on the interface property. Eg:

 add_library(foo ...)
 add_library(bar ...)

 add_executable(user ...)
 # Read the INTERFACE_POSITION_INDEPENDENT_CODE from bar, but not
 # from foo:
 target_link_libraries(user foo $<$<TARGET_PROPERTY:POSTITION_INDEPENDENT_CODE>:bar>)

This obviously doesn't make sense. We require that INTERFACE
properties are consistent across all linked targets instead.

We need to make sure expressions which evaluate TARGET_PROPERTY:TYPE
multiple times for example get the correct result each time, and
not an empty string instead.

Generator expressions whose output depends on the configuration
now record that fact. The GetIncludeDirectories method can use
that result to cache the include directories for later calls.

GetIncludeDirectories is called multiple times for a target
for each configuration, so this should restore performance for
multi-config generators.

While porting boost to use these features, the generation step took
too long (several minutes before I stopped it). The reason was that
the boost libraries form a large interdependent mesh. The libraries
list their dependencies in their INTERFACE such as:

 $<LINKED:boost::core>;$<LINKED:boost::config>;$<LINKED:boost::mpl>

As boost::core already depends on the boost::config libraries, that
expression has no impact on the end-content, as it is removed after
the generation step. There is no DAG issue though, so the generator
expression evaluation would fully evaluate them. In the case of the
config library, it also depends on the core library, so all depends
are followed through that again, despite the fact that they've just
been evaluated. After this patch, the evaluation skips libraries if
they have already been seen via depends or directly in the content.

This patch keeps track of targets whose INTERFACE has been consumed
already. The INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS properties
are whitelisted because repeated content will be stripped out later
during generation. For other properties now and in the future, that
may not be the case.

This is both a short form of using a TARGET_DEFINED expression
together with a TARGET_PROPERTY definition, and a way to strip
non-target content from interface properties when exporting.

An empty string is not likely going to produce expected results
in any evaluation context. It is replaced by preprocessing
currently.

This was segfaulting before.

Stephen Kelly authored Nov 20, 2012 and Brad King committed Jan 23, 2013

When using QAxServer, ensure that the qtmain library is excluded
by reporting an error at CMake time if it is not.

The properties are evaluated as link-dependent interface properties when
evaluating the generator expressions.

This new expression allows checking how a policy was set when a target
was created.  That information is only recorded for a subset of policies,
so a whitelist is used.

This tests whether the parameter is a usable target.

Those properties can't later be implicitly defined by the interface
of those link libraries.

Contextually, the behavior is as if the properties content from another
target is included in the string and then the result is evaluated.

Constructs such as these are an error as they are direct self-references:

 set_property(TARGET foo APPEND PROPERTY
   INCLUDE_DIRECTORIES $<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>)
 set_property(TARGET foo APPEND PROPERTY
   INCLUDE_DIRECTORIES $<TARGET_PROPERTY:INCLUDE_DIRECTORIES>)

However, this is an indirect self-reference in a cycle, and not an error:

 set_property(TARGET foo APPEND PROPERTY
   INCLUDE_DIRECTORIES $<TARGET_PROPERTY:bar,INCLUDE_DIRECTORIES>)
 set_property(TARGET bar APPEND PROPERTY
   INCLUDE_DIRECTORIES $<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>)

The current node being evaluated transitively in the generator
expression must be available to resolve mapped configs.

It will be used as a preprocessing marker.

This is for specifying INCLUDE_DIRECTORIES relevant to the build-location
or the install location for example:

 set_property(TARGET foo PROPERTY
   INTERFACE_INCLUDE_DIRECTORIES
   "$<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR};${CMAKE_CURRENT_SOURCE_DIR}>"
   "$<INSTALL_INTERFACE:${CMAKE_INSTALL_PREFIX}/include>"
 )

A 'bar' target can then use:

 set_property(TARGET bar PROPERTY
   INCLUDE_DIRECTORIES
   "$<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES>"
 )

and it will work whether foo is in the same project, or an imported target
from an installation location, or an imported target from a build location
generated by the export() command.

Because the generator expressions are only evaluated at build-time, these
new expressions are equivalent to the ZeroNode and OneNode.

The GeneratorExpression test is split into parts. Some shells can't run
the custom command as it is getting too long.

For consistency with the rest of the method.

Following from the discussion here:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=5170
 (Re: Generator expressisons in target properties, 26 Oct 12:10)

we can't split cmTarget API for linking into cmGeneratorTarget. In
the future we will probably also need to move the include and compile
definitions API back to cmTarget so that it can be used by export().

Stephen Kelly authored Nov 01, 2012 and Brad King committed Nov 05, 2012

This fixes a regression introduced by commit f1eacf0e
(cmGeneratorExpression: Re-write for multi-stage evaluation).

Stephen Kelly authored Oct 19, 2012 and Brad King committed Oct 22, 2012

In the unit test, use the same IMPORTED_LOCATION trick that
the ExportImport test uses.

The problem may be that the reportError method is static, so make
it non-static on that platform.

Stephen Kelly authored Oct 04, 2012 and Brad King committed Oct 09, 2012

It might not exist with GCC 2.9.

Stephen Kelly authored Oct 04, 2012 and Brad King committed Oct 09, 2012

The CONFIGURATION can not be manipulated at unit testing time, so
this is not unit tested further.

Stephen Kelly authored Oct 04, 2012 and Brad King committed Oct 09, 2012

They must be non-empty, and match a restrictive regexp.