| View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0013233 | CMake | CMake | public | 2012-05-17 08:44 | 2016-06-10 14:31 | ||||
| Reporter | Mathieu Malaterre | ||||||||
| Assigned To | Kitware Robot | ||||||||
| Priority | normal | Severity | minor | Reproducibility | have not tried | ||||
| Status | closed | Resolution | moved | ||||||
| Platform | OS | OS Version | |||||||
| Product Version | CMake 2.8.8 | ||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0013233: Teach find_library to optionally report only library name | ||||||||
| Description | Quoting 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. | ||||||||
| Additional Information | ref: http://bugs.debian.org/672729#27 [^] | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files | |||||||||
| Relationships | |
| Relationships |
| Notes | |
|
(0029511) Alex Neundorf (developer) 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 (manager) 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 (administrator) 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. |
| Notes |
| Issue History | |||
| Date Modified | Username | Field | Change |
| 2012-05-17 08:44 | Mathieu Malaterre | New Issue | |
| 2012-05-17 08:50 | Brad King | Assigned To | => Brad King |
| 2012-05-17 08:50 | Brad King | Status | new => backlog |
| 2012-05-17 08:50 | Brad King | Summary | add new behavior for find_library => Teach find_library to optionally report only library name |
| 2012-05-17 09:10 | Brad King | Assigned To | Brad King => |
| 2012-05-20 05:46 | Alex Neundorf | Note Added: 0029511 | |
| 2012-05-21 08:05 | Brad King | Note Added: 0029516 | |
| 2016-06-10 14:28 | Kitware Robot | Note Added: 0042049 | |
| 2016-06-10 14:28 | Kitware Robot | Status | backlog => resolved |
| 2016-06-10 14:28 | Kitware Robot | Resolution | open => moved |
| 2016-06-10 14:28 | Kitware Robot | Assigned To | => Kitware Robot |
| 2016-06-10 14:31 | Kitware Robot | Status | resolved => closed |
| Issue History |
| Copyright © 2000 - 2018 MantisBT Team |