On 21 October 2011 21:11, Thibault Kruse <
kruset@in.tum.de> wrote:
> **
> Hi Daniel,
>
> yes, current yaml ignores uri for elements of type "other".
>
> You can call "rosinstall . http://rnd.yujinrobot.com/ycs.rosinstall". By
> calling this again you also get updates from
> http://rnd.yujinrobot.com/ycs.rosinstall (only adding new locations or
> changing urls/versions, but not removing anything).
>
> If ycs.rosinstall <http://rnd.yujinrobot.com/ycs.rosinstall> has elements
> with localnames such as
>
> - git:
> local-name: ycs/foo
> uri: https://somewhere.com/foo.git<https://win-ros-pkg.googlecode.com/svn/stacks/win_ros/trunk>
>
> 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:
>
> - other:
> local-name: /opt/ros/electric/ros
>
> - other:
> local-name: ycs
> uri: http://rnd.yujinrobot.com/ycs.rosinstall
>
> - svn:
> local-name: win_ros
> uri: https://win-ros-pkg.googlecode.com/svn/stacks/win_ros/trunk
>
> - git:
> uri: https://github.com/stonier/qt_ros.git
> local-name: qt_ros
> version: master
>
> 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?
>
> Cheers,
> Daniel Stonier.
>
>
(text/plain)