I think you can have most of what you want already.
You can then maintain several such rosinstall files and keep merging
them into your environment (by calling rosinstall . http://rnd.yujinrobot.com/ycs.rosinstall",
which can be in a script)
That's maybe not exactly what you want, but close.
It seems there are two uses for .rosinstall files - 1) as a snippet that is not useful standalone 2) as representative of a complete, standalone ros buildable source tree.
2) is convenient. I did think of using scripts to do as you say, but it's still awkward. You'd be using custom scripts + rosinstalls - two tools where one would be simpler and less to remember. In addition, if you wanted the flexibility of letting them target the script to a location of their choice, or running it with a nobuild option (or any of rosinstall's usual arguments), you then have to repeat all the rosinstall logic inside your scripts.
Else, maybe describe your workflow also.
Essentially we setup a .rosinstall for each robot, or environment. Being able to include other .rosinstalls would let us track moving changes in dependant .rosinstalls (e.g. the .rosinstall generated by ros' variants) and remove alot of copy/pasting commonly used stacks now that our rosinstall scripts are getting largish.
Daniel.
cheers,
Thibault
On 10/21/2011 10:46 AM, Daniel Stonier wrote:
Hi all,
Pretty sure this can't be done with the current yaml so I
guess it falls in the area of a feature request.
e.g. envisioning a rosinstall file that would look
something like:
where ycs.rosinstall conveniently collects and maintains
its own working set. This would be fairly convenient to our
workflow, would it be a useful addition for others in
general?