Revision history [back]

I was expecting things not to work with the commented out section, but it turns out it works well without the run_depend tags. The full package can be viewed here.

The package manifest is mostly used for resolving dependencies for packages when they are being installed, either from source (using rosdep), or (after processing by Bloom) by the Debian/Fedora/X package manager. The buidfarm also uses this information.

That things still work on your local machine makes perfect sense: you already have all dependencies installed. Removing the run_depends from your manifest does not change that fact.

(note that for Python this is slightly different, as in that case run_depends are also used to setup the Python path in your workspace).

I've manually written package.xml but I don't understand how I am supposed to fill the build_depend and run_depend tags.

Most people (at least initially) use the catkin_create_pkg command, with appropriate arguments. If, during development, you find that you need to add more dependencies, simply edit the file by hand, as you have done now.

As to whether things are a run_depend, build_depend or test_depend (and sometimes also why), the How to do common tasks section (from the catkin documentation) is probably very helpful (note: the linked version is for Indigo).

1 . How do I check that my package.xml is correctly written? (I only know catkin_lint)

REP-127 would be the authorative source for information on whether the manifest is 'correctly written'. The catkin/package.xml tutorial you linked would be the more informal version of that.

As to dependencies: catkin_lint actually makes sure that the manifest and CMakeLists.txt are consistent with each other (it also performs syntax and 'best practice' conformance checks). It cannot know whether a dependency you stated in your manifest or CMakeLists.txt is actually needed / correct. It does not parse your C++. You are the only one (at the moment) with that knowledge.

Failing builds would be a sign of missing dependencies in CMakeLists.txt.

2 . In what cases would anything fail if the package.xml is wrong?

See earlier comments.

3 . Is there a tool that automatically writes the package.xml? (using the CMakeLists.txt for example). If it's not possible, why?

I don't know of a tool that can generate package.xml for you, but catkin_lint at least does the consistency checks for you. Whether it would be possible to create such a tool: Python packages would be one example of why that is difficult (with only run_depends, and an almost empty CMakeLists.txt).

4 . Why is information duplicated between CMakeLists.txt and package.xml?

I think others (like @dirk-thomas, @William) can probably answer this in more detail, but in general I consider CMakeLists.txt to be the build script, while package.xml is where we store mostly other metadata. Some things are duplicated, but (I think) only because it is complicated to deduce generic rules for translating build dependencies into run dependencies (on some platforms, all build deps are suffixed with -dev, but that is hardly a general rule. There could even be pkgs for which the runtime libraries are in a package with a completely different name than the development artefacts).

I was expecting things not to work with the commented out section, but it turns out it works well without the run_depend tags. The full package can be viewed here.

The package manifest is mostly used for resolving dependencies for packages when they are being installed, either from source (using rosdep), or (after processing by Bloom) by the Debian/Fedora/X package manager. The buidfarm also uses this information.

That things still work on your local machine makes perfect sense: you already have all dependencies installed. Removing the run_depends from your manifest does not change that fact.

(note that for Python this is slightly different, as in that case run_depends are also used to setup the Python path in your workspace).

I've manually written package.xml but I don't understand how I am supposed to fill the build_depend and run_depend tags.

Most people (at least initially) use the catkin_create_pkg command, with appropriate arguments. If, during development, you find that you need to add more dependencies, simply edit the file by hand, as you have done now.

As to whether things are a run_depend, build_depend or test_depend (and sometimes also why), the How to do common tasks section (from the catkin documentation) is probably very helpful (note: the linked version is for Indigo).

1 . How do I check that my package.xml is correctly written? (I only know catkin_lint)

REP-127 would be the authorative source for information on whether the manifest is 'correctly written'. The catkin/package.xml tutorial you linked would be the more informal version of that.

As to dependencies: catkin_lint actually makes sure that the manifest and CMakeLists.txt are consistent with each other (it also performs syntax and 'best practice' conformance checks). It cannot know whether a dependency you stated in your manifest or CMakeLists.txt is actually needed / correct. It does not parse your C++. You are the only one (at the moment) with that knowledge.

Failing builds would be a sign of missing dependencies in CMakeLists.txt.

2 . In what cases would anything fail if the package.xml is wrong?

See earlier comments.

3 . Is there a tool that automatically writes the package.xml? (using the CMakeLists.txt for example). If it's not possible, why?

I don't know of a tool that can generate package.xml for you, but catkin_lint at least does the consistency checks for you. Whether it would be possible to create such a tool: Python packages would be one example of why that is difficult (with only run_depends, and an almost empty CMakeLists.txt).

4 . Why is information duplicated between CMakeLists.txt and package.xml?

I think others (like @dirk-thomas, @William) can probably answer this in more detail, but in general I consider CMakeLists.txt to be the build script, while package.xml is where we store mostly other metadata. Some things are duplicated, but (I think) only because it is complicated to deduce generic rules for translating build dependencies into run dependencies (on some platforms, all build deps are suffixed with -dev, but that is hardly a general rule. There could even be pkgs for which the runtime libraries are in a package with a completely different name than the development artefacts).

I was expecting things not to work with the commented out section, but it turns out it works well without the run_depend tags. The full package can be viewed here.

The package manifest is mostly used for resolving dependencies for packages when they are being installed, either from source (using rosdep), or (after processing by Bloom) by the Debian/Fedora/X package manager. The buidfarm also uses this information.

That things still work on your local machine makes perfect sense: you already have all dependencies installed. Removing the run_depends from your manifest does not change that fact.

(note that for Python this is slightly different, as in that case run_depends are also used to setup the Python path in your workspace).

I've manually written package.xml but I don't understand how I am supposed to fill the build_depend and run_depend tags.

Most people (at least initially) use the catkin_create_pkg command, with appropriate arguments. If, during development, you find that you need to add more dependencies, simply edit the file by hand, as you have done now.

As to whether things are a run_depend, build_depend or test_depend (and sometimes also why), the How to do common tasks section (from the catkin documentation) is probably very helpful (note: the linked version is for Indigo).

1 . How do I check that my package.xml is correctly written? (I only know catkin_lint)

REP-127 would be the authorative source for information on whether the manifest is 'correctly written'. The catkin/package.xml tutorial you linked would be the more informal version of that.

As to dependencies: catkin_lint actually makes sure that the manifest and CMakeLists.txt are consistent with each other (it also performs syntax and 'best practice' conformance checks). It cannot know whether a dependency you stated in your manifest or CMakeLists.txt is actually needed / correct. It does not parse your C++. You are the only one (at the moment) with that knowledge.

Failing builds would be a sign of missing dependencies in CMakeLists.txt.

2 . In what cases would anything fail if the package.xml is wrong?

See earlier comments.

3 . Is there a tool that automatically writes the package.xml? (using the CMakeLists.txt for example). If it's not possible, why?

I don't know of a tool that can generate package.xml for you, but catkin_lint at least does the consistency checks for you. Whether it would be possible to create such a tool: Python packages would be one example of why that is difficult (with only run_depends, and an almost empty CMakeLists.txt).

4 . Why is information duplicated between CMakeLists.txt and package.xml?

I think others (like @dirk-thomas, @William) @william) can probably answer this in more detail, but in general I consider CMakeLists.txt to be the build script, while package.xml is where we store mostly other metadata. Some things are duplicated, but (I think) only because it is complicated to deduce generic rules for translating build dependencies into run dependencies (on some platforms, all build deps are suffixed with -dev, but that is hardly a general rule. There could even be pkgs for which the runtime libraries are in a package with a completely different name than the development artefacts).

I was expecting things not to work with the commented out section, but it turns out it works well without the run_depend tags. The full package can be viewed here.

The package manifest is mostly used for resolving dependencies for packages when they are being installed, either from source (using rosdep), or (after processing by Bloom) by the Debian/Fedora/X package manager. The buidfarm also uses this information.

That things still work on your local machine makes perfect sense: you already have all dependencies installed. Removing the run_depends from your manifest does not change that fact.

(note that for Python this is slightly different, as in that case run_depends are also used to setup the Python path in your workspace).

I've manually written package.xml but I don't understand how I am supposed to fill the build_depend and run_depend tags.

Most people (at least initially) use the catkin_create_pkg command, with appropriate arguments. If, during development, you find that you need to add more dependencies, simply edit the file by hand, as you have done now.

As to whether things are a run_depend, build_depend or test_depend (and sometimes also why), the How to do common tasks section (from the catkin documentation) is probably very helpful (note: the linked version is for Indigo).

1 . How do I check that my package.xml is correctly written? (I only know catkin_lint)

REP-127 would be the authorative source for information on whether the manifest is 'correctly written'. The catkin/package.xml tutorial you linked would be the more informal version of that.

As to dependencies: catkin_lint actually makes sure that the manifest and CMakeLists.txt are consistent with each other (it also performs syntax and 'best practice' conformance checks). It cannot know whether a dependency you stated in your manifest or CMakeLists.txt is actually needed / correct. It does not parse your C++. You are the only one (at the moment) with that knowledge.

Failing builds would be a sign of missing dependencies in CMakeLists.txt.

2 . In what cases would anything fail if the package.xml is wrong?

See earlier comments.

3 . Is there a tool that automatically writes the package.xml? (using the CMakeLists.txt for example). If it's not possible, why?

I don't know of a tool that can generate package.xml for you, but catkin_lint at least does the consistency checks for you. Whether it would be possible to create such a tool: Python packages would be one example of why that is difficult (with only run_depends, and an almost empty CMakeLists.txt).

4 . Why is information duplicated between CMakeLists.txt and package.xml?

I think others (like @dirk-thomas, @william) @Dirk Thomas, @William) can probably answer this in more detail, but in general I consider CMakeLists.txt to be the build script, while package.xml is where we store mostly other metadata. Some things are duplicated, but (I think) only because it is complicated to deduce generic rules for translating build dependencies into run dependencies (on some platforms, all build deps are suffixed with -dev, but that is hardly a general rule. There could even be pkgs for which the runtime libraries are in a package with a completely different name than the development artefacts).

I was expecting things not to work with the commented out section, but it turns out it works well without the run_depend tags. The full package can be viewed here.

The package manifest is mostly used for resolving dependencies for packages when they are being installed, either from source (using rosdep), or (after processing by Bloom) by the Debian/Fedora/X package manager. The buidfarm also uses this information.

That things still work on your local machine makes perfect sense: you already have all dependencies installed. Removing the run_depends from your manifest does not change that fact.

(note that for Python this is slightly different, as in that case run_depends are also used to setup the Python path in your workspace).

I've manually written package.xml but I don't understand how I am supposed to fill the build_depend and run_depend tags.

Most people (at least initially) use the catkin_create_pkg command, with appropriate arguments. If, during development, you find that you need to add more dependencies, simply edit the file by hand, as you have done now.

As to whether things are a run_depend, build_depend or test_depend (and sometimes also why), the How to do common tasks section (from the catkin documentation) is probably very helpful (note: the linked version is for Indigo).

1 . How do I check that my package.xml is correctly written? (I only know catkin_lint)

REP-127 would be the authorative source for information on whether the manifest is 'correctly written'. The catkin/package.xml tutorial you linked would be the more informal version of that.

As to dependencies: catkin_lint actually makes sure that the manifest and CMakeLists.txt are consistent with each other (it also performs syntax and 'best practice' conformance checks). It cannot know whether a dependency you stated in your manifest or CMakeLists.txt is actually needed / correct. It does not parse your C++. You are the only one (at the moment) with that knowledge.

Failing builds would be a sign of missing dependencies in CMakeLists.txt.

2 . In what cases would anything fail if the package.xml is wrong?

See earlier comments.

3 . Is there a tool that automatically writes the package.xml? (using the CMakeLists.txt for example). If it's not possible, why?

I don't know of a tool that can generate package.xml for you, but catkin_lint at least does the consistency checks for you. Whether it would be possible to create such a tool: Python packages would be one example of why that is difficult (with only run_depends, and an almost empty CMakeLists.txt).

4 . Why is information duplicated between CMakeLists.txt and package.xml?

I think others (like @Dirk Thomas, @William) @wjwwood) can probably answer this in more detail, but in general I consider CMakeLists.txt to be the build script, while package.xml is where we store mostly other metadata. Some things are duplicated, but (I think) only because it is complicated to deduce generic rules for translating build dependencies into run dependencies (on some platforms, all build deps are suffixed with -dev, but that is hardly a general rule. There could even be pkgs for which the runtime libraries are in a package with a completely different name than the development artefacts).

I was expecting things not to work with the commented out section, but it turns out it works well without the run_depend tags. The full package can be viewed here.

The package manifest is mostly used for resolving dependencies for packages when they are being installed, either from source (using rosdep), or (after processing by Bloom) by the Debian/Fedora/X package manager. The buidfarm also uses this information.

That things still work on your local machine makes perfect sense: you already have all dependencies installed. Removing the run_depends from your manifest does not change that fact.

(note that for Python this is slightly different, as in that case run_depends are also used to setup the Python path in your workspace).

I've manually written package.xml but I don't understand how I am supposed to fill the build_depend and run_depend tags.

Most people (at least initially) use the catkin_create_pkg command, with appropriate arguments. If, during development, you find that you need to add more dependencies, simply edit the file by hand, as you have done now.

As to whether things are a run_depend, build_depend or test_depend (and sometimes also why), the How to do common tasks section (from the catkin documentation) is probably very helpful (note: the linked version is for Indigo).

1 . How do I check that my package.xml is correctly written? (I only know catkin_lint)

REP-127 would be the authorative source for information on whether the manifest is 'correctly written'. The catkin/package.xml tutorial you linked would be the more informal version of that.

As to dependencies: catkin_lint actually makes sure that the manifest and CMakeLists.txt are consistent with each other (it also performs syntax and 'best practice' conformance checks). It cannot know whether a dependency you stated in your manifest or CMakeLists.txt is actually needed / correct. It does not parse your C++. You are the only one (at the moment) with that knowledge.

Failing builds would be a sign of missing dependencies in CMakeLists.txt.

2 . In what cases would anything fail if the package.xml is wrong?

See earlier comments.

3 . Is there a tool that automatically writes the package.xml? (using the CMakeLists.txt for example). If it's not possible, why?

I don't know of a tool that can generate package.xml for you, but catkin_lint at least does the consistency checks for you. Whether it would be possible to create such a tool: Python packages would be one example of why that is difficult (with only run_depends, and an almost empty CMakeLists.txt).

4 . Why is information duplicated between CMakeLists.txt and package.xml?

I think others (like @Dirk Thomas, @wjwwood) @William) can probably answer this in more detail, but in general I consider CMakeLists.txt to be the build script, while package.xml is where we store mostly other metadata. Some things are duplicated, but (I think) only because it is complicated to deduce generic rules for translating build dependencies into run dependencies (on some platforms, all build deps are suffixed with -dev, but that is hardly a general rule. There could even be pkgs for which the runtime libraries are in a package with a completely different name than the development artefacts).

I was expecting things not to work with the commented out section, but it turns out it works well without the run_depend tags. The full package can be viewed here.

The package manifest is mostly used for resolving dependencies for packages when they are being installed, either from source (using rosdep), or (after processing by Bloom) by the Debian/Fedora/X package manager. The buidfarm also uses this information.

That things still work on your local machine makes perfect sense: you already have all dependencies installed. Removing the run_depends from your manifest does not change that fact.

(note that for Python this is slightly different, as in that case run_depends are also used to setup the Python path in your workspace). (probably not true, see also REP-122/PYTHONPATH, roslib.load_manifest())

I've manually written package.xml but I don't understand how I am supposed to fill the build_depend and run_depend tags.

Most people (at least initially) use the catkin_create_pkg command, with appropriate arguments. If, during development, you find that you need to add more dependencies, simply edit the file by hand, as you have done now.

As to whether things are a run_depend, build_depend or test_depend (and sometimes also why), the How to do common tasks section (from the catkin documentation) is probably very helpful (note: the linked version is for Indigo).

1 . How do I check that my package.xml is correctly written? (I only know catkin_lint)

REP-127 would be the authorative source for information on whether the manifest is 'correctly written'. The catkin/package.xml tutorial you linked would be the more informal version of that.

As to dependencies: catkin_lint actually makes sure that the manifest and CMakeLists.txt are consistent with each other (it also performs syntax and 'best practice' conformance checks). It cannot know whether a dependency you stated in your manifest or CMakeLists.txt is actually needed / correct. It does not parse your C++. You are the only one (at the moment) with that knowledge.

Failing builds would be a sign of missing dependencies in CMakeLists.txt.

2 . In what cases would anything fail if the package.xml is wrong?

See earlier comments.

3 . Is there a tool that automatically writes the package.xml? (using the CMakeLists.txt for example). If it's not possible, why?

I don't know of a tool that can generate package.xml for you, but catkin_lint at least does the consistency checks for you. Whether it would be possible to create such a tool: Python packages would be one example of why that is difficult (with only run_depends, and an almost empty CMakeLists.txt).

4 . Why is information duplicated between CMakeLists.txt and package.xml?

I think others (like @Dirk Thomas, @William) can probably answer this in more detail, but in general I consider CMakeLists.txt to be the build script, while package.xml is where we store mostly other metadata. Some things are duplicated, but (I think) only because it is complicated to deduce generic rules for translating build dependencies into run dependencies (on some platforms, all build deps are suffixed with -dev, but that is hardly a general rule. There could even be pkgs for which the runtime libraries are in a package with a completely different name than the development artefacts).