GitLab

Imported INTERFACE libraries can specify include directories via
`INTERFACE_INCLUDE_DIRECTORIES` so the default behavior of treating them
as system include directories applies.  Allow users to turn this off by
setting `NO_SYSTEM_FROM_IMPORTED` on such targets.

Closes: #16443

Add an `IMPORTED_LIBNAME[_<CONFIG>]` target property to specify a library
name to be placed on the link line in place of an interface library
since it has no library file of its own.  Restrict use of the property
to imported `INTERFACE` libraries.

This will be particularly useful for find modules that need to provide
imported libraries from system SDKs where the full path to the library
file is not known.  Now such find modules will be able to provide an
imported interface library and set `IMPORTED_LIBNAME` to refer to the
SDK library by name.

Issue: #15267

Run the `Utilities/Scripts/clang-format.bash` script to update
all our C++ code to a new style defined by `.clang-format`.
Use `clang-format` version 3.8.

* If you reached this commit for a line in `git blame`, re-run the blame
  operation starting at the parent of this commit to see older history
  for the content.

* See the parent commit for instructions to rebase a change across this
  style transition commit.

Revert commit v3.0.0-rc1~175^2~20 (add_dependencies: Disallow use with
INTERFACE_LIBRARY, 2013-12-25).  Teach our dependency analysis to
transitively follow INTERFACE target utility dependencies as was done or
IMPORTED targets in commit v2.8.6~127^2~1 (Allow add_dependencies() on
imported targets, 2010-11-19).  Extend the InterfaceLibrary test with a
case to cover header generation for a header-only INTERFACE library via
a custom target.

Extract a new method to encapsulate the requirements of evaluating
dependent-expressions, namely, propagation of the
EvaluateForBuildsystem setting, which is missing from the
getLinkedTargetsContent implementation.

Commit v3.1.0-rc1~688^2 (Genex: Only evaluate TARGET_OBJECTS to determine
target sources., 2014-03-20) introduced an error case for use of
TARGET_OBJECTS outside of the context of generating the buildsystem,
as the path to object files may be dependent on buildsystem
variables (See bug #15226).

Commit v3.1.0-rc1~314^2 (Allow INTERFACE_SOURCES to specify
$<TARGET_OBJECTS> (#14970), 2014-07-09) made it possible to
propagate such content to dependent targets.

While that commit propagated the EvaluateForBuildsystem setting
for the case of a TARGET_PROPERTY expression, as generated for
direct dependencies of a target in
cmTargetInternals::AddInterfaceEntries, it did not add propagation
for content from further transitive target dependencies, as determined
by getLinkedTargetsContent.

Fix cmTarget::GetSourceFiles to set EvaluateForBuildsystem on the
$<TARGET_PROPERTY:...,INTERFACE_SOURCES> generator expression so that
the $<TARGET_OBJECTS> generator expression is allowed within an
INTERFACE_SOURCES value.

Extend the InterfaceLibrary test to cover this case.  Extend the
RunCMake.TargetObjects test to cover failure of $<TARGET_OBJECTS>
when used through $<TARGET_PROPERTY:...,INTERFACE_SOURCES> in a
non-buildsystem context.

In cmTarget, cmGeneratorTarget, and cmGeneratorExpressionEvaluator, fix
target name lookups to occur in the cmMakefile context of the target
that referenced the name, not the current 'head' target.  The context
matters for imported targets because they are directory-scoped instead
of globally unique.  We already do this in cmComputeLinkDepends and
cmComputeTargetDepends.

Extend the InterfaceLibrary test with an example covering this behavior.

The target properties with this prefix are whitelisted for
INTERFACE_LIBRARY targets.

Document the valid signatures. Add a test for the IMPORTED GLOBAL
signature.

Make the CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE variable affect
INTERFACE_LIBRARY targets.

Commit b04f3b9a (Create make rules for INTERFACE_LIBRARY
targets., 2013-08-21) extended the makefile generator to create
build targets for INTERFACE_LIBRARY targets. No other generators
were extended with this feature.

This conflicts with the feature of whitelisting of target properties
read from INTERFACE_LIBRARY targets. The INTERFACE_* properties
of the INTERFACE_LIBRARY may legitimately contain TARGET_PROPERTY
generator expressions for reading properties from the 'head target'.
The 'head target' would be the INTERFACE_LIBRARY itself when creating
the build rules for it, which means that non-whitelisted properties
would be read.

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.