bc30f8b5e6
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>
9 lines
232 B
CMake
9 lines
232 B
CMake
|
|
add_library(tgt STATIC empty.cpp)
|
|
add_library(Sub::tgt ALIAS tgt)
|
|
|
|
# foo comes from the top-level CMakeLists.txt
|
|
add_library(Top::foo ALIAS foo)
|
|
get_target_property(some_prop Top::foo SOME_PROP)
|
|
target_link_libraries(tgt Top::foo)
|