Note that in my code I do not actually add package1 to find_package, because package1 is not compiled yet when find_package is called in package2.
Now when building I get the following error:
<catkin_ws>/src/package2/src/MyFile.cpp:2:32: fatal error: package1/Type1.h: No such file or directory
I thought that the path to <catkin_ws>/devel/include/package1/Type1.h would be provided as an include by the dependency set in package2's package.xml file, no?
Indeed: no.
I thought this was actually explained in one of your earlier questions (CMakeLists.txt vs package.xml), but just to reiterate: package.xml (where you put the build_depend) and CMakeLists.txt (find_package(..) and friends) are two separate things.
The former is used by (meta-)package managers (such as rosdep, but ultimately apt, dfn and others) to understand how your package relates to all others (in terms of dependencies, ie: which pkgs should be on the system, separated out into two sets: 'when running' and 'when compiling'), while the latter is a codification of the actual process to follow when converting your sources into binary artefacts (ie: compiling into objects and executable binaries).
In other words: how would the compiler know about package1 if you don't add it to package2's INCLUDE_PATH etc? That is CMakeLists.txt's task (via find_package(..)), and you deliberately left that out of there.
Compilation order is (partially) determined by the contents of the find_package(..) calls, so:
Note that in my code I do not actually add package1 to find_package, because package1 is not compiled yet when find_package is called in package2.
is a bit of strange statement, as I hope you understand now.
Edit:
I thought that the path to <catkin_ws>/devel/include/package1/Type1.h would be provided as an include by the dependency set in catkin_package, via the CATKIN_DEPENDS keyword, no?
Not if you don't find_package(catkin COMPONENTS .. package1 ..) in package2's CMakeLists.txt.
Though when I do use catkin_package / CATKIN_DEPENDS to indicate the dependency on package1, I have no more luck.
No, because listing package1 under CATKIN_DEPENDS only causes the catkin_package(..) call to configure the build system to generate a PkgConfig (.pc) file for package2 that states the dependency on package1. It does not update the compilation process with any new information regarding the location of package1.
(well, actually it will try to, as the PkgConfig file will need the same set of information, but since you don't find_package(.. package1 ..) anywhere, the variables need will most likely be empty).
CMakeLists.txt in package2 does not explicitly import package1, so even if package1 exports something, package2 won't know about it.
Additionally, I would expect ${catkin_INCLUDE_DIRS}** to include the path to **<catkin_ws>/devel/include/package1/Type1.h**, but **${catkin_INCLUDE_DIRS} only contains the path to ros core installation.
Which makes sense, as you don't find_package(catkin COMPONENTS .. package1 ..) in package2's CMakeLists.txt.
Without an explicit find_package(.. package1 ..) somewhere in the CMakeLists.txt of package2, nothing you do in package1 will be picked up by any of the build activities undertaken by the build tool that builds package2.
Edit2:
Note that when I add package1 to find_package(catkin REQUIRED COMPONENTS ... package1) I get the following error:
CMake Error at /opt/ros/indigo/share/catkin/cmake/catkinConfig.cmake:83 (find_package): Could not find a package configuration file provided by "package1" with any of the following names:
package1Config.cmake
package1-config.cmake
Add the installation prefix of "package1" to CMAKE_PREFIX_PATH or set "package1_DIR" to a directory containing one of the above files. If "package1" provides a separate development package or SDK, be sure it has been installed.
(after all the edits, it's no longer visible, but I feel as if the original question was a good example of an xy-problem)
The first thing to check is that a file package1/package.xml actually exists. If that is the case, check the package name. Make sure it corresponds to the one you add to find_package(..) (in package2) and to catkin_package() (in package1).
Edit3:
I have created a MWE which can be found in this link. Both packages are in meta-package le_painters_companion, package1 corresponds to lc_control and package2 to lc_toolkitLink.
If I understand you correctly, you have both package1 and package2 in the directory of the lc_control metapackage? I'm not sure that is supposed to work. Could you please try flattening your workspace? So make package1 and package2 siblings of your metapackage.
No, this is not correct. I was confused by you using the name meta-package for a directory containing other packages. I typically reserve that name for actual metapackages.
Does this MWE shed some more light on the problem?
No, not really. It wasn't an actual MWE, as it is still full of project-specific CMake statements and paths.
It's hard for me to test, but by commenting out all the orocos_component(..) calls (and related lines), I can get a sample workspace containing your two packages to build just fine. With lc_control listed in both find_package(catkin .. COMPONENTS .. lc_control) and in catkin_package(.. CATKIN_DEPENDS .. lc_control).
The CMakeLists.txt of both packages are actually quite convoluted. Perhaps it would help if you stripped them completely (comment almost everything), have just the bare Catkin skeleton in there, then try to build your workspace. See if lc_toolkitLink can find lc_control. Then start re-enabling the orocos and other bits. I suspect that at some point things will break.
Additionally: I assume you've already removed your build and devel directories and rebuild everything from scratch?
Originally posted by gvdhoorn with karma: 86574 on 2016-09-13
This answer was ACCEPTED on the original site
Post score: 1
Original comments
Comment by arennuit on 2016-09-13:
You are right, my comment on package.xml is useless. I have updated the post accordingly and added an update to provide more details on why I did not add package1 to find_package. Although my problem is not solved yet, it looks like you are pointing towards the right direction.
Comment by arennuit on 2016-09-13:
I believe you are right about the xy problem (I have tried to narrow things down now, so the post is useful for later use to others). I have added a 2nd edit to give some more information.
Comment by gvdhoorn on 2016-09-13:
Something is not right here. If you can, try and create an MWE, or provide access to both packages somehow. We don't need the sources (they can be empty), but it would help to see the complete package.xml and CMakeLists.txt of both packages, and the directory layout as well.
Comment by arennuit on 2016-09-14:
Hello gvdhoorn, I believe your edit3 is wrong: package1 and package2 are actually dummy names used to make the post as generic as possible. Their real name (in the MWE) are lc_control (for package1 and lc_toolkitLink (for package2).
Comment by arennuit on 2016-09-14:
... and it turns out that lc_control and lc_toolkitLink are already both in a metapackage (called le_painters_companion).
Comment by arennuit on 2016-09-19:
Hello gvdhoorn, using the stripe down technique you suggested and hours of analysis I have been able to solve the problem described in my post. There are still problems to my build though whiich are very closely linked, but I believe they deserve another post. Thanks for your help.
Comment by arennuit on 2016-09-19:
Note that the problem arouse because, in package1, the name of the produced library was not the name of the project package1, hence I was not allowed to use LIBRARY ${PROJECT_NAME} in catkin_package().
Comment by gvdhoorn on 2016-09-19:\
[..] and hours of analysis [..]
I'm sorry to hear that.
I have been able to solve the problem described in my post
Glad to hear that you got to the bottom of it though.
