View Issue Details [ Jump to Notes ] [ Print ]
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.
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0039097)
Brad King (manager)
2015-07-08 14:56
edited on: 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 (developer)
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 (administrator)
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.

 Issue History
Date Modified Username Field Change
2015-07-08 14:49 Stephen Kelly New Issue
2015-07-08 14:56 Brad King Note Added: 0039097
2015-07-08 14:56 Brad King Note Edited: 0039097
2015-07-08 16:17 Stephen Kelly Note Added: 0039098
2016-06-10 14:29 Kitware Robot Note Added: 0042805
2016-06-10 14:29 Kitware Robot Status new => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:29 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team