Add cpack-like option to generate Debian packages from ament packages.

[dustingooding]

http://www.cmake.org/Wiki/CMake:Packaging_With_CPack

Since ament uses CMake under the covers, it seems reasonable to me to support some of the CPack features like generating Debian packages directly from ament packages. Not everyone wants to set up bloom and the complicated multi-repository upstream stuff... Sometimes I just want to take the install space I've already generated, add a control file, and be done with it.

I'd like to propose a new verb and accompanying ament cmake macros. Something like 'ament release' (and 'ament release_pkg') to generate debs (or other installer formats) from all packages or selected packages. The cmake macros would be helpful wrappers that automatically pull information from package.xml to populate the cpack variables.

[wjwwood]

I'm not opposed to this, but I think there will be some issues with the suggested approach.

First, CPack operates on a single CMake package, but you're talking about operating on multiple packages. My experience with CPack, like CMake in general, is that it doesn't scale well to many interdependent packages without extra work.

I've discussed this with people before:

http://answers.ros.org/question/192419/how-to-setup-bloom-to-generate-a-local-deb-outside-of-rosorg-buildfarm/

I'm not saying this is impossible, just that there are issues you may not be aware of that need to be overcome.

[wjwwood]

That being said, for ROS 2, I'll probably reconsider how releases are made, with the possibility of using CPack for CMake based packages.

Also, just to be clear, ament_cmake uses CMake, but we also have pure Python packages as well as autoconf, so we need to consider those when figuring out how to do releases.

[dustingooding]

I was unaware of the pure Python package and autoconf support. I assumed ament continued the legacy of cmake-based packages. I concede cpack will not be a general solution then.

FWIW, the way we do release packages in-house are through a series of python scripts that build catkin packages in a clean install tree (handling dependency packages in an underlay workspace), then use rosdep to convert run_depends into debian dependencies. I imagined a similar rosdep approach here, that magically determined debian package names according to naming rules that admittedly don't exist yet.

If this can't be implemented as written, I get that. This was more of a "this kinda thing should exist, somehow" ticket that we keep in our minds as we move forward.

[wjwwood]

Ok, I'll leave it open and in our backlog.

[dirk-thomas]

Closing since the repo is archived.