Bug #1338
Wrong prefix in pkg-config files of the debian packages
Status: | Resolved | Start date: | 01/17/2013 | |
---|---|---|---|---|
Priority: | High | Due date: | ||
Assignee: | J. Wienke | % Done: | 100% | |
Category: | cmake | |||
Target version: | Robotics Service Bus - rsb-0.9 |
Description
The .pc
files incorrectly define the prefix and pathes to be in /usr/local
, where infact it should be /usr/
, where everything is installed to. The wrong .pc
file looks like:
prefix=/usr/local libdir=${prefix}/lib ...
This seems to be a cmake/cpack glitch, since we use the variable CMAKE_INSTALL_PREFIX
to configure this pkg-config file, but cpack just sets CPACK_INSTALL_PREFIX
(note: CPACK_
instead of CMAKE_
), see CMake-CPack Package Installation Path Nightmare (the solutions suggested in the comments don't work for me).
Associated revisions
Fixed prefix path in package config file
- CPack now sets CMAKE_INSTALL_PREFIX to its own CPACK_INSTALL_PREFIX
- This has to happen before config file confoiguration
- CPACK_INSTALL_PREFIX is /usr/local by default but can be set through cmake
fixes #1338
Backport: Fixed prefix path in package config file
refs #1338
History
#1 Updated by Anonymous over 11 years ago
- Target version changed from 0.7 to rsb-0.9
I report this in trunk, but it will have to be back-ported to 0.7 also.
#2 Updated by Anonymous over 11 years ago
- File cpack-prefix.patch added
Adding the following lines to the CPackDebianConfig.cmake
will do the trick:
#set(CPACK_INSTALL_PREFIX "/usr") set(CPACK_SET_DESTDIR On) set(CMAKE_INSTALL_PREFIX ${CPACK_INSTALL_PREFIX})
under the condition, that the CPack stuff happens before the config files configuration (so that setting CMAKE_INSTALL_PREFIX
can take effect in these files), see attached patch.
This will create valid packages and config files, but without explicitly setting CPACK_INSTALL_PREFIX
, content will then be installed in /usr/local
instead of /usr
. CPACK_INSTALL_PREFIX
can be set either right inside our CPackDebianConfig.cmake
or from outside in our ci job configuration.
This is all still a bit fuzzy, since documentation of this matter ist mainly through bug reports and work-arounds not through actual documentation. The fact, that this solution depends on the order of configuration is not so nice. But at least explicitly configuring the CPACK_INSTALL_PREFIX
doesn't seem to be a too bad idea.
Any opinions?
#3 Updated by J. Wienke over 11 years ago
I am not specifically happy about moving the place where the package file is included around. For the next bug fix it needs to be moved down again and so on. But if there is no other chance we should do it like this.
#4 Updated by Anonymous over 11 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
Applied in changeset rsc|commit:feab1daa5b6ce27b46cb37d339de08d08bbd56c9.