MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013233CMakeCMakepublic2012-05-17 08:442016-06-10 14:31
ReporterMathieu Malaterre 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake 2.8.8 
Target VersionFixed in Version 
Summary0013233: Teach find_library to optionally report only library name
DescriptionQuoting Brad's suggestion:

CMake's design assumes that the dependencies don't move after a project
is built. If one of VTK's dependencies is rebuilt and puts a library
in a new location, VTK could be rebuilt to know about the new location.
I guess Debian's packages can be rebuilt without rebuilding all their
dependents so long as the ABI is compatible. This is necessary for a
sane update path for clients because otherwise if one low-level library
is rebuilt for a bugfix then the entire system would have to be updated.

A solution on the CMake side would be to (optionally) change the
behavior of find_library. Currently it reports the full path to a
library, but when that full path is inside an implicit linker search
path the generated link line ends up with the -l form anyway. We could
teach find_library to optionally report the library by only its name
if the full path found is in an implicit search path. If the behavior
were controlled by a global setting then that setting could simply be
added as a -D argument in Debian package build rules.
Steps To Reproduce
Additional Informationref: http://bugs.debian.org/672729#27 [^]
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-05-17 08:44Mathieu MalaterreNew Issue
2012-05-17 08:50Brad KingAssigned To => Brad King
2012-05-17 08:50Brad KingStatusnew => backlog
2012-05-17 08:50Brad KingSummaryadd new behavior for find_library => Teach find_library to optionally report only library name
2012-05-17 09:10Brad KingAssigned ToBrad King =>
2012-05-20 05:46Alex NeundorfNote Added: 0029511
2012-05-21 08:05Brad KingNote Added: 0029516
2016-06-10 14:28Kitware RobotNote Added: 0042049
2016-06-10 14:28Kitware RobotStatusbacklog => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:28Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0029511)
Alex Neundorf   
2012-05-20 05:46   
Is this a problem with the exported targets and which libraries they depend on ?

This is no problem anymore when those libraries it depends on were imported target themselves.
Then they end up as imported targets in the exported targets files, and must be found again when the exported targets are imported again.

Or is it a RPATH problem ?
(0029516)
Brad King   
2012-05-21 08:05   
The problem is that the libraries on which the exported targets depend *MOVE* due to updates to other packages (multiarch-ification). The full paths to the old locations are left behind in the targets file of an existing package. Then CMake-generated build rules of a dependent package complain that the files do not exist. Since this is all for libraries in system directories it is simpler to just list them by name.
(0042049)
Kitware Robot   
2016-06-10 14:28   
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.