Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
make installed code relocatable #490
Installed code should not (or as few as possible) contain absolute path information. Currently a lot of code contains the
One goal would be to compile a workspace with
The following things need to be updated to not use absolute paths:
Changes required in other packages:
All patches are committed to the
referenced this issue
Jul 27, 2013
@dirk-thomas I have test the patches and they work. Nevertheless I would proposed to replace
I am glad to hear that it works for your use case.
Regarding the variable: this variable should not be overwritten - not even for cross compilation. If a package requires compiled binaries to build itself / downstream stuff it needs to reference that using a separate variable pointing to a different directory. E.g. in the case where a package uses both (a Python script as well as a compiled binary) to build downstream stuff it will not have both of the executables in the same directory anyway.
Each package should consciously deal with this in its CMake extra file. catkin should not try to populate any package-specific variables. For the source/devel space catkin would not even be able to set a reasonable directory since it just does not know where the binaries in the package are.
In that case the binaries need to use the find_binary function to get the real path of the binary.
As the long time goal it would be nice if catkin and the CMake extra files always use the find_binary function to get the real path of all executed scripts and binaries. This enables the cross build environment to use all binaries and as well scripts from the native system root if it doesn't install any binaries and scripts into the cross system root.
For packages which do not generate compiled binaries it can stay the way as it is with these patches. I don't see a reason to change that even in the long term.
For compiled binaries we should indeed use the find_* CMake functions. But that should handled by the first package which actually requires that. Currently no (wet) package requires compiled binaries during the build (as far as I know) and that was an important goal of the new buildsystem.
I will go ahead and merge all above mentioned patches. Releases for the separate packages will follow when ever each package has "enough" changes accumulated.
As long as the build machine (native system root) and cross compiled machine (cross system root) use the same python version it doesn't matter which python script is used and its a design decision.
@dirk-thomas thanks for your work. We will update our recipes in meta-ros after you have apply the different patches.