summaryrefslogtreecommitdiffstats
path: root/Tests/AliasTarget
Commit message (Collapse)AuthorAgeFilesLines
* Merge topic 'fix-target-alias-in-subdir'Brad King2016-04-051-0/+5
|\ | | | | | | | | | | 0e44f489 Rename local target lookup methods to clarify purpose bc30f8b5 Fix lookup of an ALIAS target outside aliased target's directory (#16044)
| * Fix lookup of an ALIAS target outside aliased target's directory (#16044)Brad King2016-04-011-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Refactoring in commit v3.5.0-rc1~272^2~11 (cmTarget: Implement ALIAS in terms of name mapping, 2015-10-25) accidentally introduced logic that assumes ALIAS targets always reference targets in their own directory. Fix this and add a test case. The configure-step fix is that `cmMakefile::FindTarget` should not consider aliases. The purpose of this method is just to look up targets local to a directory. Since ALIAS and normal targets share a namespace we know a locally defined target will never collide with an ALIAS target anyway. The method has 3 call sites, and this change is safe for all of them: * `cmInstallCommand::HandleTargetsMode`: Rejects aliases before the call. * `cmFLTKWrapUICommand::FinalPass`: Should never have considered aliases. * `cmMakefile::FindTargetToUse`: Falls back to a global lookup anyway. The generate-step fix is that `cmLocalGenerator::FindGeneratorTarget` should not consider aliases. This method is the generate-step equivalent to the above. The method has 2 call sites, and this change is safe for both of them: * `cmInstallTargetGenerator::Compute`: Never uses an alias target name. * `cmLocalGenerator::FindGeneratorTargetToUse`: Falls back to global lookup. Reported-by: Matteo Settenvini <matteo@member.fsf.org>
* | Tests: fix AliasTarget building on Clang/C2Mariusz PluciƄski2016-03-101-0/+7
|/
* Alias: Fix access at generate-time (#15832)Stephen Kelly2015-11-083-1/+13
| | | | | | | | | | | | Commit c389f8bb (cmLocalGenerator: Port Find method away from GetGeneratorTarget, 2015-10-25) ported the implementation of FindGeneratorTargetToUse away from the FindTargetToUse method, but neglected to handle alias targets. The latter method has a parameter to determine whether to include alias targets in the search, but as that is only needed at configure time, this generate-time equivalent does not need the condition.
* HP aCC: record compiler flag for Ansi C++98 support for version 3.80 onwardsRolf Eike Beer2014-04-251-1/+9
| | | | | | Old versions of aCC need a special compiler flag to get full C++98 template support as e.g. CMake itself or the Complex and ComplexOneConfig tests need. The same versions need a special flag to get a proper C++ library, too.
* get_property: Fix testing ALIASED_TARGET target property (#14670)Stephen Kelly2014-01-041-0/+22
| | | | | In the case where the argument is not an ALIAS, the variable should be set to a -NOTFOUND content.
* Add the INTERFACE_LIBRARY target type.Stephen Kelly2013-10-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Add the ALIAS target concept for libraries and executables.Stephen Kelly2013-08-027-0/+119
* 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.