Hi,
i had some problems with enabling the deployability of KDL-dependent
components in OCL therefor i propose the following patch for OCL to
automaticaly load the KDLToolkit if it is found during configuration:
Index: deployment/CMakeLists.txt
===================================================================
--- deployment/CMakeLists.txt (revision 28912)
+++ deployment/CMakeLists.txt (working copy)
@@ -15,7 +15,12 @@
GLOBAL_ADD_INCLUDE( ocl ${HPPS})
COMPONENT_ADD_LIBS( orocos-deployment "dl" )
-
+
+ # Link with KDLToolkit if found to enable KDL Types
+ IF(KDLTK_FOUND)
+ COMPONENT_ADD_LIBS( orocos-deployment ${KDLTK_LIBS} )
+ ENDIF(KDLTK_FOUND)
+
ADD_SUBDIRECTORY( tests )
# This requires the orocos-rtt library to be carefully tagged
Index: taskbrowser/CMakeLists.txt
===================================================================
--- taskbrowser/CMakeLists.txt (revision 28912)
+++ taskbrowser/CMakeLists.txt (working copy)
@@ -18,6 +18,11 @@
COMPONENT_ADD_LIBS( orocos-taskbrowser ncurses readline )
+ # Link with KDLToolkit if found to enable KDL Types
+ IF(KDLTK_FOUND)
+ COMPONENT_ADD_LIBS( orocos-deployment ${KDLTK_LIBS} )
+ ENDIF(KDLTK_FOUND)
+
ADD_SUBDIRECTORY( tests )
ENDIF(NOT CURSES AND NOT READLINE)
Ruben
Automatically enabling KDL-types
On Thursday 07 February 2008 10:19:04 Ruben Smits wrote:
> Hi,
>
> i had some problems with enabling the deployability of KDL-dependent
> components in OCL therefor i propose the following patch for OCL to
> automaticaly load the KDLToolkit if it is found during configuration:
>
> Index: deployment/CMakeLists.txt
> ===================================================================
> --- deployment/CMakeLists.txt (revision 28912)
> +++ deployment/CMakeLists.txt (working copy)
> @@ -15,7 +15,12 @@
> GLOBAL_ADD_INCLUDE( ocl ${HPPS})
>
> COMPONENT_ADD_LIBS( orocos-deployment "dl" )
> -
> +
> + # Link with KDLToolkit if found to enable KDL Types
> + IF(KDLTK_FOUND)
> + COMPONENT_ADD_LIBS( orocos-deployment ${KDLTK_LIBS} )
> + ENDIF(KDLTK_FOUND)
> +
> ADD_SUBDIRECTORY( tests )
>
> # This requires the orocos-rtt library to be carefully tagged
> Index: taskbrowser/CMakeLists.txt
> ===================================================================
> --- taskbrowser/CMakeLists.txt (revision 28912)
> +++ taskbrowser/CMakeLists.txt (working copy)
> @@ -18,6 +18,11 @@
>
> COMPONENT_ADD_LIBS( orocos-taskbrowser ncurses readline )
>
> + # Link with KDLToolkit if found to enable KDL Types
> + IF(KDLTK_FOUND)
> + COMPONENT_ADD_LIBS( orocos-deployment ${KDLTK_LIBS} )
> + ENDIF(KDLTK_FOUND)
> +
> ADD_SUBDIRECTORY( tests )
> ENDIF(NOT CURSES AND NOT READLINE)
If it is a proposol, then why did you commit this on trunk/ocl ? Please revert
this.
Peter
Automatically enabling KDL-types
On Friday February 8 2008 16:11:27 Peter Soetens wrote:
> On Thursday 07 February 2008 10:19:04 Ruben Smits wrote:
> > Hi,
> >
> > i had some problems with enabling the deployability of KDL-dependent
> > components in OCL therefor i propose the following patch for OCL to
> > automaticaly load the KDLToolkit if it is found during configuration:
> >
> > Index: deployment/CMakeLists.txt
> > ===================================================================
> > --- deployment/CMakeLists.txt (revision 28912)
> > +++ deployment/CMakeLists.txt (working copy)
> > @@ -15,7 +15,12 @@
> > GLOBAL_ADD_INCLUDE( ocl ${HPPS})
> >
> > COMPONENT_ADD_LIBS( orocos-deployment "dl" )
> > -
> > +
> > + # Link with KDLToolkit if found to enable KDL Types
> > + IF(KDLTK_FOUND)
> > + COMPONENT_ADD_LIBS( orocos-deployment ${KDLTK_LIBS} )
> > + ENDIF(KDLTK_FOUND)
> > +
> > ADD_SUBDIRECTORY( tests )
> >
> > # This requires the orocos-rtt library to be carefully tagged
> > Index: taskbrowser/CMakeLists.txt
> > ===================================================================
> > --- taskbrowser/CMakeLists.txt (revision 28912)
> > +++ taskbrowser/CMakeLists.txt (working copy)
> > @@ -18,6 +18,11 @@
> >
> > COMPONENT_ADD_LIBS( orocos-taskbrowser ncurses readline )
> >
> > + # Link with KDLToolkit if found to enable KDL Types
> > + IF(KDLTK_FOUND)
> > + COMPONENT_ADD_LIBS( orocos-deployment ${KDLTK_LIBS} )
> > + ENDIF(KDLTK_FOUND)
> > +
> > ADD_SUBDIRECTORY( tests )
> > ENDIF(NOT CURSES AND NOT READLINE)
>
> If it is a proposol, then why did you commit this on trunk/ocl ? Please
> revert this.
Because i thought it was a good idea, apparently not. I will revert it
and continue on my own branch.
Ruben
> Peter
>
>
> --
> Peter Soetens -- FMTC --
Automatically enabling KDL-types
On Friday February 8 2008 16:14:27 Ruben Smits wrote:
> On Friday February 8 2008 16:11:27 Peter Soetens wrote:
> > On Thursday 07 February 2008 10:19:04 Ruben Smits wrote:
> > > Hi,
> > >
> > > i had some problems with enabling the deployability of KDL-dependent
> > > components in OCL therefor i propose the following patch for OCL to
> > > automaticaly load the KDLToolkit if it is found during configuration:
> > >
> > > Index: deployment/CMakeLists.txt
> > > ===================================================================
> > > --- deployment/CMakeLists.txt (revision 28912)
> > > +++ deployment/CMakeLists.txt (working copy)
> > > @@ -15,7 +15,12 @@
> > > GLOBAL_ADD_INCLUDE( ocl ${HPPS})
> > >
> > > COMPONENT_ADD_LIBS( orocos-deployment "dl" )
> > > -
> > > +
> > > + # Link with KDLToolkit if found to enable KDL Types
> > > + IF(KDLTK_FOUND)
> > > + COMPONENT_ADD_LIBS( orocos-deployment ${KDLTK_LIBS} )
> > > + ENDIF(KDLTK_FOUND)
> > > +
> > > ADD_SUBDIRECTORY( tests )
> > >
> > > # This requires the orocos-rtt library to be carefully tagged
> > > Index: taskbrowser/CMakeLists.txt
> > > ===================================================================
> > > --- taskbrowser/CMakeLists.txt (revision 28912)
> > > +++ taskbrowser/CMakeLists.txt (working copy)
> > > @@ -18,6 +18,11 @@
> > >
> > > COMPONENT_ADD_LIBS( orocos-taskbrowser ncurses readline )
> > >
> > > + # Link with KDLToolkit if found to enable KDL Types
> > > + IF(KDLTK_FOUND)
> > > + COMPONENT_ADD_LIBS( orocos-deployment ${KDLTK_LIBS} )
> > > + ENDIF(KDLTK_FOUND)
> > > +
> > > ADD_SUBDIRECTORY( tests )
> > > ENDIF(NOT CURSES AND NOT READLINE)
> >
> > If it is a proposol, then why did you commit this on trunk/ocl ? Please
> > revert this.
>
> Because i thought it was a good idea, apparently not. I will revert it
> and continue on my own branch.
svn ci deployment/ taskbrowser/ -m"Reverting automatic inclusion of kdltk if
found, you will have to wait until the deployer can import rtt plugins to
beable to use kdl types when using the deployer"
Sending taskbrowser/CMakeLists.txt
Transmitting file data .
Committed revision 28933.
Automatically enabling KDL-types
On Thursday 07 February 2008 10:19:04 Ruben Smits wrote:
> Hi,
>
> i had some problems with enabling the deployability of KDL-dependent
> components in OCL therefor i propose the following patch for OCL to
> automaticaly load the KDLToolkit if it is found during configuration:
Why doesn't *your* component link against the KDL toolkit ? That should do
it... no ?
This patch is not acceptible for inclusion as it would force a KDL dependency
on the base components of OCL, which only depend on the RTT. This would have
as a consequence that the OCL Debian packages would always depend on KDL (and
on any future toolkit).
Peter
Automatically enabling KDL-types
On Friday February 8 2008 08:49:33 Peter Soetens wrote:
> On Thursday 07 February 2008 10:19:04 Ruben Smits wrote:
> > Hi,
> >
> > i had some problems with enabling the deployability of KDL-dependent
> > components in OCL therefor i propose the following patch for OCL to
> > automaticaly load the KDLToolkit if it is found during configuration:
>
> Why doesn't *your* component link against the KDL toolkit ? That should do
> it... no ?
No, it does not work. I tried it, in a lot of different ways. The
proposed solution was the only one that worked.
The orocos-taskbrowser
is the only one that must be linked with the orocos-kdltk. I don't
know why other solutions don't work. Probably because the deployer
loads the other (kdl-dependend) libraries but isn't really linked with
it, and not executing the OS::InitFunction(&loadKDL) command that is
executed if orocos-kdltk is linked with orocos-taskbrowser.
> This patch is not acceptible for inclusion as it would force a KDL
> dependency on the base components of OCL, which only depend on the
> RTT. This would have as a consequence that the OCL Debian packages
> would always depend on KDL (and on any future toolkit).
Is it a shame to depend on KDL, which is -i thought- a part of
the Orocos Project?
Ruben
Automatically enabling KDL-types
On Friday 08 February 2008 09:38:42 Ruben Smits wrote:
> On Friday February 8 2008 08:49:33 Peter Soetens wrote:
> > On Thursday 07 February 2008 10:19:04 Ruben Smits wrote:
> > > Hi,
> > >
> > > i had some problems with enabling the deployability of KDL-dependent
> > > components in OCL therefor i propose the following patch for OCL to
> > > automaticaly load the KDLToolkit if it is found during configuration:
> >
> > Why doesn't *your* component link against the KDL toolkit ? That should
> > do it... no ?
>
> No, it does not work. I tried it, in a lot of different ways. The
> proposed solution was the only one that worked.
>
> The orocos-taskbrowser
> is the only one that must be linked with the orocos-kdltk. I don't
> know why other solutions don't work. Probably because the deployer
> loads the other (kdl-dependend) libraries but isn't really linked with
> it, and not executing the OS::InitFunction(&loadKDL) command that is
> executed if orocos-kdltk is linked with orocos-taskbrowser.
>
> > This patch is not acceptible for inclusion as it would force a KDL
> > dependency on the base components of OCL, which only depend on the
> > RTT. This would have as a consequence that the OCL Debian packages
> > would always depend on KDL (and on any future toolkit).
>
> Is it a shame to depend on KDL, which is -i thought- a part of
> the Orocos Project?
The problem is that it's just another dependency. A solution that I would
prefer is that we have a /usr/lib/ocl/tk directory where toolkits may reside
and which get automatically loaded by the deployment component, a bit similar
as a component is loaded using import. This would also solve the toolkit
problem from a structural point of view.
Peter
Automatically enabling KDL-types
On Fri, 8 Feb 2008, Peter Soetens wrote:
[...]
>>> This patch is not acceptible for inclusion as it would force a KDL
>>> dependency on the base components of OCL, which only depend on the
>>> RTT. This would have as a consequence that the OCL Debian packages
>>> would always depend on KDL (and on any future toolkit).
>>
>> Is it a shame to depend on KDL, which is -i thought- a part of
>> the Orocos Project?
>
> The problem is that it's just another dependency. A solution that I would
> prefer is that we have a /usr/lib/ocl/tk directory where toolkits may reside
> and which get automatically loaded by the deployment component, a bit similar
> as a component is loaded using import. This would also solve the toolkit
> problem from a structural point of view.
Indeed, such a run-time "plug in" concept scales much more easily than a
static linking approach! We should try to go this way whenever possible, I
think. (Also the new release of the audio framework CLAM
Or do I miss something essential here? What are the limits of plug in
architectures, btw?
Herman
Automatically enabling KDL-types
On Friday 08 February 2008 10:16:32 Herman Bruyninckx wrote:
>
> Indeed, such a run-time "plug in" concept scales much more easily than a
> static linking approach! We should try to go this way whenever possible, I
> think. (Also the new release of the audio framework CLAM
>
>
> Or do I miss something essential here? What are the limits of plug in
> architectures, btw?
You have better control over initialisation ordering etc, but it only works
on OS's with dynamic linking support.
Each plugin implements the same C functions, so you must detect when the
sources are built for static libraries and omit these functions in order to
avoid 'duplicate symbols'. That's what OCL does already.
Peter
Automatically enabling KDL-types
On Friday February 8 2008 10:00:13 Peter Soetens wrote:
> On Friday 08 February 2008 09:38:42 Ruben Smits wrote:
> > On Friday February 8 2008 08:49:33 Peter Soetens wrote:
> > > On Thursday 07 February 2008 10:19:04 Ruben Smits wrote:
> > > > Hi,
> > > >
> > > > i had some problems with enabling the deployability of KDL-dependent
> > > > components in OCL therefor i propose the following patch for OCL to
> > > > automaticaly load the KDLToolkit if it is found during configuration:
> > >
> > > Why doesn't *your* component link against the KDL toolkit ? That should
> > > do it... no ?
> >
> > No, it does not work. I tried it, in a lot of different ways. The
> > proposed solution was the only one that worked.
> >
> > The orocos-taskbrowser
> > is the only one that must be linked with the orocos-kdltk. I don't
> > know why other solutions don't work. Probably because the deployer
> > loads the other (kdl-dependend) libraries but isn't really linked with
> > it, and not executing the OS::InitFunction(&loadKDL) command that is
> > executed if orocos-kdltk is linked with orocos-taskbrowser.
> >
> > > This patch is not acceptible for inclusion as it would force a KDL
> > > dependency on the base components of OCL, which only depend on the
> > > RTT. This would have as a consequence that the OCL Debian packages
> > > would always depend on KDL (and on any future toolkit).
> >
> > Is it a shame to depend on KDL, which is -i thought- a part of
> > the Orocos Project?
>
> The problem is that it's just another dependency. A solution that I would
> prefer is that we have a /usr/lib/ocl/tk directory where toolkits may
> reside and which get automatically loaded by the deployment component, a
> bit similar as a component is loaded using import. This would also solve
> the toolkit problem from a structural point of view.
That would be a very nice solution. I created a branch of OCL, so i
can keep working until this feature is implemented.
A small question, how would the toolkits end up in the /usr/lib/ocl/tk
directory? By installation of KDL (or any other lib) or by the
installation of ocl which would create a symbolic link if a supported
toolkit is found during installation?
Ruben
> Peter
>
> --
> Peter Soetens -- FMTC --
Automatically enabling KDL-types
On Friday 08 February 2008 10:09:16 Ruben Smits wrote:
> On Friday February 8 2008 10:00:13 Peter Soetens wrote:
> > The problem is that it's just another dependency. A solution that I would
> > prefer is that we have a /usr/lib/ocl/tk directory where toolkits may
> > reside and which get automatically loaded by the deployment component, a
> > bit similar as a component is loaded using import. This would also solve
> > the toolkit problem from a structural point of view.
>
> That would be a very nice solution. I created a branch of OCL, so i
> can keep working until this feature is implemented.
> A small question, how would the toolkits end up in the /usr/lib/ocl/tk
> directory? By installation of KDL (or any other lib) or by the
> installation of ocl which would create a symbolic link if a supported
> toolkit is found during installation?
As a second thought, it should have been: /usr/lib/rtt/tk and if KDL detects
the RTT, it installs its libkdltk into that directory.
Peter
Automatically enabling KDL-types
On Friday February 8 2008 11:36:27 Peter Soetens wrote:
> On Friday 08 February 2008 10:09:16 Ruben Smits wrote:
> > On Friday February 8 2008 10:00:13 Peter Soetens wrote:
> > > The problem is that it's just another dependency. A solution that I
> > > would prefer is that we have a /usr/lib/ocl/tk directory where toolkits
> > > may reside and which get automatically loaded by the deployment
> > > component, a bit similar as a component is loaded using import. This
> > > would also solve the toolkit problem from a structural point of view.
> >
> > That would be a very nice solution. I created a branch of OCL, so i
> > can keep working until this feature is implemented.
> > A small question, how would the toolkits end up in the /usr/lib/ocl/tk
> > directory? By installation of KDL (or any other lib) or by the
> > installation of ocl which would create a symbolic link if a supported
> > toolkit is found during installation?
>
> As a second thought, it should have been: /usr/lib/rtt/tk and if KDL
> detects the RTT, it installs its libkdltk into that directory.
and the deployer/taskbrowser should check that directory for toolkits
in automatically includes them?
Ruben
Automatically enabling KDL-types
On Friday 08 February 2008 11:45:08 Ruben Smits wrote:
> On Friday February 8 2008 11:36:27 Peter Soetens wrote:
> > On Friday 08 February 2008 10:09:16 Ruben Smits wrote:
> > > On Friday February 8 2008 10:00:13 Peter Soetens wrote:
> > > > The problem is that it's just another dependency. A solution that I
> > > > would prefer is that we have a /usr/lib/ocl/tk directory where
> > > > toolkits may reside and which get automatically loaded by the
> > > > deployment component, a bit similar as a component is loaded using
> > > > import. This would also solve the toolkit problem from a structural
> > > > point of view.
> > >
> > > That would be a very nice solution. I created a branch of OCL, so i
> > > can keep working until this feature is implemented.
> > > A small question, how would the toolkits end up in the /usr/lib/ocl/tk
> > > directory? By installation of KDL (or any other lib) or by the
> > > installation of ocl which would create a symbolic link if a supported
> > > toolkit is found during installation?
> >
> > As a second thought, it should have been: /usr/lib/rtt/tk and if KDL
> > detects the RTT, it installs its libkdltk into that directory.
>
> and the deployer/taskbrowser should check that directory for toolkits
> in automatically includes them?
Yes, that as well. We should open a bug report to track this feature.
Peter
Automatically enabling KDL-types
On Fri, 8 Feb 2008, Ruben Smits wrote:
[...]
>> This patch is not acceptible for inclusion as it would force a KDL
>> dependency on the base components of OCL, which only depend on the
>> RTT. This would have as a consequence that the OCL Debian packages
>> would always depend on KDL (and on any future toolkit).
>
> Is it a shame to depend on KDL, which is -i thought- a part of
> the Orocos Project?
It's not a shame, but not a desirable situation either... But maybe the
core of this problem is that "OCL" is not sufficiently structured/decoupled
in itself...?
Herman
Automatically enabling KDL-types
On Thursday February 7 2008 10:19:04 Ruben Smits wrote:
> Hi,
>
> i had some problems with enabling the deployability of KDL-dependent
> components in OCL therefor i propose the following patch for OCL to
> automaticaly load the KDLToolkit if it is found during configuration:
>
> Index: deployment/CMakeLists.txt
> ===================================================================
> --- deployment/CMakeLists.txt (revision 28912)
> +++ deployment/CMakeLists.txt (working copy)
> @@ -15,7 +15,12 @@
> GLOBAL_ADD_INCLUDE( ocl ${HPPS})
>
> COMPONENT_ADD_LIBS( orocos-deployment "dl" )
> -
> +
> + # Link with KDLToolkit if found to enable KDL Types
> + IF(KDLTK_FOUND)
> + COMPONENT_ADD_LIBS( orocos-deployment ${KDLTK_LIBS} )
> + ENDIF(KDLTK_FOUND)
> +
> ADD_SUBDIRECTORY( tests )
>
> # This requires the orocos-rtt library to be carefully tagged
> Index: taskbrowser/CMakeLists.txt
> ===================================================================
> --- taskbrowser/CMakeLists.txt (revision 28912)
> +++ taskbrowser/CMakeLists.txt (working copy)
> @@ -18,6 +18,11 @@
>
> COMPONENT_ADD_LIBS( orocos-taskbrowser ncurses readline )
>
> + # Link with KDLToolkit if found to enable KDL Types
> + IF(KDLTK_FOUND)
> + COMPONENT_ADD_LIBS( orocos-deployment ${KDLTK_LIBS} )
A small error slipped into the patch this should offcourse be:
+ COMPONENT_ADD_LIBS( orocos-taskbrowser ${KDLTK_LIBS} )
> + ENDIF(KDLTK_FOUND)
> +
> ADD_SUBDIRECTORY( tests )
> ENDIF(NOT CURSES AND NOT READLINE)
>
> Ruben
> --
> Ir. Ruben Smits
> Robotics Research - Autonomous Compliant Motion
> Division Production engineering, Machine design and Automation
> Department of Mechanical Engineering
> Katholieke Universiteit Leuven