Revision history [back]

For a package all the link-time and run-time dependencies are already described inside the CMakeLists.txt, so why do we need to re-state these dependencies inside the package.xml?

First: CMakeLists.txt is a build script, it does not explicitly express the run dependencies of the targets that get built. Yes, it's likely that you'll need at least the (dynamic) libraries that you linked to, but that doesn't tell you where those libraries can be found. Also, some libraries are header only and will not be needed any more after compilation. CMake has no system in place to express that kind of information.

The wiki/catkin/CMakeLists.txt page, under the Finding Dependent CMake Packages section also hints at this:

NB: You should only find_package components for which you want build flags. You should not add runtime dependencies.

package.xml contains meta-data (in addition to the dependency declarations you identified): things not necessarily needed for building (or even running) a package, but still nice to have around in a central place. Examples would be author, maintainer, url, description and license. These are used on the ROS wiki, and are displayed on a page that uses the PackageHeader(..) macro. See REP-127 for more info.

Firstly the information seems redundant and secondly when is the information inside package.xml used? What is it used for?

Where CMakeLists.txt and package.xml seem to overlap, is the declaration of build, run and test dependencies. The thing to understand though, is that a 1-to-1 relationship between things you need to build and things you need to run does not necessarily exist. In addition, it could very well be that libfoo.so is shipped on platform X in package Bar, but is only found by using the FindMyBarLibrary.cmake file (which the author unfortunately didn't name after libfoo.so or Bar). Or it could be that Bar actually consists of a number of libraries each with their own find scripts, which do not easily map to the name of the package.

Because of this, systems like the ROS buildfarm require extra (and more machine readable) readable) information to be able to install all the right dependencies while setting up a working build environment. And - after a successful build - to correctly list all *runrun dependencies in the debians (or RPMs on Fedora) that you install using apt-get. That is where package.xml comes in.

Another important benefit of having that information in a format other than a build script is that it allows a certain amount of abstraction, making cross-platform support easier. For some more comments on that, please see why rosdep instead of others?.

For a package all the link-time and run-time dependencies are already described inside the CMakeLists.txt, so why do we need to re-state these dependencies inside the package.xml?

First: CMakeLists.txt is a build script, it does not explicitly express the run dependencies of the targets that get built. Yes, it's likely that you'll need at least the (dynamic) libraries that you linked to, but that doesn't tell you where those libraries can be found. Also, some libraries are header only and will not be needed any more after compilation. CMake has no system in place to express that kind of information.

The wiki/catkin/CMakeLists.txt page, under the Finding Dependent CMake Packages section also hints at this:

NB: You should only find_package components for which you want build flags. You should not add runtime dependencies.

package.xml contains meta-data (in addition to the dependency declarations you identified): things not necessarily needed for building (or even running) a package, but still nice to have around in a central place. Examples would be author, maintainer, url, description and license. These are used on the ROS wiki, and are displayed on a page that uses the PackageHeader(..) macro. See REP-127 for more info.

Firstly the information seems redundant and secondly when is the information inside package.xml used? What is it used for?

Where CMakeLists.txt and package.xml seem to overlap, is the declaration of build, run and test dependencies. The thing to understand though, is that a 1-to-1 relationship between things you need to build and things you need to run does not necessarily exist. In addition, This, coupled with the fact that the CMake language is a rather complex language to parse (because of branching, conditional includes, macros, functions, etc), no standardised naming scheme for files, libraries or their distribution archives, differences between platforms and coding styles, makes it could all very well be that libfoo.so is shipped on platform X in package Bar, but is only found by using the FindMyBarLibrary.cmake file (which the author unfortunately didn't name after libfoo.so or Bar). Or it could be that Bar actually consists of a number of libraries each with their own find scripts, which do not easily map to the name of the package.hard to reliably extract the necessary information from build scripts alone (CMakeLists.txt).

Because of this, systems like the ROS buildfarm require extra (and more machine readable) information to be able to install all the right dependencies while setting up a working build environment. And - after a successful build - to correctly list all run dependencies in the debians (or RPMs on Fedora) that you install using apt-get. That is where package.xml comes in.

Another important benefit of having that information in a format other than a build script is that it allows a certain amount of abstraction, making cross-platform support easier. For some more comments on that, please see why rosdep instead of others?.

tl;dr: compare the CMakeLists.txt / package.xml situation with GNU Makefiles / Debian control files: both (partly) contain the same information, but neither covers everything needed to be able to successfully build packages. To facilitate automated build systems and information extraction, machine readable file formats are highly preferable to the complex dynamic constructs allowed in most build scripts. Additionally, dependency declaration and resolution can benefit from a slightly higher level of abstraction, especially when dealing with from-source builds on multiple different platforms and OSs.

longer:

For a package all the link-time and run-time dependencies are already described inside the CMakeLists.txt, so why do we need to re-state these dependencies inside the package.xml?

First: CMakeLists.txt is a build script, it does not explicitly express the run dependencies of the targets that get built. Yes, it's likely that you'll need at least the (dynamic) libraries that you linked to, but that doesn't tell you where those libraries can be found. Also, some libraries are header only and will not be needed any more after compilation. CMake has no system in place to express that kind of information.

The wiki/catkin/CMakeLists.txt page, under the Finding Dependent CMake Packages section also hints at this:

NB: You should only find_package components for which you want build flags. You should not add runtime dependencies.

package.xml contains meta-data (in addition to the dependency declarations you identified): things not necessarily needed for building (or even running) a package, but still nice to have around in a central place. Examples would be author, maintainer, url, description and license. These are used on the ROS wiki, and are displayed on a page that uses the PackageHeader(..) macro. See REP-127 for more info.

Firstly the information seems redundant and secondly when is the information inside package.xml used? What is it used for?

Where CMakeLists.txt and package.xml seem to overlap, is the declaration of build, run and test dependencies. The thing to understand though, is that a 1-to-1 relationship between things you need to build and things you need to run does not necessarily exist. This, This - coupled with the fact that the CMake language is a rather complex language to parse (because of branching, conditional includes, macros, functions, etc), no standardised naming scheme for files, libraries or their distribution archives, differences between platforms and coding styles, styles - makes it all very hard to reliably extract the necessary information from build scripts alone (CMakeLists.txt).alone.

Because of this, systems like the ROS buildfarm require extra (and more machine readable) information to be able to install all the right dependencies while setting up a working build environment. And - after a successful build - to correctly list all run dependencies in the debians (or RPMs on Fedora) that you install using apt-get. That is where package.xml comes in.

Another important benefit of having that information in a format other than a build script is that it allows a certain amount of abstraction, making cross-platform support easier. For some more comments on that, please see why rosdep instead of others?.

Edit: clarified why a machine readable file format are highly preferable to parsing complex, dynamic CMake build scripts.

tl;dr: compare the CMakeLists.txt / package.xml situation with GNU Makefiles / Debian control files: both (partly) contain the same information, but neither covers everything needed to be able to successfully build packages. To facilitate automated build systems and information extraction, machine readable file formats are highly preferable to the complex dynamic constructs allowed in most build scripts. Additionally, dependency declaration and resolution can benefit from a slightly higher level of abstraction, especially when dealing with from-source builds on multiple different platforms and OSs.

longer:

For a package all the link-time and run-time dependencies are already described inside the CMakeLists.txt, so why do we need to re-state these dependencies inside the package.xml?

First: CMakeLists.txt is a build script, it does not explicitly express the run dependencies of the targets that get built. Yes, it's likely that you'll need at least the (dynamic) libraries that you linked to, but that doesn't tell you where those libraries can be found. Also, some libraries are header only and will not be needed any more after compilation. CMake has no system in place to express that kind of information.

The wiki/catkin/CMakeLists.txt page, under the Finding Dependent CMake Packages section also hints at this:

NB: You should only find_package components for which you want build flags. You should not add runtime dependencies.

package.xml contains meta-data (in addition to the dependency declarations you identified): things not necessarily needed for building (or even running) a package, but still nice to have around in a central place. Examples would be author, maintainer, url, description and license. These are used on the ROS wiki, and are displayed on a page that uses the PackageHeader(..) macro. See REP-127 for more info.

Firstly the information seems redundant and secondly when is the information inside package.xml used? What is it used for?

Where CMakeLists.txt and package.xml seem to overlap, is the declaration of build, run and test dependencies. The thing to understand though, is that a 1-to-1 relationship between things you need to build and things you need to run does not necessarily exist. This - coupled with the fact that the CMake language is a rather complex language to parse (because of branching, conditional includes, macros, functions, etc), no standardised naming scheme for files, libraries or their distribution archives, differences between platforms and coding styles - makes it all very hard to reliably extract the necessary information from build scripts alone.

Because of this, systems like the ROS buildfarm require extra (and more machine readable) information to be able to install all the right dependencies while setting up a working build environment. And - after a successful build - to correctly list all run dependencies in the debians (or RPMs on Fedora) that you install using apt-get. That is where package.xml comes in.

Another important benefit of having that information in a format other than a build script is that it allows a certain amount of abstraction, making cross-platform support easier. For some more comments on that, please see why rosdep instead of others?.

Edit: clarified why a machine readable file format are is highly preferable to parsing complex, dynamic CMake build scripts.

tl;dr: compare the CMakeLists.txt / package.xml situation with GNU Makefiles / Debian control files: both (partly) contain the same information, but neither covers everything needed to be able to successfully build packages. To facilitate automated build systems and information extraction, machine readable file formats are highly preferable to the complex dynamic constructs allowed in most build scripts. Additionally, dependency declaration and resolution can benefit from a slightly higher level of abstraction, especially when dealing with from-source builds on multiple different platforms and OSs.

longer:

For a package all the link-time and run-time dependencies are already described inside the CMakeLists.txt, so why do we need to re-state these dependencies inside the package.xml?

First: CMakeLists.txt is a build script, it does not explicitly express the run dependencies of the targets that get built. Yes, it's likely that you'll need at least the (dynamic) libraries that you linked to, but that doesn't tell you where those libraries can be found. Also, some libraries are header only and will not be needed any more after compilation. CMake has no system in place to express that kind of information.

The wiki/catkin/CMakeLists.txt page, under the Finding Dependent CMake Packages section also hints at this:

NB: You should only find_package components for which you want build flags. You should not add runtime dependencies.

package.xml contains meta-data (in addition to the dependency declarations you identified): things not necessarily needed for building (or even running) a package, but still nice to have around in a central place. Examples would be author, maintainer, url, description and license. These are used on the ROS wiki, and are displayed on a page that uses the PackageHeader(..) macro. See REP-127 for more info.

Firstly the information seems redundant and secondly when is the information inside package.xml used? What is it used for?

Where CMakeLists.txt and package.xml seem to overlap, is the declaration of build, run and test dependencies. The thing to understand though, is that a 1-to-1 relationship between things you need to build and things you need to run does not necessarily exist. This - coupled with the fact that the CMake language is a rather complex language to parse (because of branching, conditional includes, macros, functions, etc), no standardised naming scheme for files, libraries or their distribution archives, differences between platforms and coding styles - makes it all very hard to reliably extract the necessary information from build scripts alone.

Because of this, systems like the ROS buildfarm require extra (and more machine readable) information to be able to install all the right dependencies while setting up a working build environment. And - after a successful build - to correctly list all run dependencies in the debians (or RPMs on Fedora) that you install using apt-get. That is where package.xml comes in.

Another important benefit of having that information in a format other than a build script is that it allows a certain amount of abstraction, making cross-platform support easier. For some more comments on that, please see why rosdep instead of others?.

Edit: clarified why a machine readable file format is highly preferable to parsing complex, dynamic CMake build scripts.