Hi.
I work on a project with differents components maintained by different person on different workstation. So when i write my component, if i have "dependencies" to others, i write for example
#include <rtt/TaskContexts.hpp> #include <my_associate_component.h>
For Future version i would like to regroup every orocos stuff in one place.
For example, lets say we have Orocos-RTT, Orocos-KDL, Orocos-OCL, Orocos-myproject. My project have mycomponent_1, mycomponent_2.
The install directory layout could be.
include
orocos
rtt
...
kdl
...
ocl
...
myproject
lib
liborocos-rtt-xxx.so
liborocos-kdl-xxx.so
liborocos-ocl-xxx.so
liborocos-myproject-mycomponent_1.so
liborocos-myproject-mycomponent_2.soThe lib/rtt could be flattened at the root of lib.
My proposition is just an example.
The important thing is to have a naming convention and don't have too many things related to orocos too scattered.
Thanks for your reading.
Paul.
RTT 2 naming convention suggestion
On Friday 08 January 2010 15:23:26 paul [dot] chavent [..] ... wrote:
> Hi.
>
> I work on a project with differents components maintained by different
> person on different workstation. So when i write my component, if i have
> "dependencies" to others, i write for example
>
> For Future version i would like to regroup every orocos stuff in one place.
>
> For example, lets say we have Orocos-RTT, Orocos-KDL, Orocos-OCL,
> Orocos-myproject. My project have mycomponent_1, mycomponent_2.
>
> The install directory layout could be.
>
>
>
> The lib/rtt could be flattened at the root of lib.
>
> My proposition is just an example.
>
> The important thing is to have a naming convention and don't have too many
> things related to orocos too scattered.
So if I translate this to what needs to change, You'd require to be able to
install headers in <prefix>/include/orocos/<package> instead of
<prefix>/include/<package> and install libraries in <prefix>/lib/ ?
... with <prefix> being set to CMAKE_INSTALL_PREFIX. I don't know yet how to
add the 'orocos' prefix in front of the package name, I think we have to write
our own cmake logic. Also the .pc files would need to change.
With respect to the libraries, I don't agree fully. I believe the components
(ocl and yours), typekits and other plugins need to be installed in an orocos
subdirectory of <prefix>/lib, while rtt and kdl remain in <prefix>/lib.
That's conforming the 'modules' policy of the 'lib' dir on Linux systems: if
a program uses plugins or dynamically loads modules, these may/must be put in
a sub directory of lib, because they are not made to be linked against, and
they would clutter the /lib directory.
So in my proposal you would have:
include/orocos/[rtt|kdl|yourproject]
lib/liborocos-rtt.so
lib/orocos/plugins/rtt-scripting-gnulinux.so
lib/orocos/types/rtt-types-gnulinux.so
lib/orocos/ocl/ocl-component-gnulinux.so
As a special provision, each lib directory will also to be allowed to have a
'target' subdirectory for grouping target specific libraries (instead of
encoding the target in the so name):
lib/orocos/plugins/gnulinux/rtt-scripting.so
lib/orocos/types/gnulinux/rtt-types.so
lib/orocos/ocl/gnulinux/ocl-component.so
This provision is only necessary on targets that support running multiple
targets, like the gnulinux/[lxrt|xenomai] combo. win32 and macosx targets will
not need to make use of this provision.
This is transparant to users, they will always be able to write something
like:
the RTT will then look for:
1. lib/orocos/ocl/ocl-component.[so|dll|...]
2. lib/orocos/ocl/ocl-component-gnulinux.[so|dll|..]
3. lib/orocos/ocl/gnulinux/ocl-component.[so|dll|...]
In that order. You'll be able to set the ORO_COMPONENT_PATH environment
variable or deployment property to an ordered list of places to look for
components and plugins.
Thoughts ?
Peter
RTT 2 naming convention
So in your proposal we would have:
include/orocos/[rtt|kdl|ocl|yourproject]
lib/liborocos-rtt.so
lib/orocos/plugins/rtt-scripting-gnulinux.so
lib/orocos/types/rtt-types-gnulinux.so
lib/orocos/ocl/ocl-component-gnulinux.so
lib/orocos/yourproject/ocl-yourcomponent-gnulinux.so
Ok, it's seems clean and clear.
RTT 2 naming convention suggestion
On Wednesday 13 January 2010 10:29:13 Sylvain Joyeux wrote:
> > With respect to the libraries, I don't agree fully. I believe the
> > components (ocl and yours), typekits and other plugins need to be
> > installed in an orocos subdirectory of <prefix>/lib, while rtt and kdl
> > remain in <prefix>/lib.
>
> +1
>
> > That's conforming the 'modules' policy of the 'lib' dir on Linux
> > systems: if a program uses plugins or dynamically loads modules, these
> > may/must be put in a sub directory of lib, because they are not made to
> > be linked against, and they would clutter the /lib directory.
>
> They can be linked against, this is no problem (see static deployments in
> orogen). But I agree on the need for an orocs/ subdirectory ;-)
>
> > So in my proposal you would have:
> > include/orocos/[rtt|kdl|yourproject]
> > lib/liborocos-rtt.so
> > lib/orocos/plugins/rtt-scripting-gnulinux.so
> > lib/orocos/types/rtt-types-gnulinux.so
> > lib/orocos/ocl/ocl-component-gnulinux.so
>
> What about transports ?
>
> I would prefer
> orocos/types/rtt-transport-<transport_name>-gnulinux.so
>
> to avoid having 2000 subdirectories in lib/orocos
Ack.
> >
> > Thoughts ?
>
> * orogen also has a toolkit/ directory in include/-- would be types/ in
> RTT2.0 -- in which type-related headers are stored (as for instance
> generated IDL files and <project_name>ToolkitTypes.hpp headers which
> load all C++ definitions for types defined in <project_name> plus external
> template declarations for properties, ports, ...).
>
> The rationale was to see type libraries are a global thing while
> components are more local -- a rationale you seem to follow given your
> directory structure in lib/
Ack. Remember that Toolkit will be renamed to Typekit.
>
> * I'm wondering if it make sense to mandate that projects are split on a
> per- component basis. It makes sense for OCL which is a collection of
> unrelated components, but is "hair-splitting-style" for orogen projects in
> which components are closely related to each other (for instance).
>
> I.e. I would allow both project_name/libcomponent.so or lib
> project_name.so. This would be allowed by changing the API to
>
> TaskContext* nc = RTT::loadComponent("project_name", "component_name",
> "NewComponent");
>
> which would search for
> orocos/libproject_name.so
> orocos/project_name/libcomponent_name.so
>
May I refrase this into:
which would search for
orocos/package.so (and looks for component_name inhere)
orocos/package/component_name.so
> It also could automatically load the toolkits/transports of the said
> project, as the interfaces of the project's components are very likely
> to need it.
Meaning you can have an orocos/package/types directory ?
> (note: the Ruby libraries I have do that on a more fine-grained basis
> since they can compute what component needs what toolkit ... thanks to
> model- based development)
>
> * I would keep the "lib" prefix as these libraries are not only plugins
> (i.e. dynamic-loadable) but also plain libraries (orogen uses them as
> such).
Hmm. I wouldn't, although I acknowledge that component libs are used for
linking too. I don't want to see the lib prefix in user (xml) code. It makes
the plugin loading code complexer. If you want to satisfy everyone, you'd need
to search for:
orocos/package.so (and looks for component_name inhere)
orocos/libpackage.so (and looks for component_name inhere)
orocos/libpackage-gnulinux.so (and looks for component_name inhere)
orocos/package/component_name.so
orocos/package/component_name-gnulinux.so
orocos/package/libcomponent_name.so
orocos/package/libcomponent_name-gnulinux.so
orocos/package/gnulinux/component_name.so
orocos/package/gnulinux/libcomponent_name.so
So this doubles our search paths list. What about using symlinks ?
Peter
RTT 2 naming convention suggestion
On Wed, 13 Jan 2010, Sylvain Joyeux wrote:
Has any thought been given already to a concrete _versioning_ approach that
can be used during runtime to make sure(?) that only version-compatible
components can get connected? I think this problem is connected to some
extent with the "namespaces", since the name _plus_ the version are
basically the real semantic tags to structure the software (in source code
form as well as binary form). The svn versions _could_ maybe serve a
purpose here, but I am quite confident that we have to add them to the
interface of the components in one way or another...
Thoughts?
Herman
> On Wednesday 13 January 2010 13:35:25 Peter Soetens wrote:
>>>> Thoughts ?
>>>
>>> * orogen also has a toolkit/ directory in include/-- would be types/ in
>>> RTT2.0 -- in which type-related headers are stored (as for instance
>>> generated IDL files and <project_name>ToolkitTypes.hpp headers which
>>> load all C++ definitions for types defined in <project_name> plus
>>> external template declarations for properties, ports, ...).
>>>
>>> The rationale was to see type libraries are a global thing while
>>> components are more local -- a rationale you seem to follow given your
>>> directory structure in lib/
>>
>> Ack. Remember that Toolkit will be renamed to Typekit.
> ... which is a very welcome rename ;-)
>
>>> TaskContext* nc = RTT::loadComponent("project_name", "component_name",
>>> "NewComponent");
>>>
>>> which would search for
>>> orocos/libproject_name.so
>>> orocos/project_name/libcomponent_name.so
>>
>> May I refrase this into:
>>
>>
> You're going to be the guy that will do string manipulation in C++ ... your
> choice ;-)
>
>> which would search for
>> orocos/package.so (and looks for component_name inhere)
>> orocos/package/component_name.so
>>
>>> It also could automatically load the toolkits/transports of the said
>>> project, as the interfaces of the project's components are very likely
>>> to need it.
>>
>> Meaning you can have an orocos/package/types directory ?
> Well ... as I mentioned, I think toolkits/typekits should be listed all in the
> same place. Right now in orogen I have
>
> include/orocos/toolkits/
> lib/orocos/lib<project_name>-toolkit-gnulinux.so
>
> which I would propose to change to
>
> include/orocos/types/
> lib/orocos/types/lib<project_name>-typekit-gnulinux.so
> lib/orocos/types/lib<project_name>-transport-<transport_type>-gnulinux.so
>
>>> (note: the Ruby libraries I have do that on a more fine-grained basis
>>> since they can compute what component needs what toolkit ... thanks to
>>> model- based development)
>>>
>>> * I would keep the "lib" prefix as these libraries are not only plugins
>>> (i.e. dynamic-loadable) but also plain libraries (orogen uses them as
>>> such).
>>
>> Hmm. I wouldn't, although I acknowledge that component libs are used for
>> linking too. I don't want to see the lib prefix in user (xml) code. It
>> makes the plugin loading code complexer. If you want to satisfy everyone,
>> you'd need to search for:
>>
>>
>>
>> orocos/package.so (and looks for component_name inhere)
>> orocos/libpackage.so (and looks for component_name inhere)
>> orocos/libpackage-gnulinux.so (and looks for component_name inhere)
>> orocos/package/component_name.so
>> orocos/package/component_name-gnulinux.so
>> orocos/package/libcomponent_name.so
>> orocos/package/libcomponent_name-gnulinux.so
>> orocos/package/gnulinux/component_name.so
>> orocos/package/gnulinux/libcomponent_name.so
>>
>> So this doubles our search paths list. What about using symlinks ?
> Adding symlinks simply moves the complexity from the C++ to the CMake code. I
> don't mind either way.
>
> Sylvain
RTT 2 naming convention suggestion
On Thursday 14 January 2010 09:16:31 Herman Bruyninckx wrote:
> On Wed, 13 Jan 2010, Sylvain Joyeux wrote:
>
> Has any thought been given already to a concrete _versioning_ approach that
> can be used during runtime to make sure(?) that only version-compatible
> components can get connected? I think this problem is connected to some
> extent with the "namespaces", since the name _plus_ the version are
> basically the real semantic tags to structure the software (in source code
> form as well as binary form). The svn versions _could_ maybe serve a
> purpose here, but I am quite confident that we have to add them to the
> interface of the components in one way or another...
>
> Thoughts?
On unix systems, we only use the .so versioning scheme for component versions.
If two components depending on different installed libraries are loaded in the
same process, the behaviour is today undefined. Separating into two processes
is the safest bet for now.
Peter
RTT 2 naming convention suggestion
On Thu, 14 Jan 2010, Peter Soetens wrote:
> On Thursday 14 January 2010 09:16:31 Herman Bruyninckx wrote:
>> On Wed, 13 Jan 2010, Sylvain Joyeux wrote:
>>
>> Has any thought been given already to a concrete _versioning_ approach that
>> can be used during runtime to make sure(?) that only version-compatible
>> components can get connected? I think this problem is connected to some
>> extent with the "namespaces", since the name _plus_ the version are
>> basically the real semantic tags to structure the software (in source code
>> form as well as binary form). The svn versions _could_ maybe serve a
>> purpose here, but I am quite confident that we have to add them to the
>> interface of the components in one way or another...
>>
>> Thoughts?
>
> On unix systems, we only use the .so versioning scheme for component versions.
> If two components depending on different installed libraries are loaded in the
> same process, the behaviour is today undefined. Separating into two processes
> is the safest bet for now.
>
The binary versioning is only one aspect; there should also be a "semantic"
versioning, accessible via an API. This will be most useful/necessary for
components to know whether they can understand each others "topical data
structures" or not, and to which extent.
We have a growing number of use cases where systems have to coordinate with
each other without really having to understand the complete data structures
they can exchange...
Herman
RTT 2 naming convention suggestion
On Thu, Jan 14, 2010 at 09:16:31AM +0100, Herman Bruyninckx wrote:
> On Wed, 13 Jan 2010, Sylvain Joyeux wrote:
>
> Has any thought been given already to a concrete _versioning_ approach that
> can be used during runtime to make sure(?) that only version-compatible
> components can get connected? I think this problem is connected to some
> extent with the "namespaces", since the name _plus_ the version are
> basically the real semantic tags to structure the software (in source code
> form as well as binary form). The svn versions _could_ maybe serve a
> purpose here, but I am quite confident that we have to add them to the
> interface of the components in one way or another...
>
> Thoughts?
I think there are two types of versions: a) the version of a component
(e.g. kuka-RSI-v1.0) and the version of RTT against which it was
compiled. A often used way of including the latter in binaries is by
using git-tags and the 'git describe' command. For example running
that in a current Linux git repository gets me:
v2.6.33-rc4-22-g004b350
Which tells me I am on commit "g004b350..." which is 22 commits ahead
of tag "v2.6.33-rc4". Something like this could added to components in
the build system and be used to decide if a component to be loaded is
compatible or not.
Not so sure about versioning of components. It's a good practice to
use the latest stable...
Markus
RTT 2 naming convention suggestion
On Thu, 14 Jan 2010, Markus Klotzbuecher wrote:
> On Thu, Jan 14, 2010 at 09:16:31AM +0100, Herman Bruyninckx wrote:
>> On Wed, 13 Jan 2010, Sylvain Joyeux wrote:
>>
>> Has any thought been given already to a concrete _versioning_ approach that
>> can be used during runtime to make sure(?) that only version-compatible
>> components can get connected? I think this problem is connected to some
>> extent with the "namespaces", since the name _plus_ the version are
>> basically the real semantic tags to structure the software (in source code
>> form as well as binary form). The svn versions _could_ maybe serve a
>> purpose here, but I am quite confident that we have to add them to the
>> interface of the components in one way or another...
>>
>> Thoughts?
>
> I think there are two types of versions: a) the version of a component
> (e.g. kuka-RSI-v1.0) and the version of RTT against which it was
> compiled.
Also the "topical data structures" will have to be versioned. Independently
of the component versioning.
> A often used way of including the latter in binaries is by
> using git-tags and the 'git describe' command. For example running
> that in a current Linux git repository gets me:
>
> v2.6.33-rc4-22-g004b350
>
> Which tells me I am on commit "g004b350..." which is 22 commits ahead
> of tag "v2.6.33-rc4". Something like this could added to components in
> the build system and be used to decide if a component to be loaded is
> compatible or not.
FOr the topical data, one needs to add _semantic_ information to this raw
version number: what can one component understand from a newer/older
version of the same topical data structure.
> Not so sure about versioning of components. It's a good practice to
> use the latest stable...
...but it is bad practice to develop a framework that assumes/hopes that
all users follow that "good practice", and in addition switch over to the
newer version all at the same time :-)
Herman
RTT 2 naming convention
I agree for splitting the runtime libs and the plugins.
But i am still bothered by the multiplication of subdirectory in <prefix>/lib/orocos.
A naming convention could be enought ?
The name are long, but with a good convention (TBD), it could be simpler :
* avoid to have too many export LD_LIBRARY_PATH
* see every package in one place
* fixed pattern that avoid to have too many search rules
RTT 2 naming convention suggestion
On Thu, Jan 14, 2010 at 04:42:07PM +0100, Herman Bruyninckx wrote:
> On Thu, 14 Jan 2010, Markus Klotzbuecher wrote:
>
> > On Thu, Jan 14, 2010 at 09:16:31AM +0100, Herman Bruyninckx wrote:
> >> On Wed, 13 Jan 2010, Sylvain Joyeux wrote:
> >>
> >> Has any thought been given already to a concrete _versioning_ approach that
> >> can be used during runtime to make sure(?) that only version-compatible
> >> components can get connected? I think this problem is connected to some
> >> extent with the "namespaces", since the name _plus_ the version are
> >> basically the real semantic tags to structure the software (in source code
> >> form as well as binary form). The svn versions _could_ maybe serve a
> >> purpose here, but I am quite confident that we have to add them to the
> >> interface of the components in one way or another...
> >>
> >> Thoughts?
> >
> > I think there are two types of versions: a) the version of a component
> > (e.g. kuka-RSI-v1.0) and the version of RTT against which it was
> > compiled.
>
> Also the "topical data structures" will have to be versioned. Independently
> of the component versioning.
Yes, for instance it could consist of valid component version ranges
for each component in the topological spec.
> > A often used way of including the latter in binaries is by
> > using git-tags and the 'git describe' command. For example running
> > that in a current Linux git repository gets me:
> >
> > v2.6.33-rc4-22-g004b350
> >
> > Which tells me I am on commit "g004b350..." which is 22 commits ahead
> > of tag "v2.6.33-rc4". Something like this could added to components in
> > the build system and be used to decide if a component to be loaded is
> > compatible or not.
>
> FOr the topical data, one needs to add _semantic_ information to this raw
> version number: what can one component understand from a newer/older
> version of the same topical data structure.
Yes, for instance there could be simple text files containing mappings
of API breakages to component or framework version numbers. With that
a deployer can reason about valid combinations of components. If the
file contains a short message about the change, it could also output a
nice message and tell the user why there is an mismatch.
> > Not so sure about versioning of components. It's a good practice to
> > use the latest stable...
>
> ...but it is bad practice to develop a framework that assumes/hopes that
> all users follow that "good practice", and in addition switch over to the
> newer version all at the same time :-)
Yes I agree :-) However such versioning should be used to warn only,
if a user wants to ignore it he should be able to do so.
Markus
RTT 2 naming convention suggestion
I agree for splitting the runtime libs and the plugins.
But i am still bothered by the multiplication of subdirectory in <prefix>/lib/orocos.
A naming convention could be enought ?
The name are long, but with a good convention (TBD), it could be simpler :
RTT 2 naming convention
On Thursday 14 January 2010 11:13:45 paul [dot] chavent [..] ... wrote:
> I agree for splitting the runtime libs and the plugins.
>
> But i am still bothered by the multiplication of subdirectory in
> <prefix>/lib/orocos.
>
> A naming convention could be enought ?
>
>
>
> The name are long, but with a good convention (TBD), it could be simpler :
> * avoid to have too many export LD_LIBRARY_PATH
You will not need to set LD_LIBRARY_PATH, since the plugin loading will
explicitly look for components into these directories. If you have 'normal'
libraries, they still belong in prefix/lib. We could also settle for RPATH
which fixes this problem in any case.
> * see every package in one place
> * fixed pattern that avoid to have too many search rules
I'm also keeping an eye on how ros structures its packages and try to be
compatible with their setup. Meaning, a ros package can have a ros node and/or
one or more Orocos components.
Peter
RTT 2 naming convention suggestion
RTT 2 naming convention suggestion
Hi.
I work on a project with differents components maintained by different person on different workstation. So when i write my component, if i have "dependencies" to others, i write for example
For Future version i would like to regroup every orocos stuff in one place.
For example, lets say we have Orocos-RTT, Orocos-KDL, Orocos-OCL, Orocos-myproject. My project have mycomponent_1, mycomponent_2.
The install directory layout could be.
include orocos rtt ... kdl ... ocl ... myproject lib liborocos-rtt-xxx.so liborocos-kdl-xxx.so liborocos-ocl-xxx.so liborocos-myproject-mycomponent_1.so liborocos-myproject-mycomponent_2.soThe lib/rtt could be flattened at the root of lib.
My proposition is just an example.
The important thing is to have a naming convention and don't have too many things related to orocos too scattered.
Thanks for your reading.
Paul.