|
Notes |
|
|
(0032703)
|
|
Brad King
|
|
2013-03-26 10:25
|
|
CMAKE_FIND_ROOT_PATH is only about the find_* commands. Once found these files should be loaded by their real full path. The tested files should exist at these full paths.
Please provide a complete minimal example demonstrating the issue. We need a sample project that installs the package config files and one that loads them and gets errors. |
|
|
|
(0032708)
|
|
Matthieu Gallien
|
|
2013-03-27 10:49
|
|
My point is that the find command will locate the config file prepending CMAKE_FIND_ROOT_PATH paths. The config file will be executed and will try to locate files without prepending the same variable. This will fail because I am doing cross compilation. The root path of the system is not / but some path a. The path in the config file is relative to the path a. For example, in my case a library is located /a/usr but the config file says it is located in /usr.
I will try my best o provide you quickly with an example that shows how to reproduce.
Maybe a better patch would be to not use if(NOT EXISTS ...) but to use FIND_FILE ? |
|
|
|
(0032709)
|
|
Brad King
|
|
2013-03-27 11:02
|
|
Re 0014041:0032708: The main purpose of a package config file is to *know* where the rest of the package files are located. It shouldn't have to do any searching (unlike a find-module which must search because it doesn't come with the package).
Is the following correct?
You have a package that was built for another machine and at runtime on that other machine will be installed in /usr, and so has paths hard-coded for that. On the host machine it is in /a/usr so the full paths don't resolve without prepending /a.
Did this work with CMake 2.8.10? |
|
|
|
(0032736)
|
|
Brad King
|
|
2013-04-01 10:20
|
|
|
|
|
(0032743)
|
|
Matthieu Gallien
|
|
2013-04-02 17:00
|
|
The steps to reproduce.
1) create a project1 directory with CMakeLists.txt, project1.cpp, project1.h and project1Config.cmake.in (renammed from project1Config-2.cmake.in)
2) create a build directory and call cmake .. -DCMAKE_INSTALL_PREFIX=/usr
3) call make install DESTDIR=/some/path
4) create a project2 directory with CMakeLists.txt (renammed from CMakeLists-2.txt) and project2.cpp
5) create a build directory and call cmake .. -DCMAKE_FIND_ROOT_PATH=/some/path -DCMAKE_INSTALL_PREFIX=/usr |
|
|
|
(0032744)
|
|
Matthieu Gallien
|
|
2013-04-02 17:09
|
|
Using cmake 2.8.10.2 tag allows one to configure the second project without errors.
Using cmake 2.8.10.20130321 allows one to reproduce my problem. |
|
|
|
(0032745)
|
|
Brad King
|
|
2013-04-02 17:10
|
|
Re 0014041:0032743: DESTDIR is for installation during packaging. It is expected that the package will be extracted such that the files appear at their intended prefix before being used.
The value of CMAKE_INSTALL_PREFIX should be the actual location of the files when they are to be loaded. Build with -DCMAKE_INSTALL_PREFIX=/some/path/usr instead. |
|
|
|
(0032746)
|
|
Matthieu Gallien
|
|
2013-04-02 17:16
|
|
DESTDIR is what is used to build the package with oe-core and it is also what I had found more convenient to reproduce my problem. The fact is that CMAKE_INSTALL_PREFIX has to be /usr because it will really be /usr chen deployed on the target. On the development system, the development package is deployed under some prefix. This is what I was willing to simulate with DESTDIR. I could have used a mv directly.
The location of the config file is ${CMAKE_FIND_ROOT_PATH}/${CMAKE_INSTALL_PREFIX} on my development system and ${CMAKE_INSTALL_PREFIX} on my target system. |
|
|
|
(0032747)
|
|
Brad King
|
2013-04-03 08:10
(edited on: 2013-04-03 08:11) |
|
Re 0014041:0032746: Lots of projects hard-code paths to their installation prefix instead of being relocatable. How are they used in a cross-compiling scenario like this?
A lot of care went into making CMake-generated packages relocatable by computing locations relative to the package file locations. Unfortunately it is not safe to evaluate such relative paths in the presence of cross-prefix symlinks like "/lib -> /usr/lib" as is done by usr-move Linux distros. The changes mentioned in 0014041:0032736 add a special case for system-located install prefixes to switch to hard-coded full paths under the assumption that such prefixes will only be used for non-relocatable system packages.
As stated in 0014041:0032709 the entire point of package config files and target files created by install(EXPORT) is to know *exactly* where to find the rest of the package. It is not acceptable to do any searching. In your use case this requirement is in direct conflict with the usr-move changes mentioned above, so we may need another solution to that problem.
|
|
|
|
(0032750)
|
|
Brad King
|
|
2013-04-03 11:27
|
|
|
|
|
(0032753)
|
|
Matthieu Gallien
|
|
2013-04-03 15:59
|
|
It works fine with your commit.
Thanks for your help. |
|
|
|
(0034025)
|
|
Robert Maynard
|
|
2013-10-07 10:04
|
|
|
Closing resolved issues that have not been updated in more than 4 months. |
|
0001-takes-into-account-CMAKE_FIND_ROOT_PATH-when-checkin.patch (3,090) 2013-03-26 09:56
project1Config.cmake.in (446) 2013-04-02 16:16
project1.cpp (52) 2013-04-02 16:18