Packages dependency and includes

asked 2016-09-13 05:34:04 -0500

955 ●67 ●83 ●98

updated 2016-09-14 01:28:25 -0500

Hi all,

I have a package1 which generates services via a Type1.srv file. These generated services are located in <catkin_ws>/devel/include/package1/Type1.h. This all works fine.

Now when I want a package2 to also use the services generated in package1 I follow the steps described in here.

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

When I manually add include path <catkin_ws>/devel/include to include_directories, it compiles and links fine, but it is obviously very dirty...

Anyone knows what I am missing here? How can I let my system know about the include path to devel?

-------------------EDIT 1---------------

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.

-------------------EDIT 2---------------

File package1/package.xml does exist and has the following name

<package format="2">
  <name>package1</name>
  <version>0.1.0</version>

package1/CMakeLists.txt contains

project(package1)

...

catkin_package(
    LIBRARIES ${PROJECT_NAME}
    CATKIN_DEPENDS rtt_ros message_runtime std_msgs
)

and package2/CMakeLists.txt contains

find_package(catkin REQUIRED COMPONENTS roscpp std_msgs package1)

This causes the error described above.

-------------------EDIT 3---------------

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.

Does this MWE shed some more light on the problem?

Kind regards,

Antoine.

edit retag flag offensive close merge delete

add a comment

answered 2016-09-13 06:15:23 -0500

gvdhoorn
86574 ●283 ●1432 ●1054 http://cor.tudelft.nl/

updated 2016-09-14 12:49:00 -0500

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 ... (more)

edit flag offensive delete link

Comments

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.

arennuit ( 2016-09-13 07:42:47 -0500 )edit

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.

arennuit ( 2016-09-13 12:57:33 -0500 )edit

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.

gvdhoorn ( 2016-09-13 13:22:10 -0500 )edit

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).

arennuit ( 2016-09-14 03:20:23 -0500 )edit

... and it turns out that lc_control and lc_toolkitLink are already both in a metapackage (called le_painters_companion).

arennuit ( 2016-09-14 03:24:22 -0500 )edit

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.

arennuit ( 2016-09-19 11:27:59 -0500 )edit

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().

arennuit ( 2016-09-19 11:30:29 -0500 )edit

[..] 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.

gvdhoorn ( 2016-09-19 12:13:20 -0500 )edit

add a comment

Packages dependency and includes

1 Answer

Comments

Question Tools

Stats

Related questions

Packages dependency and includes edit

1 Answer

Comments

Question Tools

Stats

Related questions

Packages dependency and includes