On Tuesday 14 December 2010 20:13:08 S Roderick wrote:
> On 14/12/2010, at 23:05 , Peter Soetens wrote:
> > I'll try to keep this short, but there were quite some issues I have hit
> > during the preparation of the 2.2 release. It took me longer to
> > package/test/fix it because of these issues:
> >
> > **Debian packages and /usr/local/lib/orocos:
> > - It's impossible to install both xenomai/gnulinux component/plugin
> > libraries in the same lib/orocos directory. I had to install them in
> > /usr/lib/orocos-<target> in order to avoid the plugin loaders to load the
> > libs for both targets
> > -> I propose to make this the default for non Debian builds as well. For
> > macosx/windows systems, I would not change this since they don't have
> > this problem. So there it remains the 'lib/orocos' subdirectory.
>
> While that extra target prefix/suffix is a pain, I'd suggest leaving it the
> same for mac/win. Personally, I don't want to have to think one thing for
> Linux, and a different thing for Mac. That will just result in me swearing
> in Peter's direction one day, for no good reason ...
>
> > -> this would have an influence on the UseOrocos.cmake macros as well, so
> > not a light change. We also need to see how this would work in a ROS
> > package tree. - We have to (or don't we have to?) think about packaging
> > the other toolchain packages. I have no time to do this however. Debian
> > packaging takes so much more time than I had hoped for. The major reason
> > here is that we need to keep track of the multi-target installations
> > (gnulinux/xenomai/lxrt) which complicates the packaging a lot... and
> > sometimes only reveals problems when you install the package or run its
> > programs.
>
> Debian packaging is a nightmare .... :-(
>
> > **autoproj and/or bootstrap:
> > I can't run this in my Hudson since it's interactive (or is there a
> > plugin to provide the input ???) I had to pull the release the last
> > minute because when manually testing the bootstrap script, it failed to
> > build.
> > -> Can we make it non-interactive, or is there another solution ?
> >
> > ** bootstrap vs the packaged files
> > I have a script to create the zip files of the release. I had to hack a
> > custom autoproj package + release package set to make this work (the zip
> > files are not upgradable, there is a 'none' vcs associated with their
> > packages). I just noticed that the 2.2.0 zip files don't contain the
> > log4cpp patches. Fortunately, recent autobuild covers our 'damage', but
> > maybe we should think/colaborate on how to make releases of autoproj
> > projects. (note: autoproj status would have informed me of the branch
> > deviations, my release script should have run that command...).
> >
> > ** RPATH settings
> > We had removed/omitted too much rpath settings from the UseOrocos.cmake
> > macros. These turned up while testing the Debian packages for RTT/OCL
> > (which don't use an env.sh script) Would it make sense to set the rpaths
> > as such ? :
> >
> > * programs: prefix/lib; prefix/lib/orocos; prefix/lib/types;
> > prefix/lib/plugins * components: prefix/lib; prefix/lib/orocos;
> > prefix/lib/types; prefix/lib/plugins * plugins: prefix/lib;
> > prefix/lib/plugins
> > * types: prefix/lib; prefix/lib/types
> >
> > ** Documentation
> > I'd like to set up daily documentation generation for the toolchain-* and
> > master branches. Such that users have quicker access to updates. With
> > this mechanism, it would no longer be necessary for me to do the
> > documentation release steps, since it would always be there.
> > -> I'm also not happy with the Lua documentation.
>
> +1 YES! I would love to have auto-created documentation, generated upon
> commit. That is, use Hudson to auto-build the latest doc's and link the
> website to the latest stable. I was intending to suggest this for the
> upcoming Examples repo. Saves generating wiki pages as well as inline
> doxygen doc's.

I've been doing this for a while now for KDL, it pretty easy to configure
Hudson to do this.

> > ** Website
> > I have updated the front page figure of the Orocos project to the
> > traditional KDL/BFL/Toolchain trio. I'm unsure how to position the
> > orogen/dfki efforts here. orogen is part of the toolchain, but I could
> > not write up release notes about that part in my 'changes' document. I
> > had a similar issue for the Lua contributions. For the next release, I'd
> > like to setup a wiki page that contains these changes for all parts of
> > the toolchain. Then these 'non-Peter' parts can be updated by their
> > maintainer in the run for the release. -> Other suggestions on this
> > topic ?
>
> You are suggesting to _not_ produce a changelist within the code
> distribution itself? That doesn't sound like a good idea.

Same opinion, in the ideal case the wiki should be able to extract the
changelist from the codebase and pretty print it.

Ruben

On Tuesday 14 December 2010 12:38:27 Sylvain Joyeux wrote:
> On 12/14/2010 11:05 AM, Peter Soetens wrote:
> > I'll try to keep this short, but there were quite some issues I have hit
> > during the preparation of the 2.2 release. It took me longer to
> > package/test/fix it because of these issues:
> >
> > **Debian packages and /usr/local/lib/orocos:
> > - It's impossible to install both xenomai/gnulinux component/plugin
> > libraries in the same lib/orocos directory. I had to install them in
> > /usr/lib/orocos-<target> in order to avoid the plugin loaders to load
> > the libs for both targets
> > -> I propose to make this the default for non Debian builds as well. For
> > macosx/windows systems, I would not change this since they don't have
> > this problem. So there it remains the 'lib/orocos' subdirectory.
> > -> this would have an influence on the UseOrocos.cmake macros as well,
> > so not a light change. We also need to see how this would work in a ROS
> > package tree.
>
> And on the orogen cmake

Ack.

>
> > **autoproj and/or bootstrap:
> > I can't run this in my Hudson since it's interactive (or is there a
> > plugin to provide the input ???) I had to pull the release the last
> > minute because when manually testing the bootstrap script, it failed to
> > build.
> > -> Can we make it non-interactive, or is there another solution ?
>
> Yes. Autoproj supports this but it is undocumented. Solution is on its way
>
> > ** bootstrap vs the packaged files
> > I have a script to create the zip files of the release. I had to hack a
> > custom autoproj package + release package set to make this work (the zip
> > files are not upgradable, there is a 'none' vcs associated with their
> > packages). I just noticed that the 2.2.0 zip files don't contain the
> > log4cpp patches. Fortunately, recent autobuild covers our 'damage', but
> > maybe we should think/colaborate on how to make releases of autoproj
> > projects. (note: autoproj status would have informed me of the branch
> > deviations, my release script should have run that command...).
>
> What is that zip file exactly ? Is it an autoproj tree that includes
> everything already checked out and ready to build ? Is it something else ?
>
> Overriding all VCS can be done by creating an autoproj/overrides.yml with
>
> overrides:
> .*:
> type: none

I'm indeed using something similar. I have a local autoproj project with one
package set in there named 'release' and has this sources.yml :
$ cat release/source.yml
name: orocos.toolchain

version_control:
- ".*": none

The bootstrap_toolchain script is a slightly modified version of latest
autoproj_bootrap and serves to setup ruby and autoproj. The rest of the zip
are exports of the git repositories...

>
> What would be left is not having autoproj ask questions. Could add a
> config.yml to autoproj/ and add a mechanism

I don't mind that the bootstrap_toolchain script asks users questions.

>
> > ** RPATH settings
> > We had removed/omitted too much rpath settings from the UseOrocos.cmake
> > macros. These turned up while testing the Debian packages for RTT/OCL
> > (which don't use an env.sh script) Would it make sense to set the rpaths
> > as such ? :
> >
> > * programs: prefix/lib; prefix/lib/orocos; prefix/lib/types;
> > prefix/lib/plugins * components: prefix/lib; prefix/lib/orocos;
> > prefix/lib/types; prefix/lib/plugins * plugins: prefix/lib;
> > prefix/lib/plugins
> > * types: prefix/lib; prefix/lib/types
>
> FYI, as far as I remember, the Debian policy forbids using RPATH at all.

I'll be blind to that for now. Seeing Adolfo's mail seems to suggest that
we're not in a 'hard' violation, except that we need to omit the 'prefix/lib'
for Debian packages, which makes sense since prefix is '/usr'.

>
> > ** Website
> > I have updated the front page figure of the Orocos project to the
> > traditional KDL/BFL/Toolchain trio. I'm unsure how to position the
> > orogen/dfki efforts here. orogen is part of the toolchain, but I could
> > not write up release notes about that part in my 'changes' document. I
> > had a similar issue for the Lua contributions. For the next release, I'd
> > like to setup a wiki page that contains these changes for all parts of
> > the toolchain. Then these 'non-Peter' parts can be updated by their
> > maintainer in the run for the release. -> Other suggestions on this
> > topic ?
>
> I don't know about oroGen. I'd like to have a statement, at this stage,
> about how you (= Peter, Markus, Steven, ...) see oroGen as "part of the
> toolchain"
>
> What I feel is that typegen is part of the "official" toolchain, but
> oroGen is not.

I think both are part of the toolchain, but there are two workflows in the
toolchain which I wish to support. With and without orogen, and using typegen
whenever possible.

> Example: the "advertised" workflow is the
> write-C++-components-manually workflow. oroGen is barely mentioned.
>
> Note that I don't see that as a bad thing per se. I'd just like to know.

I currently see the workflow 'dependency' graph like this:

1. Orocos workflow = agreement on the concepts like in the 'Orocos cheatsheet'
2. Choose between 'write' or 'generate' components
2a. Write: use the RTT cheat sheet workflow
2b. Generate: use the oroGen cheat sheet workflow

oroGen is advertised on the toolchain home page. But maybe we can visualise
this better. To make my statement clear: I *want* orogen to be part of the
"official" toolchain. I also think that there are still existing tools lacking
(that build further on orogen). If you can say: if you use orogen, then you'll
also always use tool 'X', then that tool should be part of the toolchain as
well.

>
> As for release notes, I would be happy to fill in a wiki page.

So it will be next time.

Peter

On Tue, Dec 14, 2010 at 12:38 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:

> On 12/14/2010 11:05 AM, Peter Soetens wrote:
> > I'll try to keep this short, but there were quite some issues I have hit
> > during the preparation of the 2.2 release. It took me longer to
> > package/test/fix it because of these issues:
> >
> > **Debian packages and /usr/local/lib/orocos:
> > - It's impossible to install both xenomai/gnulinux component/plugin
> libraries
> > in the same lib/orocos directory. I had to install them in
> > /usr/lib/orocos-<target> in order to avoid the plugin loaders to load
> the libs
> > for both targets
> > -> I propose to make this the default for non Debian builds as well. For
> > macosx/windows systems, I would not change this since they don't have
> this
> > problem. So there it remains the 'lib/orocos' subdirectory.
> > -> this would have an influence on the UseOrocos.cmake macros as well,
> so not a
> > light change. We also need to see how this would work in a ROS package
> tree.
> And on the orogen cmake
>
> > **autoproj and/or bootstrap:
> > I can't run this in my Hudson since it's interactive (or is there a
> plugin to
> > provide the input ???) I had to pull the release the last minute because
> when
> > manually testing the bootstrap script, it failed to build.
> > -> Can we make it non-interactive, or is there another solution ?
> Yes. Autoproj supports this but it is undocumented. Solution is on its way
>
> > ** bootstrap vs the packaged files
> > I have a script to create the zip files of the release. I had to hack a
> custom
> > autoproj package + release package set to make this work (the zip files
> are not
> > upgradable, there is a 'none' vcs associated with their packages).
> > I just noticed that the 2.2.0 zip files don't contain the log4cpp
> patches.
> > Fortunately, recent autobuild covers our 'damage', but maybe we should
> > think/colaborate on how to make releases of autoproj projects. (note:
> autoproj
> > status would have informed me of the branch deviations, my release script
> > should have run that command...).
> What is that zip file exactly ? Is it an autoproj tree that includes
> everything already checked out and ready to build ? Is it something else ?
>
> Overriding all VCS can be done by creating an autoproj/overrides.yml with
>
> overrides:
> .*:
> type: none
>
> What would be left is not having autoproj ask questions. Could add a
> config.yml to autoproj/ and add a mechanism
>
> > ** RPATH settings
> > We had removed/omitted too much rpath settings from the UseOrocos.cmake
> > macros. These turned up while testing the Debian packages for RTT/OCL
> (which
> > don't use an env.sh script) Would it make sense to set the rpaths as such
> ? :
> >
> > * programs: prefix/lib; prefix/lib/orocos; prefix/lib/types;
> prefix/lib/plugins
> > * components: prefix/lib; prefix/lib/orocos; prefix/lib/types;
> prefix/lib/plugins
> > * plugins: prefix/lib; prefix/lib/plugins
> > * types: prefix/lib; prefix/lib/types
> FYI, as far as I remember, the Debian policy forbids using RPATH at all.
>

More details on Debian and rpath use: From [1], "While there's no policy
dictating the accepted use of rpath, it's been a general consensus that
rpath use is discouraged...". "Currently, the only generally accepted use of
this feature in Debian is to add non-standard library path (like
/usr/lib/<package>) to libraries that are only intended to be used by the
executables or other libraries within the same source package". More on when
it is OK to use rpath settings can be found here [2].

[1] http://wiki.debian.org/RpathIssue
[2] http://lists.debian.org/debian-devel/2002/07/msg02030.html

Adolfo

> > ** Website
> > I have updated the front page figure of the Orocos project to the
> traditional
> > KDL/BFL/Toolchain trio. I'm unsure how to position the orogen/dfki
> efforts
> > here. orogen is part of the toolchain, but I could not write up release
> notes
> > about that part in my 'changes' document. I had a similar issue for the
> Lua
> > contributions. For the next release, I'd like to setup a wiki page that
> > contains these changes for all parts of the toolchain. Then these
> 'non-Peter'
> > parts can be updated by their maintainer in the run for the release.
> > -> Other suggestions on this topic ?
> I don't know about oroGen. I'd like to have a statement, at this stage,
> about how you (= Peter, Markus, Steven, ...) see oroGen as "part of the
> toolchain"
>
> What I feel is that typegen is part of the "official" toolchain, but
> oroGen is not. Example: the "advertised" workflow is the
> write-C++-components-manually workflow. oroGen is barely mentioned.
>
> Note that I don't see that as a bad thing per se. I'd just like to know.
>
> As for release notes, I would be happy to fill in a wiki page.
>
> > Other feedback welcome too.
> >
> > Peter
>
>
> --
> Sylvain Joyeux (Dr. Ing.)
> Researcher - Space and Security Robotics
> DFKI Robotics Innovation Center
> Bremen, Robert-Hooke-Straße 5, 28359 Bremen, Germany
>
> Phone: +49 421 218-64136
> Fax: +49 421 218-64150
> Email: sylvain [dot] joyeux [..] ...
>
> Weitere Informationen: http://www.dfki.de
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>