summaryrefslogtreecommitdiffstats
path: root/Tests/InterfaceLibrary
Commit message (Collapse)AuthorAgeFilesLines
* Do not initialize NO_SYSTEM_FROM_IMPORTED on INTERFACE librariesBrad King2017-10-131-1/+0
| | | | | | | | | | | | | | The change in commit v3.8.0-rc1~276^2 (Allow NO_SYSTEM_FROM_IMPORTED on imported INTERFACE libraries, 2016-11-21) was incorrect. The property is not meant to be set on imported targets at all. It is meant to be set on their consumers that compile sources. Since INTERFACE libraries have no sources to compile, the property is not needed on them. Revert most of that change. Unfortunately we must still tolerate project code setting NO_SYSTEM_FROM_IMPORTED on INTERFACE libraries because they were allowed by CMake 3.8 and 3.9. Issue: #17348
* Allow NO_SYSTEM_FROM_IMPORTED on imported INTERFACE librariesBrad King2016-11-211-0/+1
| | | | | | | | | 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
* Allow imported INTERFACE libraries to specify a link library nameBrad King2016-11-094-2/+29
| | | | | | | | | | | | | | | 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
* Revise C++ coding style using clang-formatKitware Robot2016-05-166-6/+12
| | | | | | | | | | | | | 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.
* Allow add_dependencies() on INTERFACE libraries (#15414)Brad King2015-03-272-3/+9
| | | | | | | | | | 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.
* Genex: Fix evaluation context propagation for TARGET_OBJECTS.Stephen Kelly2014-11-261-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* Allow INTERFACE_SOURCES to specify $<TARGET_OBJECTS> (#14970)Brad King2014-07-143-2/+8
| | | | | | | | | | | | 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.
* Fix scope of transitive target name lookupsBrad King2014-06-234-2/+23
| | | | | | | | | | | 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.
* InterfaceLibrary: Add test requiring MAP_IMPORTED_CONFIG whitelistingStephen Kelly2014-01-092-0/+28
| | | | | The target properties with this prefix are whitelisted for INTERFACE_LIBRARY targets.
* add_library: Disallow invalid signatures for INTERFACE_LIBRARY.Stephen Kelly2014-01-062-1/+3
| | | | | Document the valid signatures. Add a test for the IMPORTED GLOBAL signature.
* cmTarget: Enable convenient include dir handling for INTERFACE_LIBRARY.Stephen Kelly2014-01-064-1/+24
| | | | | Make the CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE variable affect INTERFACE_LIBRARY targets.
* Remove INTERFACE build targets.Stephen Kelly2013-12-103-0/+21
| | | | | | | | | | | | | | | 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.
* Add the INTERFACE_LIBRARY target type.Stephen Kelly2013-10-078-0/+115
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.
generated by cgit v0.12 at 2024-11-13 20:50:35 (GMT)