New installation location of OCL components/libraries

I'm looking into the 'component finding' problem for OCL and applications in
general. Current ocl installs its components as /usr/lib/lib*.so, which is bad
for our deployment component. The idea is to change this to
/usr/lib/orocos/lib*.so such that we can do an import of /usr/lib/orocos and
only find components instead of 987 other libraries.

The problem is that some applications (like deployer) link to these libraries
and the only reasonable solution is to add the orocos subdir into the rpath of
these applications. It works, but I might be overlooking something. This is
the structure I have right now (filenames shortened to fit within 80 columns) :

<pre>
/opt/2.0/lib/
|-- librtt-corba-gnulinux.so -> librtt-corba-gnulinux.so.1.99
|-- librtt-corba-gnulinux.so.1.99 -> librtt-corba-gnulinux.so.1.99.3
|-- librtt-corba-gnulinux.so.1.99.3
|-- librtt-gnulinux.so -> librtt-gnulinux.so.1.99
|-- librtt-gnulinux.so.1.99 -> librtt-gnulinux.so.1.99.3
|-- librtt-gnulinux.so.1.99.3
|-- librtt-mqueue-gnulinux.so -> librtt-mqueue-gnulinux.so.1.99
|-- librtt-mqueue-gnulinux.so.1.99 -> librtt-mqueue-gnulinux.so.1.99.3
|-- librtt-mqueue-gnulinux.so.1.99.3
|-- orocos
| |-- libdeployment-corba-gnulinux.so -> libdeployment-corba-
gnulinux.so.1.99
| |-- libdeployment-corba-gnulinux.so.1.99 -> libdeployment-corba-
gnulinux.so.1.99.3
| |-- libdeployment-corba-gnulinux.so.1.99.3
| |-- libdeployment-gnulinux.so -> libdeployment-gnulinux.so.1.99
| |-- libdeployment-gnulinux.so.1.99 -> libdeployment-gnulinux.so.1.99.3
| |-- libdeployment-gnulinux.so.1.99.3
| |-- libhelloworld-gnulinux.so -> libhelloworld-gnulinux.so.1.99
| |-- libhelloworld-gnulinux.so.1.99 -> libhelloworld-gnulinux.so.1.99.3
| |-- libhelloworld-gnulinux.so.1.99.3
| |-- libocl-common-gnulinux.so -> libocl-common-gnulinux.so.1.99
| |-- libocl-common-gnulinux.so.1.99 -> libocl-common-gnulinux.so.1.99.3
| |-- libocl-common-gnulinux.so.1.99.3
| |-- libreporting-gnulinux.so -> libreporting-gnulinux.so.1.99
| |-- libreporting-gnulinux.so.1.99 -> libreporting-gnulinux.so.1.99.3
| |-- libreporting-gnulinux.so.1.99.3
| |-- libtaskbrowser-gnulinux.so -> libtaskbrowser-gnulinux.so.1.99
| |-- libtaskbrowser-gnulinux.so.1.99 -> libtaskbrowser-gnulinux.so.1.99.3
| |-- libtaskbrowser-gnulinux.so.1.99.3
| |-- libtimer-gnulinux.so -> libtimer-gnulinux.so.1.99
| |-- libtimer-gnulinux.so.1.99 -> libtimer-gnulinux.so.1.99.3
| |-- libtimer-gnulinux.so.1.99.3
| |-- plugins
| | |-- librtt-marshalling-gnulinux.so -> librtt-marshalling-
gnulinux.so.1.99.3
| | |-- librtt-marshalling-gnulinux.so.1.99.3
| | |-- librtt-scripting-gnulinux.so -> librtt-scripting-
gnulinux.so.1.99.3
| | `-- librtt-scripting-gnulinux.so.1.99.3
| `-- types
| |-- librtt-corba-typekit-gnulinux.so.1.99.3
| |-- librtt-mqueue-typekit-gnulinux.so.1.99.3
| `-- librtt-typekit-gnulinux.so.1.99.3
`-- pkgconfig
|-- ocl-gnulinux.pc
|-- rtt-corba-gnulinux.pc
|-- rtt-gnulinux.pc
`-- rtt-mqueue-gnulinux.pc
</pre>

So normal libraries (rtt, transport helpers etc) belong in lib/ then
components in
lib/orocos and the plugins and types in the respective subdirectories.

This is quite a change, but I hope it will resolve most future issues people
have now with the RTT_COMPONENT_PATH

Peter

New installation location of OCL components/libraries

On Jun 30, 2010, at 11:48 , Peter Soetens wrote:

> I'm looking into the 'component finding' problem for OCL and applications in
> general. Current ocl installs its components as /usr/lib/lib*.so, which is bad
> for our deployment component. The idea is to change this to
> /usr/lib/orocos/lib*.so such that we can do an import of /usr/lib/orocos and
> only find components instead of 987 other libraries.
>
> The problem is that some applications (like deployer) link to these libraries
> and the only reasonable solution is to add the orocos subdir into the rpath of
> these applications. It works, but I might be overlooking something. This is
> the structure I have right now (filenames shortened to fit within 80 columns) :
>
> <pre>
> /opt/2.0/lib/
> |-- librtt-corba-gnulinux.so -> librtt-corba-gnulinux.so.1.99
> |-- librtt-corba-gnulinux.so.1.99 -> librtt-corba-gnulinux.so.1.99.3
> |-- librtt-corba-gnulinux.so.1.99.3
> |-- librtt-gnulinux.so -> librtt-gnulinux.so.1.99
> |-- librtt-gnulinux.so.1.99 -> librtt-gnulinux.so.1.99.3
> |-- librtt-gnulinux.so.1.99.3
> |-- librtt-mqueue-gnulinux.so -> librtt-mqueue-gnulinux.so.1.99
> |-- librtt-mqueue-gnulinux.so.1.99 -> librtt-mqueue-gnulinux.so.1.99.3
> |-- librtt-mqueue-gnulinux.so.1.99.3
> |-- orocos
> | |-- libdeployment-corba-gnulinux.so -> libdeployment-corba-
> gnulinux.so.1.99
> | |-- libdeployment-corba-gnulinux.so.1.99 -> libdeployment-corba-
> gnulinux.so.1.99.3
> | |-- libdeployment-corba-gnulinux.so.1.99.3
> | |-- libdeployment-gnulinux.so -> libdeployment-gnulinux.so.1.99
> | |-- libdeployment-gnulinux.so.1.99 -> libdeployment-gnulinux.so.1.99.3
> | |-- libdeployment-gnulinux.so.1.99.3
> | |-- libhelloworld-gnulinux.so -> libhelloworld-gnulinux.so.1.99
> | |-- libhelloworld-gnulinux.so.1.99 -> libhelloworld-gnulinux.so.1.99.3
> | |-- libhelloworld-gnulinux.so.1.99.3
> | |-- libocl-common-gnulinux.so -> libocl-common-gnulinux.so.1.99
> | |-- libocl-common-gnulinux.so.1.99 -> libocl-common-gnulinux.so.1.99.3
> | |-- libocl-common-gnulinux.so.1.99.3
> | |-- libreporting-gnulinux.so -> libreporting-gnulinux.so.1.99
> | |-- libreporting-gnulinux.so.1.99 -> libreporting-gnulinux.so.1.99.3
> | |-- libreporting-gnulinux.so.1.99.3
> | |-- libtaskbrowser-gnulinux.so -> libtaskbrowser-gnulinux.so.1.99
> | |-- libtaskbrowser-gnulinux.so.1.99 -> libtaskbrowser-gnulinux.so.1.99.3
> | |-- libtaskbrowser-gnulinux.so.1.99.3
> | |-- libtimer-gnulinux.so -> libtimer-gnulinux.so.1.99
> | |-- libtimer-gnulinux.so.1.99 -> libtimer-gnulinux.so.1.99.3
> | |-- libtimer-gnulinux.so.1.99.3
> | |-- plugins
> | | |-- librtt-marshalling-gnulinux.so -> librtt-marshalling-
> gnulinux.so.1.99.3
> | | |-- librtt-marshalling-gnulinux.so.1.99.3
> | | |-- librtt-scripting-gnulinux.so -> librtt-scripting-
> gnulinux.so.1.99.3
> | | `-- librtt-scripting-gnulinux.so.1.99.3
> | `-- types
> | |-- librtt-corba-typekit-gnulinux.so.1.99.3
> | |-- librtt-mqueue-typekit-gnulinux.so.1.99.3
> | `-- librtt-typekit-gnulinux.so.1.99.3
> `-- pkgconfig
> |-- ocl-gnulinux.pc
> |-- rtt-corba-gnulinux.pc
> |-- rtt-gnulinux.pc
> `-- rtt-mqueue-gnulinux.pc
> </pre>
>
> So normal libraries (rtt, transport helpers etc) belong in lib/ then
> components in
> lib/orocos and the plugins and types in the respective subdirectories.
>
> This is quite a change, but I hope it will resolve most future issues people
> have now with the RTT_COMPONENT_PATH
>
> Peter

So what gets loaded when? Is the deployer automatically doing an import of all of /usr/lib/orocos? If so, is there a way to prevent that? I presume that installing somewhere besides /usr/lib will be taken care of (it's /opt/2.0 above).

Does the deployer support multiple paths in RTT_COMPONENT_PATH?

Separately, why do RTT libraries have an "rtt-" prefix, but only one OCL library does? Why aren't all OCL libraries "libocl-XXX"?

S

New installation location of OCL components/libraries

On Thursday 01 July 2010 13:34:12 S Roderick wrote:
> On Jun 30, 2010, at 11:48 , Peter Soetens wrote:
> > I'm looking into the 'component finding' problem for OCL and applications
> > in general. Current ocl installs its components as /usr/lib/lib*.so,
> > which is bad for our deployment component. The idea is to change this to
> > /usr/lib/orocos/lib*.so such that we can do an import of /usr/lib/orocos
> > and only find components instead of 987 other libraries.
> >
...
>
> So what gets loaded when? Is the deployer automatically doing an import of
> all of /usr/lib/orocos? If so, is there a way to prevent that? I presume
> that installing somewhere besides /usr/lib will be taken care of (it's
> /opt/2.0 above).

It will import ${OROCOS_INSTALL}/lib/orocos if:
* no RTT_COMPONENT_PATH env variable was set
* no RTT_COMPONENT_PATH property was set in DeploymentComponent (using a site
file).

In my example, OROCOS_INSTALL was set to /opt/2.0 when building OCL. We need
this path to find the RTT typekits and plugins anyway.

>
> Does the deployer support multiple paths in RTT_COMPONENT_PATH?

Of course !!! Just like plain 'Unix' PATH. It's *not* recursive. I'm pondering
about a recursive search that only considers a child directory if it contains
a 'manifest.xml' file. This would allow us to work closely with ros-style
layouts of applications (ie component libs are spread over package
directories).

>
> Separately, why do RTT libraries have an "rtt-" prefix, but only one OCL
> library does? Why aren't all OCL libraries "libocl-XXX"?

I'll probably open the gates of angry-user-feedback hell when I'm doing more
renames, especially if folks directly link to taskbrowser and deployer libs.

OCL's refactoring into multiple repositories (separating infrastructure
components maintained by me from application components developed by PMA) is
also still on the list. So I'm not sure the name OCL will even survive...
'Orocos-taskbrowser' and 'orocos-deployement' don't look that bad in that
respect.

Any suggestions welcome...

Peter

New installation location of OCL components/libraries

On Jul 2, 2010, at 05:55 , Peter Soetens wrote:

> On Thursday 01 July 2010 13:34:12 S Roderick wrote:
>> On Jun 30, 2010, at 11:48 , Peter Soetens wrote:
>>> I'm looking into the 'component finding' problem for OCL and applications
>>> in general. Current ocl installs its components as /usr/lib/lib*.so,
>>> which is bad for our deployment component. The idea is to change this to
>>> /usr/lib/orocos/lib*.so such that we can do an import of /usr/lib/orocos
>>> and only find components instead of 987 other libraries.
>>>
> ...
>>
>> So what gets loaded when? Is the deployer automatically doing an import of
>> all of /usr/lib/orocos? If so, is there a way to prevent that? I presume
>> that installing somewhere besides /usr/lib will be taken care of (it's
>> /opt/2.0 above).
>
> It will import ${OROCOS_INSTALL}/lib/orocos if:
> * no RTT_COMPONENT_PATH env variable was set
> * no RTT_COMPONENT_PATH property was set in DeploymentComponent (using a site
> file).
>
> In my example, OROCOS_INSTALL was set to /opt/2.0 when building OCL. We need
> this path to find the RTT typekits and plugins anyway.

Ok, so the system will automatically import all typekits and plugins. How much has the definition of a "typekit" or a "plugin" changed from v1 to v2? (ie what is actually getting imported).

>> Does the deployer support multiple paths in RTT_COMPONENT_PATH?
>
> Of course !!! Just like plain 'Unix' PATH. It's *not* recursive. I'm pondering
> about a recursive search that only considers a child directory if it contains
> a 'manifest.xml' file. This would allow us to work closely with ros-style
> layouts of applications (ie component libs are spread over package
> directories).
>
>>
>> Separately, why do RTT libraries have an "rtt-" prefix, but only one OCL
>> library does? Why aren't all OCL libraries "libocl-XXX"?
>
> I'll probably open the gates of angry-user-feedback hell when I'm doing more
> renames, especially if folks directly link to taskbrowser and deployer libs.

What, you haven't seen any of that feedback yet?! ;-)

> OCL's refactoring into multiple repositories (separating infrastructure
> components maintained by me from application components developed by PMA) is
> also still on the list. So I'm not sure the name OCL will even survive...
> 'Orocos-taskbrowser' and 'orocos-deployement' don't look that bad in that
> respect.

I'm against this suggestion. Maintainers come and go. It also will bundle essentially functionally arbitrary chunks of code together. Why not stick with a functional separation? Isn't this about cohesiveness? If we go by maintainer, ditch OCL all together and provide github (or similar) links for each maintainer! Otherwise we're making it easier on the developer rather than easier on the user. That's a bad policy.

S

New installation location of OCL components/libraries

On Friday 02 July 2010 12:58:37 Stephen Roderick wrote:
> On Jul 2, 2010, at 05:55 , Peter Soetens wrote:
> > On Thursday 01 July 2010 13:34:12 S Roderick wrote:
> >> On Jun 30, 2010, at 11:48 , Peter Soetens wrote:
> >>> I'm looking into the 'component finding' problem for OCL and
> >>> applications in general. Current ocl installs its components as
> >>> /usr/lib/lib*.so, which is bad for our deployment component. The idea
> >>> is to change this to /usr/lib/orocos/lib*.so such that we can do an
> >>> import of /usr/lib/orocos and only find components instead of 987 other
> >>> libraries.
> >
> > ...
> >
> >> So what gets loaded when? Is the deployer automatically doing an import
> >> of all of /usr/lib/orocos? If so, is there a way to prevent that? I
> >> presume that installing somewhere besides /usr/lib will be taken care of
> >> (it's /opt/2.0 above).
> >
> > It will import ${OROCOS_INSTALL}/lib/orocos if:
> > * no RTT_COMPONENT_PATH env variable was set
> > * no RTT_COMPONENT_PATH property was set in DeploymentComponent (using a
> > site file).
> >
> > In my example, OROCOS_INSTALL was set to /opt/2.0 when building OCL. We
> > need this path to find the RTT typekits and plugins anyway.
>
> Ok, so the system will automatically import all typekits and plugins. How
> much has the definition of a "typekit" or a "plugin" changed from v1 to
> v2? (ie what is actually getting imported).

The 'C' API of plugins was only slightly extended with one extra function:
getRTTTargetName() which is optional. Only loadRTTPlugin(TaskContext*) is
mandatory btw.

The C++ API of transport plugins (TransportPlugin) which is in addition to
this 'C' API, has been slightly extended to with respect to getName() and
getTransportName().

typekits provide an subclass of TypekitPlugin and register that class using
RTT_TYPEKIT_PLUGIN. This class is then queried once to load its types or
transports into the process.
For normal 'plugins', no class must be implemented and the presence of the
Plugin.hpp functions are enough.
The macro RTT_SERVICE_PLUGIN defines these functions in case you subclassed
ServiceProvider in your plugin (like scripting and marshalling do). For each
plugin that is not a typekit, you can request that it is loaded into a
TaskContext. The plugin can refuse this.

This needs to be documented better in the plugin manual....

>
> >> Does the deployer support multiple paths in RTT_COMPONENT_PATH?
> >
> > Of course !!! Just like plain 'Unix' PATH. It's *not* recursive. I'm
> > pondering about a recursive search that only considers a child directory
> > if it contains a 'manifest.xml' file. This would allow us to work closely
> > with ros-style layouts of applications (ie component libs are spread over
> > package directories).
> >
> >> Separately, why do RTT libraries have an "rtt-" prefix, but only one OCL
> >> library does? Why aren't all OCL libraries "libocl-XXX"?
> >
> > I'll probably open the gates of angry-user-feedback hell when I'm doing
> > more renames, especially if folks directly link to taskbrowser and
> > deployer libs.
>
> What, you haven't seen any of that feedback yet?! ;-)

Well, let's say that the doors were already slightly ajar.

>
> > OCL's refactoring into multiple repositories (separating infrastructure
> > components maintained by me from application components developed by PMA)
> > is also still on the list. So I'm not sure the name OCL will even
> > survive... 'Orocos-taskbrowser' and 'orocos-deployement' don't look that
> > bad in that respect.
>
> I'm against this suggestion. Maintainers come and go. It also will bundle
> essentially functionally arbitrary chunks of code together.

Isn't this what OCL is today ?

> Why not stick
> with a functional separation? Isn't this about cohesiveness?

It's what I try to achieve !

> If we go by
> maintainer, ditch OCL all together and provide github (or similar) links
> for each maintainer! Otherwise we're making it easier on the developer
> rather than easier on the user. That's a bad policy.

I agree that ease of use is on the first place. We have however a bunch of
unmaintained code in OCL which, I as a maintainer, hate to have in there.
The main painpoint is that I don't feel responsible for maintaining that code,
I can't test it (other than that it compiles), and can only wait for patches,
which don't come. In the meantime, the people that wrote that code are setting
up different repositories and are maintaining these. I'd rather move the code
to that place and let it to them to decide to remove it or keep it in.

Actually, I think we agree on the approach to take, make OCL a must-have lib
for every user, and put all must-haves into OCL, while we put all 'lab-X',
'lab-Y' specific code in their own repositories.

Or not ?

Peter

New installation location of OCL components/libraries

Definitely yes.

I'm a big fan of small packages/repositories that can be selected by the
user to meet their needs, with a good tool that automates making sure
essentials are installed. My experience with Player and Gearbox has
soured my taste for monolithic distributions. For an example, see your
local Linux distribution, or ROS. :)

I know we've spoken about this stuff in the past, Peter. Stuff is slowly
happening. There's a patch on the ROS trac, and although it did turn out
to be not quite where WG wants to go, it looks like we'll get that
separate package manager soon now.

Geoff

On 02/07/10 21:02, Peter Soetens wrote:
> I agree that ease of use is on the first place. We have however a bunch of
> unmaintained code in OCL which, I as a maintainer, hate to have in there.
> The main painpoint is that I don't feel responsible for maintaining that code,
> I can't test it (other than that it compiles), and can only wait for patches,
> which don't come. In the meantime, the people that wrote that code are setting
> up different repositories and are maintaining these. I'd rather move the code
> to that place and let it to them to decide to remove it or keep it in.
>
> Actually, I think we agree on the approach to take, make OCL a must-have lib
> for every user, and put all must-haves into OCL, while we put all 'lab-X',
> 'lab-Y' specific code in their own repositories.
>
> Or not ?

New installation location of OCL components/libraries

On Jul 2, 2010, at 08:02 , Peter Soetens wrote:

> On Friday 02 July 2010 12:58:37 Stephen Roderick wrote:
>> On Jul 2, 2010, at 05:55 , Peter Soetens wrote:
>>> On Thursday 01 July 2010 13:34:12 S Roderick wrote:
>>>> On Jun 30, 2010, at 11:48 , Peter Soetens wrote:
>>>>> I'm looking into the 'component finding' problem for OCL and
>>>>> applications in general. Current ocl installs its components as
>>>>> /usr/lib/lib*.so, which is bad for our deployment component. The idea
>>>>> is to change this to /usr/lib/orocos/lib*.so such that we can do an
>>>>> import of /usr/lib/orocos and only find components instead of 987 other
>>>>> libraries.
>>>
>>> ...
>>>
>>>> So what gets loaded when? Is the deployer automatically doing an import
>>>> of all of /usr/lib/orocos? If so, is there a way to prevent that? I
>>>> presume that installing somewhere besides /usr/lib will be taken care of
>>>> (it's /opt/2.0 above).
>>>
>>> It will import ${OROCOS_INSTALL}/lib/orocos if:
>>> * no RTT_COMPONENT_PATH env variable was set
>>> * no RTT_COMPONENT_PATH property was set in DeploymentComponent (using a
>>> site file).
>>>
>>> In my example, OROCOS_INSTALL was set to /opt/2.0 when building OCL. We
>>> need this path to find the RTT typekits and plugins anyway.
>>
>> Ok, so the system will automatically import all typekits and plugins. How
>> much has the definition of a "typekit" or a "plugin" changed from v1 to
>> v2? (ie what is actually getting imported).
>
> The 'C' API of plugins was only slightly extended with one extra function:
> getRTTTargetName() which is optional. Only loadRTTPlugin(TaskContext*) is
> mandatory btw.
>
> The C++ API of transport plugins (TransportPlugin) which is in addition to
> this 'C' API, has been slightly extended to with respect to getName() and
> getTransportName().
>
> typekits provide an subclass of TypekitPlugin and register that class using
> RTT_TYPEKIT_PLUGIN. This class is then queried once to load its types or
> transports into the process.
> For normal 'plugins', no class must be implemented and the presence of the
> Plugin.hpp functions are enough.
> The macro RTT_SERVICE_PLUGIN defines these functions in case you subclassed
> ServiceProvider in your plugin (like scripting and marshalling do). For each
> plugin that is not a typekit, you can request that it is loaded into a
> TaskContext. The plugin can refuse this.
>
> This needs to be documented better in the plugin manual....
>
>>
>>>> Does the deployer support multiple paths in RTT_COMPONENT_PATH?
>>>
>>> Of course !!! Just like plain 'Unix' PATH. It's *not* recursive. I'm
>>> pondering about a recursive search that only considers a child directory
>>> if it contains a 'manifest.xml' file. This would allow us to work closely
>>> with ros-style layouts of applications (ie component libs are spread over
>>> package directories).
>>>
>>>> Separately, why do RTT libraries have an "rtt-" prefix, but only one OCL
>>>> library does? Why aren't all OCL libraries "libocl-XXX"?
>>>
>>> I'll probably open the gates of angry-user-feedback hell when I'm doing
>>> more renames, especially if folks directly link to taskbrowser and
>>> deployer libs.
>>
>> What, you haven't seen any of that feedback yet?! ;-)
>
> Well, let's say that the doors were already slightly ajar.
>
>>
>>> OCL's refactoring into multiple repositories (separating infrastructure
>>> components maintained by me from application components developed by PMA)
>>> is also still on the list. So I'm not sure the name OCL will even
>>> survive... 'Orocos-taskbrowser' and 'orocos-deployement' don't look that
>>> bad in that respect.
>>
>> I'm against this suggestion. Maintainers come and go. It also will bundle
>> essentially functionally arbitrary chunks of code together.
>
> Isn't this what OCL is today ?
>
>> Why not stick
>> with a functional separation? Isn't this about cohesiveness?
>
> It's what I try to achieve !
>
>> If we go by
>> maintainer, ditch OCL all together and provide github (or similar) links
>> for each maintainer! Otherwise we're making it easier on the developer
>> rather than easier on the user. That's a bad policy.
>
> I agree that ease of use is on the first place. We have however a bunch of
> unmaintained code in OCL which, I as a maintainer, hate to have in there.
> The main painpoint is that I don't feel responsible for maintaining that code,
> I can't test it (other than that it compiles), and can only wait for patches,
> which don't come. In the meantime, the people that wrote that code are setting
> up different repositories and are maintaining these. I'd rather move the code
> to that place and let it to them to decide to remove it or keep it in.
>
> Actually, I think we agree on the approach to take, make OCL a must-have lib
> for every user, and put all must-haves into OCL, while we put all 'lab-X',
> 'lab-Y' specific code in their own repositories.

Yes. Do you have an initial list of what will stay in OCL (the so called "infrastructure components")?

I actually think OCL has a degree of functional cohesiveness in its existing structure. It can always be improved upon, but it's not terrible now.
S

New installation location of OCL components/libraries

On Mon, Jul 5, 2010 at 2:03 PM, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
>
> On Jul 2, 2010, at 08:02 , Peter Soetens wrote:
...
> > Actually, I think we agree on the approach to take, make OCL a must-have lib
> > for every user, and put all must-haves into OCL, while we put all  'lab-X',
> > 'lab-Y' specific code in their own repositories.
>
> Yes. Do you have an initial list of what will stay in OCL (the so called "infrastructure
> components")?

ocl typekit, reporting, taskbrowser, deployment, helloworld, timer,
logging + binaries.

I'm still in doubt of some parts of 'hardware'. It's just most of the
time easier to directly map your device into a component than to go
through some 'framework' (midlayer problem).

I'm also seriously considering to have a not real-time 'print'
function in the scripting language in order to get rid of HMIConsole .

Peter
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

New installation location of OCL components/libraries

On Fri, Jul 2, 2010 at 12:58, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
> On Jul 2, 2010, at 05:55 , Peter Soetens wrote:
>
>> On Thursday 01 July 2010 13:34:12 S Roderick wrote:
>>> On Jun 30, 2010, at 11:48 , Peter Soetens wrote:
>>>> I'm looking into the 'component finding' problem for OCL and applications
>>>> in general. Current ocl installs its components as /usr/lib/lib*.so,
>>>> which is bad for our deployment component. The idea is to change this to
>>>> /usr/lib/orocos/lib*.so such that we can do an import of /usr/lib/orocos
>>>> and only find components instead of 987 other libraries.
>>>>
>> ...
>>>
>>> So what gets loaded when? Is the deployer automatically doing an import of
>>> all of /usr/lib/orocos? If so, is there a way to prevent that? I presume
>>> that installing somewhere besides /usr/lib will be taken care of (it's
>>> /opt/2.0 above).
>>
>> It will import ${OROCOS_INSTALL}/lib/orocos if:
>> * no RTT_COMPONENT_PATH env variable was set
>> * no RTT_COMPONENT_PATH property was set in DeploymentComponent (using a site
>> file).
>>
>> In my example, OROCOS_INSTALL was set to /opt/2.0 when building OCL. We need
>> this path to find the RTT typekits and plugins anyway.
>
> Ok, so the system will automatically import all typekits and plugins. How much has the definition of a "typekit" or a "plugin" changed from v1 to v2? (ie what is actually getting imported).
>
>>> Does the deployer support multiple paths in RTT_COMPONENT_PATH?
>>
>> Of course !!! Just like plain 'Unix' PATH. It's *not* recursive. I'm pondering
>> about a recursive search that only considers a child directory if it contains
>> a 'manifest.xml' file. This would allow us to work closely with ros-style
>> layouts of applications (ie component libs are spread over package
>> directories).
>>
>>>
>>> Separately, why do RTT libraries have an "rtt-" prefix, but only one OCL
>>> library does? Why aren't all OCL libraries "libocl-XXX"?
>>
>> I'll probably open the gates of angry-user-feedback hell when I'm doing more
>> renames, especially if folks directly link to taskbrowser and deployer libs.
>
> What, you haven't seen any of that feedback yet?! ;-)
>
>> OCL's refactoring into multiple repositories (separating infrastructure
>> components maintained by me from application components developed by PMA) is
>> also still on the list. So I'm not sure the name OCL will even survive...
>> 'Orocos-taskbrowser' and 'orocos-deployement' don't look that bad in that
>> respect.
>
> I'm against this suggestion. Maintainers come and go. It also will bundle essentially functionally arbitrary chunks of code together. Why not stick with a functional separation? Isn't this about cohesiveness? If we go by maintainer, ditch OCL all together and provide github (or similar) links for each maintainer! Otherwise we're making it easier on the developer rather than easier on the user. That's a bad policy.
>
> S
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

Is this the thread and work where you will provide the option for the
deployment component to provide XML component descriptions of the
components found in the libraries? Will the directory where the
component descriptors be user defined or will you have have a specific
directory like 'component_library"? Will the component library have
separate directories for Orocos provided components and another
directory for user provided components?

-H

New installation location of OCL components/libraries

On Friday 02 July 2010 13:36:37 Hugo Garcia wrote:
> On Fri, Jul 2, 2010 at 12:58, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
> > On Jul 2, 2010, at 05:55 , Peter Soetens wrote:
> >> On Thursday 01 July 2010 13:34:12 S Roderick wrote:
> >>> On Jun 30, 2010, at 11:48 , Peter Soetens wrote:
> >>>> I'm looking into the 'component finding' problem for OCL and
> >>>> applications in general. Current ocl installs its components as
> >>>> /usr/lib/lib*.so, which is bad for our deployment component. The idea
> >>>> is to change this to /usr/lib/orocos/lib*.so such that we can do an
> >>>> import of /usr/lib/orocos and only find components instead of 987
> >>>> other libraries.
> >>
> >> ...
> >>
> >>> So what gets loaded when? Is the deployer automatically doing an import
> >>> of all of /usr/lib/orocos? If so, is there a way to prevent that? I
> >>> presume that installing somewhere besides /usr/lib will be taken care
> >>> of (it's /opt/2.0 above).
> >>
> >> It will import ${OROCOS_INSTALL}/lib/orocos if:
> >> * no RTT_COMPONENT_PATH env variable was set
> >> * no RTT_COMPONENT_PATH property was set in DeploymentComponent (using a
> >> site file).
> >>
> >> In my example, OROCOS_INSTALL was set to /opt/2.0 when building OCL. We
> >> need this path to find the RTT typekits and plugins anyway.
> >
> > Ok, so the system will automatically import all typekits and plugins. How
> > much has the definition of a "typekit" or a "plugin" changed from v1 to
> > v2? (ie what is actually getting imported).
> >
> >>> Does the deployer support multiple paths in RTT_COMPONENT_PATH?
> >>
> >> Of course !!! Just like plain 'Unix' PATH. It's *not* recursive. I'm
> >> pondering about a recursive search that only considers a child directory
> >> if it contains a 'manifest.xml' file. This would allow us to work
> >> closely with ros-style layouts of applications (ie component libs are
> >> spread over package directories).
> >>
> >>> Separately, why do RTT libraries have an "rtt-" prefix, but only one
> >>> OCL library does? Why aren't all OCL libraries "libocl-XXX"?
> >>
> >> I'll probably open the gates of angry-user-feedback hell when I'm doing
> >> more renames, especially if folks directly link to taskbrowser and
> >> deployer libs.
> >
> > What, you haven't seen any of that feedback yet?! ;-)
> >
> >> OCL's refactoring into multiple repositories (separating infrastructure
> >> components maintained by me from application components developed by
> >> PMA) is also still on the list. So I'm not sure the name OCL will even
> >> survive... 'Orocos-taskbrowser' and 'orocos-deployement' don't look that
> >> bad in that respect.
> >
> > I'm against this suggestion. Maintainers come and go. It also will bundle
> > essentially functionally arbitrary chunks of code together. Why not stick
> > with a functional separation? Isn't this about cohesiveness? If we go by
> > maintainer, ditch OCL all together and provide github (or similar) links
> > for each maintainer! Otherwise we're making it easier on the developer
> > rather than easier on the user. That's a bad policy.
> >
> > S
> > --
> > Orocos-Dev mailing list
> > Orocos-Dev [..] ...
> > http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
> Is this the thread and work where you will provide the option for the
> deployment component to provide XML component descriptions of the
> components found in the libraries?

No, but it would be an excellent example as an RTT v2 plugin. It could be
loaded in the deployment component, iterate over all peers and generate these
files for each peer. Different plugins could generate different file formats. Our
marshalling plugin is already doing something like that: it scans the
properties of the current component and writes them to a file.

> Will the directory where the
> component descriptors be user defined or will you have have a specific
> directory like 'component_library"?

This is part of a larger problem, related to manifest.xml files and any meta-
file that tools need to work with our components. I would install any meta file
with the component library in the same location. Where components are
installed is up to the user. He'll just have to add this installation path to
his RTT_COMPONENT_PATH

> Will the component library have
> separate directories for Orocos provided components and another
> directory for user provided components?

Orocos installs its components in [/usr]/lib/orocos, It doesn't matter if user
components install there too or in another location. This will only have effect
on the RTT_COMPONENT_PATH environment variable.

Peter

New installation location of OCL components/libraries

On Wed, Jun 30, 2010 at 05:48:00PM +0200, Peter Soetens wrote:
> I'm looking into the 'component finding' problem for OCL and applications in
> general. Current ocl installs its components as /usr/lib/lib*.so, which is bad
> for our deployment component. The idea is to change this to
> /usr/lib/orocos/lib*.so such that we can do an import of /usr/lib/orocos and
> only find components instead of 987 other libraries.
>
> The problem is that some applications (like deployer) link to these libraries
> and the only reasonable solution is to add the orocos subdir into the rpath of
> these applications. It works, but I might be overlooking something. This is
> the structure I have right now (filenames shortened to fit within 80 columns) :

Good!

Remember that many people do not want to install the beast but work
from a local src tree. That workflow should not be complicated by any
changes.

Markus

New installation location of OCL components/libraries

This is the way to go, I think. We're not living in an age where every
byte on disc must be preserved, so it's reasonable to organise things in
lib a bit better if you have a lot of libraries. :)

Re the rpath setting: it solves this problem, but if users do strange
things like copy files around you may get some odd error reports. Not a
reason to not use rpath, just something to watch out for.

Geoff

On 01/07/10 00:48, Peter Soetens wrote:
> I'm looking into the 'component finding' problem for OCL and applications in
> general. Current ocl installs its components as /usr/lib/lib*.so, which is bad
> for our deployment component. The idea is to change this to
> /usr/lib/orocos/lib*.so such that we can do an import of /usr/lib/orocos and
> only find components instead of 987 other libraries.
>
> The problem is that some applications (like deployer) link to these libraries
> and the only reasonable solution is to add the orocos subdir into the rpath of
> these applications. It works, but I might be overlooking something. This is
> the structure I have right now (filenames shortened to fit within 80 columns) :
>
> <pre>
> /opt/2.0/lib/
> |-- librtt-corba-gnulinux.so -> librtt-corba-gnulinux.so.1.99
> |-- librtt-corba-gnulinux.so.1.99 -> librtt-corba-gnulinux.so.1.99.3
> |-- librtt-corba-gnulinux.so.1.99.3
> |-- librtt-gnulinux.so -> librtt-gnulinux.so.1.99
> |-- librtt-gnulinux.so.1.99 -> librtt-gnulinux.so.1.99.3
> |-- librtt-gnulinux.so.1.99.3
> |-- librtt-mqueue-gnulinux.so -> librtt-mqueue-gnulinux.so.1.99
> |-- librtt-mqueue-gnulinux.so.1.99 -> librtt-mqueue-gnulinux.so.1.99.3
> |-- librtt-mqueue-gnulinux.so.1.99.3
> |-- orocos
> | |-- libdeployment-corba-gnulinux.so -> libdeployment-corba-
> gnulinux.so.1.99
> | |-- libdeployment-corba-gnulinux.so.1.99 -> libdeployment-corba-
> gnulinux.so.1.99.3
> | |-- libdeployment-corba-gnulinux.so.1.99.3
> | |-- libdeployment-gnulinux.so -> libdeployment-gnulinux.so.1.99
> | |-- libdeployment-gnulinux.so.1.99 -> libdeployment-gnulinux.so.1.99.3
> | |-- libdeployment-gnulinux.so.1.99.3
> | |-- libhelloworld-gnulinux.so -> libhelloworld-gnulinux.so.1.99
> | |-- libhelloworld-gnulinux.so.1.99 -> libhelloworld-gnulinux.so.1.99.3
> | |-- libhelloworld-gnulinux.so.1.99.3
> | |-- libocl-common-gnulinux.so -> libocl-common-gnulinux.so.1.99
> | |-- libocl-common-gnulinux.so.1.99 -> libocl-common-gnulinux.so.1.99.3
> | |-- libocl-common-gnulinux.so.1.99.3
> | |-- libreporting-gnulinux.so -> libreporting-gnulinux.so.1.99
> | |-- libreporting-gnulinux.so.1.99 -> libreporting-gnulinux.so.1.99.3
> | |-- libreporting-gnulinux.so.1.99.3
> | |-- libtaskbrowser-gnulinux.so -> libtaskbrowser-gnulinux.so.1.99
> | |-- libtaskbrowser-gnulinux.so.1.99 -> libtaskbrowser-gnulinux.so.1.99.3
> | |-- libtaskbrowser-gnulinux.so.1.99.3
> | |-- libtimer-gnulinux.so -> libtimer-gnulinux.so.1.99
> | |-- libtimer-gnulinux.so.1.99 -> libtimer-gnulinux.so.1.99.3
> | |-- libtimer-gnulinux.so.1.99.3
> | |-- plugins
> | | |-- librtt-marshalling-gnulinux.so -> librtt-marshalling-
> gnulinux.so.1.99.3
> | | |-- librtt-marshalling-gnulinux.so.1.99.3
> | | |-- librtt-scripting-gnulinux.so -> librtt-scripting-
> gnulinux.so.1.99.3
> | | `-- librtt-scripting-gnulinux.so.1.99.3
> | `-- types
> | |-- librtt-corba-typekit-gnulinux.so.1.99.3
> | |-- librtt-mqueue-typekit-gnulinux.so.1.99.3
> | `-- librtt-typekit-gnulinux.so.1.99.3
> `-- pkgconfig
> |-- ocl-gnulinux.pc
> |-- rtt-corba-gnulinux.pc
> |-- rtt-gnulinux.pc
> `-- rtt-mqueue-gnulinux.pc
> </pre>
>
> So normal libraries (rtt, transport helpers etc) belong in lib/ then
> components in
> lib/orocos and the plugins and types in the respective subdirectories.
>
> This is quite a change, but I hope it will resolve most future issues people
> have now with the RTT_COMPONENT_PATH
>
> Peter