MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015643CMakeCMakepublic2015-07-08 14:492016-06-10 14:31
ReporterStephen Kelly 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionmoved 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0015643: Control includes order of project being configured
Description
A buildsystem can contain

 target_link_libraries(foo PRIVATE
  Vendor1::Dep
  Vendor2::OtherDep
 )

I might have otherdep installed in /opt, such that

 /opt/otherdep/include/otherdep.h

exists.

The 'dep' dependency might be provided in /usr or /usr/local.

I can run cmake with various settings such as CMAKE_PREFIX_PATH or OtherDep_DIR to find otherdep in the correct location. The 'foo' target will be compiled with

 -I/opt/otherdep/include

However, if otherdep headers are also installed in /usr or /usr/local, that -I path will not be used to find the headers, and 'foo' will be miscompiled.

There is no generic solution to this. If upstream changes the order of the IMPORTED targets, downstreams with 'dep' in /opt will have the problem instead.

This problem is more-common on platforms with package managers which do not split headers into -devel packages, and when using a mixture of libraries which are commonly installed though the package manager (such as Qt), and libraries which are installed outside the package manager using vendor supplied packages (such as Qt). It can be reproduced by installing devel packages on linux too.

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/52883/focus=52895 [^]

Perhaps a variable could be introduced to set priority of IMPORTED targets when running cmake. This is an issue local to each actor building the project.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-07-08 14:49Stephen KellyNew Issue
2015-07-08 14:56Brad KingNote Added: 0039097
2015-07-08 14:56Brad KingNote Edited: 0039097bug_revision_view_page.php?bugnote_id=39097#r1837
2015-07-08 16:17Stephen KellyNote Added: 0039098
2016-06-10 14:29Kitware RobotNote Added: 0042805
2016-06-10 14:29Kitware RobotStatusnew => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:29Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0039097)
Brad King   
2015-07-08 14:56   
IIRC we discussed this back when first designing usage requirements and decided that the consuming project could just do

 target_include_directories(mytgt PRIVATE $<TARGET_PROPERTY:target-needed-first,INTERFACE_INCLUDE_DIRECTORIES>)

to re-order includes when needed. That is as far as we got AFAIK.
(0039098)
Stephen Kelly   
2015-07-08 16:17   
RE 0015643:0039097: That is useful if there is a specific target which is needed first, which should be hardcoded in the buildsystem, such as if the mytgt project has a file of the same name as something from from an upstream.

This bug isn't about that. This is about the case when the user running cmake on the mytgt project happens to have particular files in particular prefixes. There is no upstreamable patch to the buildsystem in that case.
(0042805)
Kitware Robot   
2016-06-10 14:29   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.