At work, we have a stack built in ROS, with CMakeLists.txt files in each package. I'm trying to switch to the catkin build tool, which requires that every package be able to build isolated from the others. A file structure looks like:
base:
CMakeLists.txt
-- package1:
[files]
CMakeLists.txt
-- package2:
[files]
CMakeLists.txt
The previous build tool (catkin_make) started at a root source directory and then adds all discovered CMakeLists.txt files as sub-directories. This means that variables set in the base (or further down the line) persist.
The big issue I'm running into is that we have some test config scripts that get loaded and run for each package. You can find them from the base file along the path ${CMAKE_SOURCE_DIR}/path/to/file. For all of the sub-directories, this path still works because CMAKE_SOURCE_DIR is pointed at the root. There are a lot of settings in the root CMakeLists.txt like compiler settings and flags, along with configuration information for IDE's and especially the paths to these test files.
When making everything independent, I added INCLUDE(../CMakeLists.txt) in each sub-directory to get to this file. However, when I do this, I then also need to change the line in the root CMakeLists.txt to be a hard-coded path like so:
${CMAKE_SOURCE_DIR}/path/to/file --> ~/hard/coded/path/to/file
This is because CMAKE_SOURCE_DIR changes to become the directory of each package, and so I cannot start from there.
Since there are obviously major drawbacks to hardcoding (this doesn't even work on the hardware because the file structure is much different), how can I resolve this? A variable that defined something like CMAKE_DIR_OF_THE_FILE_WHERE_THIS_LINE_IS but I doubt that exists. I could also go through and move the test script include lines into each package CMakeLists.txt so they are completely independent. I would still get the benefit of all the settings from the root file but then it is on developers to update the test script lines in any packages they work on. But this means if we move/rename the test scripts, then there are many places to fix (which is doable with a big find and replace).
