View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015101CMakeCMakepublic2014-08-22 08:292015-03-02 08:57
ReporterBjörn Piltz 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformApple MacOSOS XOS Version10.4.10
Product VersionCMake 3.0.1 
Target VersionCMake 3.1Fixed in VersionCMake 3.1 
Summary0015101: Imported libraries go out of scope after call to target_link_libraries().
DescriptionI have a project where module lib - a library - depends on Qt, so it calls find_package(Qt5 ...) and target_link_libraries(lib Qt5::Core). Later I call target_link_libraries(app lib).
The cmake configure step runs through without problems, but the generate step halts with the message:

    Target "app" links to target "Qt5::Core" but the target was not found.
    Perhaps a find_package() call is missing for an IMPORTED target, or an
    ALIAS target is missing?

According to the documentation the target Qt5::Core is out of scope for 'app' since app is not in a subdirectory of the directory where add_library(... IMPORTED) was made, but I would argue that this is a bug since the target was in scope when the call add_library(lib Qt5::Core) was made.

This issue is not specific to Qt and I'm aware that it could be fixed on their side by calling add_library(... IMPORTED GLOBAL). I'm hoping it could be fixed on the cmake side, though.
Steps To Reproducegit clone https://github.com/bjornpiltz/cmake_bug.git [^] cmake_bug
mkdir work
cd work
cmake -DCMAKE_PREFIX_PATH=<Qt5>/lib/cmake/ ../cmake_bug/
Additional InformationThis issue is platform independent.
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0036661)
Brad King (manager)
2014-08-22 08:47

 Historically the dependency lookups were supposed to occur in the scope of the target making the direct reference, not the final target getting the dependency transitively. This may have been broken during the usage requirements implementation. Since 3.0 I've refactored some of that implementation and fixed at least one case involving this kind of lookup. Please try a nightly binary:

 http://www.cmake.org/files/dev/?C=M;O=D [^]

or build from our Git 'master' branch.
(0036662)
Brad King (manager)
2014-08-22 08:50

 Re 0015101:0036661: Local testing of the 'master' branch as of commit 16afccac confirms that the example you provided is fixed.
(0038111)
Robert Maynard (manager)
2015-03-02 08:57

 Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2014-08-22 08:29 Björn Piltz New Issue
2014-08-22 08:47 Brad King Note Added: 0036661
2014-08-22 08:50 Brad King Note Added: 0036662
2014-08-22 10:45 Brad King Target Version => CMake 3.1
2014-09-02 11:07 Brad King Status new => resolved
2014-09-02 11:07 Brad King Resolution open => fixed
2014-09-02 11:07 Brad King Fixed in Version => CMake 3.1
2015-03-02 08:57 Robert Maynard Note Added: 0038111
2015-03-02 08:57 Robert Maynard Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team