Comments (11)
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.
from old_orocos_kinematics_dynamics.
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.
from old_orocos_kinematics_dynamics.
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.
from old_orocos_kinematics_dynamics.
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
+32 479 511 786
Intermodalics - Kapeldreef 60, 3001 Heverlee - BELGIUM
www.intermodalics.eu
from old_orocos_kinematics_dynamics.
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?
from old_orocos_kinematics_dynamics.
A lot of this could be simplified just by calling
orocos_kdl
-->kdl
and make it more consistent with the toolchain libraries. Currentlykdl
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.
from old_orocos_kinematics_dynamics.
@smits @meyerj Take a look at this new arrangement in PR #2
from old_orocos_kinematics_dynamics.
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?
from old_orocos_kinematics_dynamics.
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.
from old_orocos_kinematics_dynamics.
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
from old_orocos_kinematics_dynamics.
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!
from old_orocos_kinematics_dynamics.
Related Issues (1)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from old_orocos_kinematics_dynamics.