Hello,
what's the state of the debian package generator on the rtt master branch?
Thank you,
Philippe
Orocos Real-Time Toolkit
Smarter realtime. Safer threads
Orocos Real-Time ToolkitSmarter realtime. Safer threads
|
|
Debian package
On Friday 10 December 2010 18:04:53 Philippe Hamelin wrote:
> Hello,
>
> what's the state of the debian package generator on the rtt master branch?
>
I have packaged rtt + ocl on the toolchain-2.2 branch and there it works. I
also tested if the deployer can find the plugins etc. This is not yet ported to
master, but for now, you may consider toolchain-2.2 as most
stable/tested/working.
Note that the debian packages install in /usr/lib/orocos-[lxrt|gnulinux|
xenomai] in order to support multi-target installs. The deployer/plugin
loaders know this.
Peter
Debian package
On 12/10/2010 09:41 PM, Peter Soetens wrote:
> On Friday 10 December 2010 18:04:53 Philippe Hamelin wrote:
>> Hello,
>>
>> what's the state of the debian package generator on the rtt master branch?
>>
>
> I have packaged rtt + ocl on the toolchain-2.2 branch and there it works. I
> also tested if the deployer can find the plugins etc. This is not yet ported to
> master, but for now, you may consider toolchain-2.2 as most
> stable/tested/working.
>
> Note that the debian packages install in /usr/lib/orocos-[lxrt|gnulinux|
> xenomai] in order to support multi-target installs. The deployer/plugin
> loaders know this.
Wasn't the decided strategy to keep on having libraries with a
-${OROCOS_TARGET} suffix ? I.e. orocos/types/libhokuyo-typekit-gnulinux.so
That's what oroGen does and I thought it was what we decided ...
Sylvain
Component filenames (was: Debian package)
On Monday 20 December 2010 08:36:01 Sylvain Joyeux wrote:
> On 12/10/2010 09:41 PM, Peter Soetens wrote:
> > On Friday 10 December 2010 18:04:53 Philippe Hamelin wrote:
> >> Hello,
> >>
> >> what's the state of the debian package generator on the rtt master
> >> branch?
> >
> > I have packaged rtt + ocl on the toolchain-2.2 branch and there it works.
> > I also tested if the deployer can find the plugins etc. This is not yet
> > ported to master, but for now, you may consider toolchain-2.2 as most
> > stable/tested/working.
> >
> > Note that the debian packages install in /usr/lib/orocos-[lxrt|gnulinux|
> > xenomai] in order to support multi-target installs. The deployer/plugin
> > loaders know this.
>
> Wasn't the decided strategy to keep on having libraries with a
> -${OROCOS_TARGET} suffix ? I.e. orocos/types/libhokuyo-typekit-gnulinux.so
The -gnulinux didn't change. The 'orocos' part changed for Debian packages.
>
> That's what oroGen does and I thought it was what we decided ...
The problem is that the v2.x deployer no longer relies on the filename to
determine the target it was built for. The reason for this is that it could
not exclude files, only include files. ie, libfoo-gnulinux.so is certainly fine
on a "gnulinux" target, but libfoo.so or libfoo-bar.so is unsure. It might be
ok or not. What we do now is to explicitly state which directories to process
(ie set a path).
This surfaced during the testing of the Debian packages. We installed all libs
in lib/orocos and the deployer-gnulinux tried to load both the xenomai and
gnulinux components. That didn't work.
I agree that we need a broader discussion about this. Stephen already voiced
that he prefers to keep the -macosx suffix, even if it's not strictly necessary
on that platform, for the sake of consistency.
I prefer that the filename may be arbitrary (and thus also may include target
information) but that the directory/paths determine which files are considered.
This would support layouts like:
a)
lib/orocos/project-lxrt
lib/orocos/project-gnulinux
usage: path("../lib/orocos"); import("project-lxrt");
b)
lib/orocos-lxrt/project
lib/orocos-gnulinux/project
usage: path("../lib/orocos-lxrt"); import("project");
c) but not:
lib/orocos/project/libfoo-lxrt.so
lib/orocos/project/libfoo-gnulinux.so
d) unless you have:
lib/orocos/project/libfoo-gnulinux.so
only.
Where the latter is the 1.x behavior. I would strongly advise everyone to use
option b) since this allows you to set the path in a separate xml file or the
RTT_COMPONENT_PATH environment variable.
What do you guys think ?
Peter
Component filenames
On 12/20/2010 09:30 AM, Peter Soetens wrote:
> On Monday 20 December 2010 08:36:01 Sylvain Joyeux wrote:
>> On 12/10/2010 09:41 PM, Peter Soetens wrote:
>>> On Friday 10 December 2010 18:04:53 Philippe Hamelin wrote:
>>>> Hello,
>>>>
>>>> what's the state of the debian package generator on the rtt master
>>>> branch?
>>>
>>> I have packaged rtt + ocl on the toolchain-2.2 branch and there it works.
>>> I also tested if the deployer can find the plugins etc. This is not yet
>>> ported to master, but for now, you may consider toolchain-2.2 as most
>>> stable/tested/working.
>>>
>>> Note that the debian packages install in /usr/lib/orocos-[lxrt|gnulinux|
>>> xenomai] in order to support multi-target installs. The deployer/plugin
>>> loaders know this.
>>
>> Wasn't the decided strategy to keep on having libraries with a
>> -${OROCOS_TARGET} suffix ? I.e. orocos/types/libhokuyo-typekit-gnulinux.so
>
> The -gnulinux didn't change. The 'orocos' part changed for Debian packages.
>
>>
>> That's what oroGen does and I thought it was what we decided ...
>
> The problem is that the v2.x deployer no longer relies on the filename to
> determine the target it was built for. The reason for this is that it could
> not exclude files, only include files. ie, libfoo-gnulinux.so is certainly fine
> on a "gnulinux" target, but libfoo.so or libfoo-bar.so is unsure. It might be
> ok or not. What we do now is to explicitly state which directories to process
> (ie set a path).
>
> This surfaced during the testing of the Debian packages. We installed all libs
> in lib/orocos and the deployer-gnulinux tried to load both the xenomai and
> gnulinux components. That didn't work.
>
> I agree that we need a broader discussion about this. Stephen already voiced
> that he prefers to keep the -macosx suffix, even if it's not strictly necessary
> on that platform, for the sake of consistency.
>
> I prefer that the filename may be arbitrary (and thus also may include target
> information) but that the directory/paths determine which files are considered.
>
> This would support layouts like:
>
> a)
> lib/orocos/project-lxrt
> lib/orocos/project-gnulinux
>
> usage: path("../lib/orocos"); import("project-lxrt");
>
> b)
> lib/orocos-lxrt/project
> lib/orocos-gnulinux/project
>
> usage: path("../lib/orocos-lxrt"); import("project");
>
> c) but not:
> lib/orocos/project/libfoo-lxrt.so
> lib/orocos/project/libfoo-gnulinux.so
>
> d) unless you have:
> lib/orocos/project/libfoo-gnulinux.so
> only.
>
> Where the latter is the 1.x behavior. I would strongly advise everyone to use
> option b) since this allows you to set the path in a separate xml file or the
> RTT_COMPONENT_PATH environment variable.
>
> What do you guys think ?
I see the general problem, since you want to have multiple
typekits/transports/task libraries in the same project. Requiring to
design the right "search path" for the plugin loader seem a rather
sensible path.
Small comment: why not orocos/<target> ??? Would not that make more sense ?
What I don't agree with is the current behaviour of the plugin loader to
load *everything* from RTT_COMPONENT_PATH. I.e. if I want to be
plugin-loader-compatible I *must* put everything in subdirectories, In
an oroGen environment, this would lead to having one-file directories
all over the place, which is plain annoying.
Instead of loading everything, the plugin loader could "load nothing"
and have
import("project")
load
- all libraries in the search path matching the required name, i.e.
libproject-XXX-<target>.so in the oroGen case. I would personally
add the requirement that it must start with libproject-
- look for directories called "project" in the search path and load
everything from there
Component filenames
On Monday 20 December 2010 10:04:25 Sylvain Joyeux wrote:
> On 12/20/2010 09:30 AM, Peter Soetens wrote:
> > On Monday 20 December 2010 08:36:01 Sylvain Joyeux wrote:
> >> On 12/10/2010 09:41 PM, Peter Soetens wrote:
> >>> On Friday 10 December 2010 18:04:53 Philippe Hamelin wrote:
> >>>> Hello,
> >>>>
> >>>> what's the state of the debian package generator on the rtt master
> >>>> branch?
> >>>
> >>> I have packaged rtt + ocl on the toolchain-2.2 branch and there it
> >>> works. I also tested if the deployer can find the plugins etc. This is
> >>> not yet ported to master, but for now, you may consider toolchain-2.2
> >>> as most stable/tested/working.
> >>>
> >>> Note that the debian packages install in
> >>> /usr/lib/orocos-[lxrt|gnulinux| xenomai] in order to support
> >>> multi-target installs. The deployer/plugin loaders know this.
> >>
> >> Wasn't the decided strategy to keep on having libraries with a
> >> -${OROCOS_TARGET} suffix ? I.e.
> >> orocos/types/libhokuyo-typekit-gnulinux.so
> >
> > The -gnulinux didn't change. The 'orocos' part changed for Debian
> > packages.
> >
> >> That's what oroGen does and I thought it was what we decided ...
> >
> > The problem is that the v2.x deployer no longer relies on the filename to
> > determine the target it was built for. The reason for this is that it
> > could not exclude files, only include files. ie, libfoo-gnulinux.so is
> > certainly fine on a "gnulinux" target, but libfoo.so or libfoo-bar.so is
> > unsure. It might be ok or not. What we do now is to explicitly state
> > which directories to process (ie set a path).
> >
> > This surfaced during the testing of the Debian packages. We installed all
> > libs in lib/orocos and the deployer-gnulinux tried to load both the
> > xenomai and gnulinux components. That didn't work.
> >
> > I agree that we need a broader discussion about this. Stephen already
> > voiced that he prefers to keep the -macosx suffix, even if it's not
> > strictly necessary on that platform, for the sake of consistency.
> >
> > I prefer that the filename may be arbitrary (and thus also may include
> > target information) but that the directory/paths determine which files
> > are considered.
> >
> > This would support layouts like:
> >
> > a)
> > lib/orocos/project-lxrt
> > lib/orocos/project-gnulinux
> >
> > usage: path("../lib/orocos"); import("project-lxrt");
> >
> > b)
> > lib/orocos-lxrt/project
> > lib/orocos-gnulinux/project
> >
> > usage: path("../lib/orocos-lxrt"); import("project");
> >
> > c) but not:
> > lib/orocos/project/libfoo-lxrt.so
> > lib/orocos/project/libfoo-gnulinux.so
> >
> > d) unless you have:
> > lib/orocos/project/libfoo-gnulinux.so
> > only.
> >
> > Where the latter is the 1.x behavior. I would strongly advise everyone to
> > use option b) since this allows you to set the path in a separate xml
> > file or the RTT_COMPONENT_PATH environment variable.
> >
> > What do you guys think ?
>
> I see the general problem, since you want to have multiple
> typekits/transports/task libraries in the same project. Requiring to
> design the right "search path" for the plugin loader seem a rather
> sensible path.
>
> Small comment: why not orocos/<target> ??? Would not that make more sense ?
I'm open for that as well.
>
> What I don't agree with is the current behaviour of the plugin loader to
> load *everything* from RTT_COMPONENT_PATH. I.e. if I want to be
> plugin-loader-compatible I *must* put everything in subdirectories, In
> an oroGen environment, this would lead to having one-file directories
> all over the place, which is plain annoying.
Or in an orocos/orogen subdirectory ? To be sure I understand your case: since
you already link with the types/plugins at link-time, you don't want the
pluginloader to load all these types/plugins a second time in the process ?
>
> Instead of loading everything, the plugin loader could "load nothing"
> and have
>
> import("project")
>
> load
> - all libraries in the search path matching the required name, i.e.
> libproject-XXX-<target>.so in the oroGen case. I would personally
> add the requirement that it must start with libproject-
> - look for directories called "project" in the search path and load
> everything from there
I'm open to this as well, we had a similar discussion during the -dev meeting.
However, we also want to specify paths for plugins/typekits to load by
default[1]. So the idea was to load all libs directly in the search path and
leave everything in a subdir alone, until the proper import() is given.
[1]: to avoid needing to write: import("rtt"); import("ocl"); in every
deployer/taskbrowser application.
Peter
Component filenames
On 12/20/2010 10:28 AM, Peter Soetens wrote:
>> What I don't agree with is the current behaviour of the plugin loader to
>> load *everything* from RTT_COMPONENT_PATH. I.e. if I want to be
>> plugin-loader-compatible I *must* put everything in subdirectories, In
>> an oroGen environment, this would lead to having one-file directories
>> all over the place, which is plain annoying.
>
> Or in an orocos/orogen subdirectory ? To be sure I understand your case: since
> you already link with the types/plugins at link-time, you don't want the
> pluginloader to load all these types/plugins a second time in the process ?
Moving them in orocos/orogen would break using orogen-generated typekits
and type libraries in an OCL-based workflow. I also want someone that
uses orogen *but* uses the OCL deployer to be able to use them "the
normal way", i.e. by doing
import("orogen_project_name")
>> Instead of loading everything, the plugin loader could "load nothing"
>> and have
>>
>> import("project")
>>
>> load
>> - all libraries in the search path matching the required name, i.e.
>> libproject-XXX-<target>.so in the oroGen case. I would personally
>> add the requirement that it must start with libproject-
>> - look for directories called "project" in the search path and load
>> everything from there
>
> I'm open to this as well, we had a similar discussion during the -dev meeting.
> However, we also want to specify paths for plugins/typekits to load by
> default[1]. So the idea was to load all libs directly in the search path and
> leave everything in a subdir alone, until the proper import() is given.
>
> [1]: to avoid needing to write: import("rtt"); import("ocl"); in every
> deployer/taskbrowser application.
Why don't you have the taskbrowser/deployer load the rtt and ocl plugins
? If they need it, they should load them.
Embedding such behaviour as lowlevel as the framework is really harmful.
Component filenames
On Monday 20 December 2010 10:47:44 Sylvain Joyeux wrote:
> On 12/20/2010 10:28 AM, Peter Soetens wrote:
> >> What I don't agree with is the current behaviour of the plugin loader to
> >> load *everything* from RTT_COMPONENT_PATH. I.e. if I want to be
> >> plugin-loader-compatible I *must* put everything in subdirectories, In
> >> an oroGen environment, this would lead to having one-file directories
> >> all over the place, which is plain annoying.
> >
> > Or in an orocos/orogen subdirectory ? To be sure I understand your case:
> > since you already link with the types/plugins at link-time, you don't
> > want the pluginloader to load all these types/plugins a second time in
> > the process ?
>
> Moving them in orocos/orogen would break using orogen-generated typekits
> and type libraries in an OCL-based workflow. I also want someone that
> uses orogen *but* uses the OCL deployer to be able to use them "the
> normal way", i.e. by doing
>
> import("orogen_project_name")
ok, but I believe you can also write:
import("orogen/project_name")
since import expects a directory.
>
> >> Instead of loading everything, the plugin loader could "load nothing"
> >> and have
> >>
> >> import("project")
> >>
> >> load
> >>
> >> - all libraries in the search path matching the required name, i.e.
> >>
> >> libproject-XXX-<target>.so in the oroGen case. I would personally
> >> add the requirement that it must start with libproject-
> >>
> >> - look for directories called "project" in the search path and load
> >>
> >> everything from there
> >
> > I'm open to this as well, we had a similar discussion during the -dev
> > meeting. However, we also want to specify paths for plugins/typekits to
> > load by default[1]. So the idea was to load all libs directly in the
> > search path and leave everything in a subdir alone, until the proper
> > import() is given.
> >
> > [1]: to avoid needing to write: import("rtt"); import("ocl"); in every
> > deployer/taskbrowser application.
>
> Why don't you have the taskbrowser/deployer load the rtt and ocl plugins
> ? If they need it, they should load them.
>
> Embedding such behaviour as lowlevel as the framework is really harmful.
I agree, and I was tinkering with the idea. I guess I just needed an extra
push, or more feedback from the list to make this happen.
Peter
Component filenames (was: Debian package)
On Mon, Dec 20, 2010 at 9:30 AM, Peter Soetens <peter [..] ...>wrote:
> On Monday 20 December 2010 08:36:01 Sylvain Joyeux wrote:
> > On 12/10/2010 09:41 PM, Peter Soetens wrote:
> > > On Friday 10 December 2010 18:04:53 Philippe Hamelin wrote:
> > >> Hello,
> > >>
> > >> what's the state of the debian package generator on the rtt master
> > >> branch?
> > >
> > > I have packaged rtt + ocl on the toolchain-2.2 branch and there it
> works.
> > > I also tested if the deployer can find the plugins etc. This is not yet
> > > ported to master, but for now, you may consider toolchain-2.2 as most
> > > stable/tested/working.
> > >
> > > Note that the debian packages install in
> /usr/lib/orocos-[lxrt|gnulinux|
> > > xenomai] in order to support multi-target installs. The deployer/plugin
> > > loaders know this.
> >
> > Wasn't the decided strategy to keep on having libraries with a
> > -${OROCOS_TARGET} suffix ? I.e.
> orocos/types/libhokuyo-typekit-gnulinux.so
>
> The -gnulinux didn't change. The 'orocos' part changed for Debian packages.
>
> >
> > That's what oroGen does and I thought it was what we decided ...
>
> The problem is that the v2.x deployer no longer relies on the filename to
> determine the target it was built for. The reason for this is that it
> could
> not exclude files, only include files. ie, libfoo-gnulinux.so is certainly
> fine
> on a "gnulinux" target, but libfoo.so or libfoo-bar.so is unsure. It might
> be
> ok or not. What we do now is to explicitly state which directories to
> process
> (ie set a path).
>
> This surfaced during the testing of the Debian packages. We installed all
> libs
> in lib/orocos and the deployer-gnulinux tried to load both the xenomai and
> gnulinux components. That didn't work.
>
> I agree that we need a broader discussion about this. Stephen already
> voiced
> that he prefers to keep the -macosx suffix, even if it's not strictly
> necessary
> on that platform, for the sake of consistency.
>
> I prefer that the filename may be arbitrary (and thus also may include
> target
> information) but that the directory/paths determine which files are
> considered.
>
> This would support layouts like:
>
> a)
> lib/orocos/project-lxrt
> lib/orocos/project-gnulinux
>
> usage: path("../lib/orocos"); import("project-lxrt");
>
> b)
> lib/orocos-lxrt/project
> lib/orocos-gnulinux/project
>
> usage: path("../lib/orocos-lxrt"); import("project");
>
> c) but not:
> lib/orocos/project/libfoo-lxrt.so
> lib/orocos/project/libfoo-gnulinux.so
>
> d) unless you have:
> lib/orocos/project/libfoo-gnulinux.so
> only.
>
> Where the latter is the 1.x behavior. I would strongly advise everyone to
> use
> option b) since this allows you to set the path in a separate xml file or
> the
> RTT_COMPONENT_PATH environment variable.
>
> What do you guys think ?
>
I'd go with b) as well.
Adolfo
> Peter
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>