Revision history [back]

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 feel 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) to understand how your package relates to all others (in terms of dependencies, ie: which pkgs should be on the system, separated out into a 'when running' and a 'when compiling' set), 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, and you deliberately left it out of there.

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 ~~feel~~ 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) to understand how your package relates to all others (in terms of dependencies, ie: which pkgs should be on the system, separated out into a two sets: 'when running' and a 'when ~~compiling' set),~~ 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, and you deliberately left it out of there.

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) 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,~~ task (via find_package(..)), and you deliberately left it 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.

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.

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

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.

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.

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.

6
No.6 Revision

updated 2016-09-13 08:06:24 -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 in package1 will be picked up by any of the build activities undertaken by the build tool that builds package2.

7
No.7 Revision

updated 2016-09-13 08:28:52 -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 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).

8
No.8 Revision

updated 2016-09-13 08:30:42 -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 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).

9
No.9 Revision

updated 2016-09-14 02:50:56 -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 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.

10
No.10 Revision

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 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?