# CMakeLists.txt vs package.xml

Hi all,

I have been using ROS for a bit more than a year now and there is still something I cannot understand in the relation between the CMakeLists.txt used and the extra catkin-specific information added by package.xml.

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? Firstly the information seems redundant and secondly when is the information inside package.xml used? What is it used for?

I have looked for the information on the net but no explanation was clear to me.

Edit:

And thanks for your thorough answer. Things are getting a bit more clear.

Now there is still something I am missing: the package.xml page states that

If they are missing or incorrect, you may be able to build from source and run tests on your own machine, but your package will not work correctly when released to the ROS community.

Now I am not sure I understand how this mechanism works. Does it mean that the dependencies normally delt with the CMakeLists.txt when I am on my local machine are handled by ROS when I deploy my packages to the outside world?

edit retag close merge delete

( 2015-09-15 02:20:17 -0600 )edit

You are right, thanks for correcting things.

( 2015-09-15 05:16:38 -0600 )edit

Sort by » oldest newest most voted

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

more

5

Another reason is that the CMake file is not "machine readable". It can contain arbitrary logic in CMake and can't be read without interpreting the CMake code. The XML on the other hand can easily be read.

( 2015-09-11 06:41:52 -0600 )edit
1

Yeah. I think that was partly what I was trying to express with the libfoo.so, package Bar example. I added some clarification. Thanks.

( 2015-09-11 07:08:27 -0600 )edit

Thanks for clarifying things!

( 2015-09-15 05:18:08 -0600 )edit
1

We need wiki pages for conceptual/design-choice/architecture based answers like these. Or an option to transform particular ROS answer pages into wikis (ala Stack Exchange websites).

( 2016-08-18 14:13:24 -0600 )edit

I'd encourage you to post these kind of sentiments/observations on discourse.ros.org and to start a discussion there. Posting them as comments on old(er) questions will lead to very few ppl reading them, as visibility is low here.

( 2016-08-18 14:31:07 -0600 )edit