ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Would using .rosinstall files be an option?

To separately build your 'releases', it would mean creating workspaces for each release, but those could be temporary. The .rosinstall file would group all packages that you consider to be part of the release. wstool merge URL && wstool up could then be used to easily create the workspace. Invoking catkin_make on that workspace would only build the packages in it, nothing more. Dependency resolution would still work as normal.

Would using .rosinstall files be an option?

To separately build your 'releases', it would mean creating workspaces for each release, but those could be temporary. The .rosinstall file would group all packages that you consider to be part of the release. wstool merge URL && wstool up could then be used to easily create populate the workspace. Invoking catkin_make on that workspace would only build the packages in it, nothing more. Dependency resolution would still work as normal.

Would using .rosinstall files be an option?

To separately build your 'releases', it would mean creating workspaces for each release, but those could be temporary. The .rosinstall file would group all packages that you consider to be part of the release. wstool merge URL && wstool up could then be used to easily populate the workspace. Invoking catkin_make on that workspace would only build the packages in it, nothing more. Dependency resolution would still work as normal.

.rosinstall files support specifying versions, checking out from tags (since you're using SVN) and could themselves be versioned (they're just text files). If properly named, they would also be easily recognisable.

Would using .rosinstall files be an option?

To separately build your 'releases', it would mean creating workspaces for each release, but those could be temporary. The .rosinstall file would group all packages that you consider to be part of the release. wstool merge URL && wstool up could then be used to easily populate the workspace. Invoking catkin_make on that workspace would only build the packages in it, nothing more. Dependency resolution would still work as normal.

.rosinstall files support specifying versions, checking out from tags (since you're using SVN) and could themselves be versioned (they're just text files). If properly named, they would also be easily recognisable.


Edit:

Perhaps not a real answer to your question, but reading the new wiki page about the new buildfarm setup reminded me of the requirements you describe. You might be able to exploit the configurability of the new buildfarm setup to get something a little more automated. Especially the Build a entirely custom ROS Distro section under buildfarm - Use Cases seems to fit your use case.