Invalid package names orocos-kdl and python-orocos-kdl about old_orocos_kinematics_dynamics

[meyerj]

This is the output of rosdep install orocos-kdl:

$ rosdep install orocos-kdl
WARNING: Package name "orocos-kdl" does not follow the naming conventions. It should start with a lower case letter and only contain lower case letters, digits and underscores.

[smits]

Hi,

is there any update on this? I'm preparing a new release into hydro and wonder if I might merge this catkin branch into master.

[jbohren]

Well the catkin devs still seem to be divided about 3rd-party packs names and whether they should force package.xml names to be all lowercase and underscored. The problem with this is that it makes things confusing for orocos packages which are referred to with hyphens everywhere, and it screws up the auto-generation of orocos_find_package() calls.

The ironic thing is that they're enforcing the ros underscore standard mostly because the debian community enforces the hyphen standard and they want to have a consistent mapping between the two. This means that in the case of KDL, they would like it to remain to be called "orocos_kdl" so that the debian package can be called "orocos-kdl".

At this point it seems like there's no way for it to be consistent everywhere. It's up to @smits to decide if anything should change to make things more consistent and which interfaces should generate warnings, and this fork will follow.

[smits]

On Tue, Oct 8, 2013 at 10:30 AM, Jonathan Bohren
[email protected]:

Well the catkin devs still seem to be divided about 3rd-party packs names
and whether they should force package.xml names to be all lowercase and
underscored. The problem with this is that it makes things confusing for
orocos packages which are referred to with hyphens everywhere, and it
screws up the auto-generation of orocos_find_package() calls.

@jbohren: Can you elaborate a bit more about the screwing up?

The ironic thing is that they're enforcing the ros underscore standard
mostly because the debian community enforces the hyphen standard and they
want to have a consistent mapping between the two. This means that in the
case of KDL, they would like it to remain to be called "orocos_kdl" so that
the debian package can be called "orocos-kdl".

I do not really understand the reason why both standards need to be
different. But as long as people need to be able to 'rospack find
orocos_kdl' I suggest to keep the underscore until this is fixed/not
necessary anymore.

At this point it seems like there's no way for it to be consistent
everywhere. It's up to @smits https://github.com/smits to decide if
anything should change to make things more consistent and which interfaces
should generate warnings, and this fork will follow.

I first need to know what the implications are for using the hyphen at some
places and the underscore at others.

—
Reply to this email directly or view it on GitHubhttps://github.com/jhu-lcsr-forks/orocos_kinematics_dynamics/issues/1#issuecomment-25872651
.

Ruben Smits, CTO
[phone]
Intermodalics - Kapeldreef 60, 3001 Heverlee - BELGIUM
www.intermodalics.eu

[jbohren]

On Tue, Oct 8, 2013 at 10:30 AM, Jonathan Bohren [email protected]:

Well the catkin devs still seem to be divided about 3rd-party packs names and whether they should force package.xml names to be all lowercase and underscored. The problem with this is that it makes things confusing for orocos packages which are referred to with hyphens everywhere, and it screws up the auto-generation of orocos_find_package() calls.

@jbohren: Can you elaborate a bit more about the screwing up?

So RTT and OCL generate packages whose build flags are encoded in pkg-config files which are named like ocl-deployment and ocl-logging and if you want these to be orocos_find_package()'d automatically, they need to be in the package.xml file. As I'm writing this I realize that what we're really missing to deal with the orocos_find_package() calls is a CMake config file for OCL similar to the one for RTT which uses the COMPONENTS argument to get sub-components (like deployment, logging, etc). So consider my above statement solvable and I'll go add that CMake config file over in OCL (jhu-lcsr-forks/ocl#2).

The ironic thing is that they're enforcing the ros underscore standard mostly because the debian community enforces the hyphen standard and they want to have a consistent mapping between the two. This means that in the case of KDL, they would like it to remain to be called "orocos_kdl" so that the debian package can be called "orocos-kdl".

I do not really understand the reason why both standards need to be different. But as long as people need to be able to 'rospack find orocos_kdl' I suggest to keep the underscore until this is fixed/not necessary anymore.

At this point it seems like there's no way for it to be consistent everywhere. It's up to @smits https://github.com/smits to decide if anything should change to make things more consistent and which interfaces should generate warnings, and this fork will follow.

I first need to know what the implications are for using the hyphen at some
places and the underscore at others.

This was initially because the package was called orocos_kdl but in CMake, the variables it generated were Orocos-KDL so calling find_package() with orocos_kdl and getting Orocos-KDL_LIBRARIES etc could be confusing.

While I'm on the topic of CMake variables, it would be nice to unify some of the conventions between KDL and RTT, for example, KDL sets Orocos-KDL_* and RTT sets OROCOS-RTT_*. Furthermore, the package containing rtt is just called rtt and the package containing KDL is called orocos_kdl.

A lot of this could be simplified just by calling orocos_kdl --> kdl and make it more consistent with the toolchain libraries. Currently kdl is a stack/metapackage which contains KDL and the Python KDL bindings. @smits, what are your thoughts on that?

[jbohren]

A lot of this could be simplified just by calling orocos_kdl --> kdl and make it more consistent with the toolchain libraries. Currently kdl is a stack/metapackage which contains KDL and the Python KDL bindings. @smits, what are your thoughts on that?

Of course we could maintain an orocos_kdl package for backwards compatibility which would just export the flags for the kdl package.

[jbohren]

@smits @meyerj Take a look at this new arrangement in PR #2

[smits]

Ok, it all looks reasonable to me, but how do we proceed from here? We have already released KDL into hydro, how can we release again without breaking other peoples packages?

[jbohren]

I think I can make it so nobody notices. The only name collision is between the new kdl package and the old kdl metapackage. Now, fortunately for us, normal packages can't actually depend on metapackages, so anyone who's actually depending on KDL depends on orocos_kdl so we can create a dummy deprecated package called orocos_kdl which depends on the new kdl package and exports all the right flags. We can do something similar with the python bindings. Then when Indigo is released we can remove the compatibility packages.

[smits]

Sounds good to me, but there are also packages using find_package(orocos_kdl) and using the generated cmake variables. We need to take care of those cases too.

BTW, I really appreciate all the work your doing @jbohren

[jbohren]

Sounds good to me, but there are also packages using find_package(orocos_kdl) and using the generated cmake variables. We need to take care of those cases too.

Yeah, that should be all set in 02e01a5

BTW, I really appreciate all the work your doing @jbohren

Thanks. I really appreciate all the work you did in the first place!