[Bug 965] New: ROS dependency in OCL's manifest

http://bugs.orocos.org/show_bug.cgi?id=965

Summary: ROS dependency in OCL's manifest
Product: Toolchain
Version: 2.5.0
Platform: All
OS/Version: All
Status: NEW
Severity: blocker
Priority: P3
Component: OCL
AssignedTo: orocos-dev [..] ...
ReportedBy: charles [dot] lesire [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0

The OCL manifest file lists 'rospack' as a dependency.
Of course, it prevents non-ROS users to install OCL as rospack is not found!

[Bug 965] ROS dependency in OCL's manifest

http://bugs.orocos.org/show_bug.cgi?id=965

Peter Soetens <peter [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED

[Bug 965] ROS dependency in OCL's manifest

http://bugs.orocos.org/show_bug.cgi?id=965

Peter Soetens <peter [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |peter [..] ...

[Bug 965] ROS dependency in OCL's manifest

On 06/16/2012 11:53 PM, Peter Soetens wrote:
> I assumed rospack was available as a python 'easy-install' package, which made
> it ROS independent, as long as it's added to the OS dependency resolution
> lists...
I don't see how rospack can be ros independent. How would you feel if we
added autoproj as a dependency of packages, since it is available as a
rubygem ?

And there is anyway currently no support for python eggs in autoproj

Sylvain

[Bug 965] ROS dependency in OCL's manifest

On Sun, Jun 17, 2012 at 10:24 AM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:

> On 06/16/2012 11:53 PM, Peter Soetens wrote:
>
>> I assumed rospack was available as a python 'easy-install' package, which
>> made
>> it ROS independent, as long as it's added to the OS dependency resolution
>> lists...
>>
> I don't see how rospack can be ros independent.

Because it can be downloaded independently, just like pkg-config works. The
only 'ros' thing is the name.

> How would you feel if we added autoproj as a dependency of packages, since
> it is available as a rubygem ?
>

I wouldn't mind at all. We're already coping with depending on gems for
using typegen, and we're still going forward with a unified build
structure...

>
> And there is anyway currently no support for python eggs in autoproj

Ok. I think it would be very similar to installing gems...

Peter

[Bug 965] ROS dependency in OCL's manifest

On 06/17/2012 10:19 PM, Peter Soetens wrote:
> On Sun, Jun 17, 2012 at 10:24 AM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...
> <mailto:sylvain [dot] joyeux [..] ...>> wrote:
>
> On 06/16/2012 11:53 PM, Peter Soetens wrote:
>
> I assumed rospack was available as a python 'easy-install'
> package, which made
> it ROS independent, as long as it's added to the OS dependency
> resolution
> lists...
>
> I don't see how rospack can be ros independent.
>
>
> Because it can be downloaded independently, just like pkg-config works.
> The only 'ros' thing is the name.
... rospack assumes that you are using a ROS build structure, which *is*
ros dependent. There's more than "ros' in the name. Moreover, I do hope
that OCL depends on it only when built in a ROS context.

Anyways, what I'm taking out of this is a difference in how we both see
things w.r.t. the build system (something that I noticed for a while
already ...). For you, it is "whatever works". On my side, I'm trying to
use standard tools in packages, leaving the weird bits (autoproj, ros*,
...) out of them. Because they are *not* standard. All the
build-packages problems *have* been solved quite satisfactorily by the
software development community, which is multiple orders of magnitude
bigger than whatever the robotics community will ever be. In this
context, having an autoproj-related dependency on packages would
definitely be stinky in my opinion. So is rospack.

On a related note, I would be glad if you could share with the
orocos-dev community exactly how you are "going forward with a unified
build structure". That would probably help being synchronized with
whatever rock/autoproj is going forward to (or is going to ... since I
am in parental leave until september).

These developments have always been done, on your side, behind closed
doors (which has led you to complain that rock has not used them).
Finally being public about them would help foster acceptance.

Sylvain