# Generating metapackage artifacts with catkin_tools?

My use case is non-standard. I can't use the public Bloom infrastructure because I have non-public packages, and in the past, I created non-Bloom build scripts that helped me generate Debian packages. I can't easily replace them as they're pretty baked into our process.

Previously, with catkin_make, I could build a metapackage and it's share/package_name/package.xml would show up in the install path. I used this to my advantage to create Debians for my metapackages. My workflow was roughly:

1. Create a workspace dep_ws with the metapackage repo and all its dependencies in it.
2. Build the "dependency" workspace and source dep_ws/install/setup.bash.
3. Create a workspace pkg_ws with only the metapackage's repo in it.
4. Build the "package" workspace.

This resulted in a "clean" install space with just the metapackage in it, as all its dependencies were met in the dependency workspace. I then dumped (more or less) the install path into a Debian and added the metapackage's dependencies as Debian dependencies.

I'm attempting to switch to catkin_tools as it provides many benefits, but I'm running into a problem recreating this workflow. With catkin build, metapackage artifacts don't show up in the install path. In fact, with --summary, it shows the metapackage being [Ignored] (even when I use --whitelist to only allow the metapackage to be built).

How do I generate metapackage artifacts with catkin_tools, such that I can Debianize them and get a "meta-Debian"? Ultimately, the artifacts are important so that I can query the as-built metapackage for its dependencies and add them as Debian dependencies. But if the metapackage's package.xml isn't in the install path, I have no way of doing that.

Or, am I holding it wrong and there's a different/better/correct way to do this (that doesn't involve all of Bloom)? Should I simply treat metapackages differently than normal packages and have a different process for them (now)?

Follow-on: If it is possible to generate metapackage artifacts with catkin_tools, I would also need it to only build the metapackage and not the <exec_depend>s. Currently, even using --whitelist, if I catkin build the metapackage, all its <exec_depend>s get built, too, and pollute the "clean" install space. Is this possible?

edit retag close merge delete

Sort by » oldest newest most voted

Sounds like metapackages are not being built, which is not correct if that's what's happening. You should open a issue on catkin_tools. I guess it has to do with changes that Jonathan Bohren made related to avoiding the case where normal packages that incorrectly depend on metapackages caused catkin build to crash.

more

( 2016-12-29 09:58:36 -0500 )edit