- 21 Nov, 2016 1 commit
-
-
Brad King authored
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
-
- 09 Nov, 2016 1 commit
-
-
Brad King authored
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
-
- 16 May, 2016 1 commit
-
-
Kitware Robot authored
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.
-
- 27 Mar, 2015 1 commit
-
-
Brad King authored
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.
-
- 26 Nov, 2014 1 commit
-
-
Stephen Kelly authored
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.
-
- 14 Jul, 2014 1 commit
-
-
Brad King authored
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.
-
- 23 Jun, 2014 1 commit
-
-
Brad King authored
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.
-
- 09 Jan, 2014 1 commit
-
-
Stephen Kelly authored
The target properties with this prefix are whitelisted for INTERFACE_LIBRARY targets.
-
- 06 Jan, 2014 2 commits
-
-
Stephen Kelly authored
Document the valid signatures. Add a test for the IMPORTED GLOBAL signature.
-
Stephen Kelly authored
Make the CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE variable affect INTERFACE_LIBRARY targets.
-
- 10 Dec, 2013 1 commit
-
-
Stephen Kelly authored
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.
-
- 07 Oct, 2013 1 commit
-
-
Stephen Kelly authored
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.
-