Upcoming features will make use of that.

Otherwise, in the string case, we would get a null pointer instead
of the implied empty string. That will become relevant when the
comparison result is used.

Stephen Kelly authored Oct 22, 2013 and Brad King committed Oct 23, 2013

Other warnings for the same policy already have similar output since
commit 81d2793e (Add differing target property content to policy CMP0022
warning, 2013-09-11).

Introduce a policy to control the behavior.

The AliasTargets unit test already tests that using a
double-semicolon in the name is not an error. Change the ExportImport
test to use a namespace with a double-semicolon too.

Stephen Kelly authored Aug 21, 2013 and Brad King committed Oct 21, 2013

The result is that the depends of the target are created.

So,

 add_library(somelib foo.cpp)
 add_library(anotherlib EXCLUDE_FROM_ALL foo.cpp)
 add_library(extra EXCLUDE_FROM_ALL foo.cpp)
 target_link_libraries(anotherlib extra)

 add_library(iface INTERFACE)
 target_link_libraries(iface INTERFACE anotherlib)

Executing 'make iface' will result in the anotherlib and extra targets
being made.

Adding a regular executable to the INTERFACE of an INTERFACE_LIBRARY
will not result in the executable being built with 'make iface' because
of the logic in cmComputeTargetDepends::AddTargetDepend.

So far, this is implemented only for the Makefile generator. Other
generators will follow if this feature is possible for them.

Make INTERFACE_LIBRARY targets part of the all target by default.
Test this by building the all target and making the expected library
EXCLUDE_FROM_ALL.

Drop all DefineProperty calls for non-chained properties.  Drop the
documentation from the chained ones.  The documentation for all
properties is now in Help/prop_*/*.rst files.

These checks want to know if named target properties are builtin, which
is now known by checking the Help/prop_tgt directory.  (Previously the
check could be confused by a define_property call in the project.)

The final location and name of a build-target is not determined
until generate-time. However, reading the LOCATION property from
a target is currently allowed at configure time. Apart from creating
possibly-erroneous results, this has an impact on the implementation
of cmake itself, and prevents some major cleanups from being made.

Disallow reading LOCATION from build-targets with a policy. Port some
existing uses of it in CMake itself to use the TARGET_FILE generator
expression.

It is succeeded by COMPILE_OPTIONS, which supports generator
expressions, is a list rather than a string, and is properly
escaped.

Stephen Kelly authored Nov 02, 2012 and Brad King committed Oct 07, 2013

This target type only contains INTERFACE_* properties, so it can be
used as a structural node. The target-specific commands enforce
that they may only be used with the INTERFACE keyword when used
with INTERFACE_LIBRARY targets. The old-style target properties
matching LINK_INTERFACE_LIBRARIES_<CONFIG> are always ignored for
this target type.

The name of the INTERFACE_LIBRARY must match a validity generator
expression. The validity is similar to that of an ALIAS target,
but with the additional restriction that it may not contain
double colons. Double colons will carry the meaning of IMPORTED
or ALIAS targets in CMake 2.8.13.

An ALIAS target may be created for an INTERFACE library.

At this point it can not be exported and does not appear in the
buildsystem and project files are not created for them. That may
be added as a feature in a later commit.

The generators need some changes to handle the INTERFACE_LIBRARY
targets returned by cmComputeLinkInterface::GetItems. The Ninja
generator does not use that API, so it doesn't require changes
related to that.

Introduce a target property to control this behavior variable
to set the default value for the target property.

This does not affect try_compile runs.

We already have cmake::IsPropertyDefined for the same reason.

Stephen Kelly authored Sep 12, 2013 and Brad King committed Sep 13, 2013

The string could be null at this point.

compatiblity -> compatibility

List the contents of the INTERFACE_LINK_LIBRARIES and the old-style
property.

We populate and maintain a vector of structs to keep track of
backtraces already, so no need to populate the Properties container
additionally.

For completeness, it is necessary to remove the condition for
populating the vector for only valid library names and generator
expressions. That condition is now determined when evaluating the
generator expressions.

Exclude Ninja and Xcode from the CMP0021 test

They do not behave the same as the makefile generator with
relative paths.

Don't overwrite the header file for in-source builds.

With this, projects can enable MACOSX_RPATH by default, but still have
a way to install libraries with no install name dirs into locations
such as /usr/local/lib by setting INSTALL_NAME_DIR="".

* The ALIAS name must match a validity regex.
* Executables and libraries may be aliased.
* An ALIAS acts immutable. It can not be used as the lhs
  of target_link_libraries or other commands.
* An ALIAS can be used with add_custom_command, add_custom_target,
  and add_test in the same way regular targets can.
* The target of an ALIAS can be retrieved with the ALIASED_TARGET
  target property.
* An ALIAS does not appear in the generated buildsystem. It
  is kept separate from cmMakefile::Targets for that reason.
* A target may have multiple aliases.
* An ALIAS target may not itself have an alias.
* An IMPORTED target may not have an alias.
* An ALIAS may not be exported or imported.

In generator expression contexts, this can be used to determine the
name of the head target in the evaluation.

For shared libraries and executables, the linker_language is
indepenedent of the linked libraries.

Stephen Kelly authored Jun 04, 2013 and Brad King committed Jul 24, 2013

Add a new signature to help populate INTERFACE_LINK_LIBRARIES and
LINK_LIBRARIES cleanly in a single call.  Add policy CMP0023 to control
whether the keyword signatures can be mixed with uses of the plain
signatures on the same target.

Stephen Kelly authored Jul 18, 2013 and Brad King committed Jul 24, 2013

It accepted an optional argument to test for equality, but no way
to get the linker language of a particular target.

TARGET_PROPERTY provides this flexibility and STREQUAL provides
the necessary API for equality test.

Extend the CompileDefinitions test to cover accessing the
property of another target.

Stephen Kelly authored Jul 02, 2013 and Brad King committed Jul 16, 2013

Unlike other target properties, this does not have a corresponding
non-INTERFACE variant.

This allows propagation of system attribute on include directories
from link dependents.

Drop the "vsProjectFile" argument from cmTarget::TraceDependencies.  It
appears to be the modern equivalent to a hunk added in commit ba68f771
(...added new custom command support, 2003-06-03):

 +  name = libName;
 +  name += ".dsp.cmake";
 +  srcFilesToProcess.push(name);

but was broken by refactoring at some point.  The current behavior tries
to trace dependencies on a source file named the same as a target, which
makes no sense.  Furthermore, in code of the form

 add_executable(foo foo.c)
 add_custom_command(OUTPUT "${somewhere}/foo" ... DEPENDS foo)

the "vsProjectFile" value "foo" matches source "${somewhere}/foo.rule"
generated to hold the custom command and causes the command to be added
to the "foo" target incorrectly.

Simply drop the incorrect source file trace and supporting logic.

Use constructs similar to those for COMPILE_OPTIONS. This is a little
different because there is a command to remove_definitions(), so
we can't populate the equivalent target property until generate-time
in cmGlobalGenerator.

Use preprocessor loops and add a unit test for the appropriate
policies. All policies whose value is recorded at target creation
time should be part of this list.

Refactor to create AddCompileDefinitions.

Always populate the INTERFACE_LINK_LIBRARIES for interface
entries. Don't populate the old interface properties
matching (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?
if CMP0022 is NEW.

Because the INTERFACE_LINK_LIBRARIES property is now populated by
the target_link_libraries when operating on a static library,
make an equivalent change which populates the property with
the same value when the old link_libraries() command is used. This
silences the policy warning in that case.