A couple of times recently we've had customers or other projects have serious doubts about Orocos, due to the pain of having to source build. Being able to build Orocos via package managers (source or binary) would remove another barrier to people trying/adopting it.
We will be creating a Macports portfile in the next few days, and we will post this to the ML and to Macports (though they're well known for taking ages to act on new ports). This will alleviate the issue on the Mac (for Macports users anyway - any Fink users out there willing to do same?)
Our primary Linux distro's are Ubuntu/Debian based and while Orocos has some Debian capability, it is unclear what state it is in, and there seem to be quite some differences in approach between the various subprojects (eg RTT, KDL, etc). For RTT itself
* The RTT debian installation instructions do not work completly for Ubuntu Hardy. They can install the basic RTT, but not rtt-corba due to some funky versioning problem with ace/tao.
* Building RTT from source via the debian dir in trunk seems to work, but is only version 1.4 (does require fixing some dependent packages)
* Neither approach appears to support newer features such as OmniORB versus ACE/TAO
* It is unclear whather the build from source approach allows building a selection of gnulinux, LXRT, and/or Xenomai packages, instead of building all of them.
Do people feel that as part of the v2.0 push, we should bring all of this up to date and at least have consistent, buildable Debian/Ubuntu, Macports, (Fink?) package capability?
S
Source build requirement a detriment to Orocos adoption
On Fri, May 29, 2009 at 15:27, <kiwi [dot] net [..] ...> wrote:
> A couple of times recently we've had customers or other projects have serious doubts about Orocos, due to the pain of having to source build. Being able to build Orocos via package managers (source or binary) would remove another barrier to people trying/adopting it.
Would people be satisfied with only the gnulinux target packaged ? It
would allow easier testing on standard Debian/... environments since
no patched kernel nor 3d party packages are required...
>
> We will be creating a Macports portfile in the next few days, and we will post this to the ML and to Macports (though they're well known for taking ages to act on new ports). This will alleviate the issue on the Mac (for Macports users anyway - any Fink users out there willing to do same?)
>
> Our primary Linux distro's are Ubuntu/Debian based and while Orocos has some Debian capability, it is unclear what state it is in, and there seem to be quite some differences in approach between the various subprojects (eg RTT, KDL, etc). For RTT itself
> * The RTT debian installation instructions do not work completly for Ubuntu Hardy. They can install the basic RTT, but not rtt-corba due to some funky versioning problem with ace/tao.
I wonder how easy it is to keep both Debian and Ubuntu packaging
working in the same tree...
> * Building RTT from source via the debian dir in trunk seems to work, but is only version 1.4 (does require fixing some dependent packages)
No it's not only 1.4. You need to run the scripts to generate the package files:
Add a changelog entry using 'debchange -v 1.8.0-0', then run cd
debian; ./create-control.sh That should really do it for 1.6 and
1.8,...
> * Neither approach appears to support newer features such as OmniORB versus ACE/TAO
That's true.
> * It is unclear whather the build from source approach allows building a selection of gnulinux, LXRT, and/or Xenomai packages, instead of building all of them.
The problem we have is that the rules file tries to build all targets.
We do generate the control file for each target, so maybe we should
also generate the rules file.
>
> Do people feel that as part of the v2.0 push, we should bring all of this up to date and at least have consistent, buildable Debian/Ubuntu, Macports, (Fink?) package capability?
Of course ! We want it all :-)
Peter
Source build requirement a detriment to Orocos adoption
On May 29, 2009, at 10:22 , Peter Soetens wrote:
> On Fri, May 29, 2009 at 15:27, <kiwi [dot] net [..] ...> wrote:
>> A couple of times recently we've had customers or other projects
>> have serious doubts about Orocos, due to the pain of having to
>> source build. Being able to build Orocos via package managers
>> (source or binary) would remove another barrier to people trying/
>> adopting it.
>
> Would people be satisfied with only the gnulinux target packaged ? It
> would allow easier testing on standard Debian/... environments since
> no patched kernel nor 3d party packages are required...
No. Personally, we need gnulinux on some machines, and xenomai on
others. Having a procedure to choose would be best - wonder how
difficult that will be?
>> We will be creating a Macports portfile in the next few days, and
>> we will post this to the ML and to Macports (though they're well
>> known for taking ages to act on new ports). This will alleviate the
>> issue on the Mac (for Macports users anyway - any Fink users out
>> there willing to do same?)
>>
>> Our primary Linux distro's are Ubuntu/Debian based and while Orocos
>> has some Debian capability, it is unclear what state it is in, and
>> there seem to be quite some differences in approach between the
>> various subprojects (eg RTT, KDL, etc). For RTT itself
>> * The RTT debian installation instructions do not work completly
>> for Ubuntu Hardy. They can install the basic RTT, but not rtt-corba
>> due to some funky versioning problem with ace/tao.
>
> I wonder how easy it is to keep both Debian and Ubuntu packaging
> working in the same tree...
I can take a look next week, and see if I can hack this up. Both
Ubuntu Hardy and Debain Lenny do not mention the version number within
the name of the "-dev" packages. Might help.
>> * Building RTT from source via the debian dir in trunk seems to
>> work, but is only version 1.4 (does require fixing some dependent
>> packages)
>
> No it's not only 1.4. You need to run the scripts to generate the
> package files:
> Add a changelog entry using 'debchange -v 1.8.0-0', then run cd
> debian; ./create-control.sh That should really do it for 1.6 and
> 1.8,...
I did this the hard way ... :-(
FYI the www.fmtc.be/debian site has v1.6 and v1.4 but trunk/RTT only
has v1.4.
>> * Neither approach appears to support newer features such as
>> OmniORB versus ACE/TAO
>
> That's true.
Macports variants is nice for this ... though you end up source
building.
>> * It is unclear whather the build from source approach allows
>> building a selection of gnulinux, LXRT, and/or Xenomai packages,
>> instead of building all of them.
>
> The problem we have is that the rules file tries to build all targets.
> We do generate the control file for each target, so maybe we should
> also generate the rules file.
Agreed.
We will have propogate these changes down into KDL, BFL and OCL too.
They all the explicit rtai/xenomai dependancy.
Also, OCL is commited without a generated "debian/control" file. Seems
to be the only one.
>> Do people feel that as part of the v2.0 push, we should bring all
>> of this up to date and at least have consistent, buildable Debian/
>> Ubuntu, Macports, (Fink?) package capability?
>
> Of course ! We want it all :-)
:-)))
BTW Macports port file for RTT and RTT+Corba took about 15 minutes.
Shame Debian is so damn capable/flexible/complicated!
S
Source build requirement a detriment to Orocos adoption
On Fri, 29 May 2009, Stephen Roderick wrote:
> On May 29, 2009, at 10:22 , Peter Soetens wrote:
>
>> On Fri, May 29, 2009 at 15:27, <kiwi [dot] net [..] ...> wrote:
>>> A couple of times recently we've had customers or other projects
>>> have serious doubts about Orocos, due to the pain of having to
>>> source build. Being able to build Orocos via package managers
>>> (source or binary) would remove another barrier to people trying/
>>> adopting it.
>>
>> Would people be satisfied with only the gnulinux target packaged ? It
>> would allow easier testing on standard Debian/... environments since
>> no patched kernel nor 3d party packages are required...
>
> No. Personally, we need gnulinux on some machines, and xenomai on
> others. Having a procedure to choose would be best - wonder how
> difficult that will be?
Everyone knows that synchronizing software projects and their builds is
extremely difficult. It _might_ be an option to start working together in a
more global way around this topic, e.g. via the recent RoboBuntu
initiative... <http://www.robobuntu.diiga.univpm.it /> This is certainly not
yet a very mature initiative, but it _is_ an initiative at least (and at
last, too!) :-)
Herman
>
>>> We will be creating a Macports portfile in the next few days, and
>>> we will post this to the ML and to Macports (though they're well
>>> known for taking ages to act on new ports). This will alleviate the
>>> issue on the Mac (for Macports users anyway - any Fink users out
>>> there willing to do same?)
>>>
>>> Our primary Linux distro's are Ubuntu/Debian based and while Orocos
>>> has some Debian capability, it is unclear what state it is in, and
>>> there seem to be quite some differences in approach between the
>>> various subprojects (eg RTT, KDL, etc). For RTT itself
>>> * The RTT debian installation instructions do not work completly
>>> for Ubuntu Hardy. They can install the basic RTT, but not rtt-corba
>>> due to some funky versioning problem with ace/tao.
>>
>> I wonder how easy it is to keep both Debian and Ubuntu packaging
>> working in the same tree...
>
> I can take a look next week, and see if I can hack this up. Both
> Ubuntu Hardy and Debain Lenny do not mention the version number within
> the name of the "-dev" packages. Might help.
>
>>> * Building RTT from source via the debian dir in trunk seems to
>>> work, but is only version 1.4 (does require fixing some dependent
>>> packages)
>>
>> No it's not only 1.4. You need to run the scripts to generate the
>> package files:
>> Add a changelog entry using 'debchange -v 1.8.0-0', then run cd
>> debian; ./create-control.sh That should really do it for 1.6 and
>> 1.8,...
>
> I did this the hard way ... :-(
>
> FYI the www.fmtc.be/debian site has v1.6 and v1.4 but trunk/RTT only
> has v1.4.
>
>>> * Neither approach appears to support newer features such as
>>> OmniORB versus ACE/TAO
>>
>> That's true.
>
> Macports variants is nice for this ... though you end up source
> building.
>
>>> * It is unclear whather the build from source approach allows
>>> building a selection of gnulinux, LXRT, and/or Xenomai packages,
>>> instead of building all of them.
>>
>> The problem we have is that the rules file tries to build all targets.
>> We do generate the control file for each target, so maybe we should
>> also generate the rules file.
>
> Agreed.
>
> We will have propogate these changes down into KDL, BFL and OCL too.
> They all the explicit rtai/xenomai dependancy.
>
> Also, OCL is commited without a generated "debian/control" file. Seems
> to be the only one.
>
>>> Do people feel that as part of the v2.0 push, we should bring all
>>> of this up to date and at least have consistent, buildable Debian/
>>> Ubuntu, Macports, (Fink?) package capability?
>>
>> Of course ! We want it all :-)
>
> :-)))
>
>
> BTW Macports port file for RTT and RTT+Corba took about 15 minutes.
> Shame Debian is so damn capable/flexible/complicated!
> S
>
Source build requirement a detriment to Orocos adoption
On May 30, 2009, at 07:25 , Herman Bruyninckx wrote:
> On Fri, 29 May 2009, Stephen Roderick wrote:
>
>> On May 29, 2009, at 10:22 , Peter Soetens wrote:
>>
>>> On Fri, May 29, 2009 at 15:27, <kiwi [dot] net [..] ...> wrote:
>>>> A couple of times recently we've had customers or other projects
>>>> have serious doubts about Orocos, due to the pain of having to
>>>> source build. Being able to build Orocos via package managers
>>>> (source or binary) would remove another barrier to people trying/
>>>> adopting it.
>>>
>>> Would people be satisfied with only the gnulinux target packaged ?
>>> It
>>> would allow easier testing on standard Debian/... environments since
>>> no patched kernel nor 3d party packages are required...
>>
>> No. Personally, we need gnulinux on some machines, and xenomai on
>> others. Having a procedure to choose would be best - wonder how
>> difficult that will be?
>
> Everyone knows that synchronizing software projects and their builds
> is
> extremely difficult. It _might_ be an option to start working
> together in a
> more global way around this topic, e.g. via the recent RoboBuntu
> initiative... <http://www.robobuntu.diiga.univpm.it /> This is
> certainly not
> yet a very mature initiative, but it _is_ an initiative at least
> (and at
> last, too!) :-)
Agreed, this is not an easy issue. And RoboBuntu definitely looks
interesting as a future candidate.
I see two issues here:
1) Modify the existing build scripts to produce a combination of
targets appropriate to the user's situation, so that we can build just
gnulinux, or gnulinux + xenomai, etc
2) Get all/some combinations built and publish the binaries to the
FMTC website for download.
The first one is just "some coding" and I can take a look at that next
week (if Peter doesn't beat me to it). The second one sorted out is a
tricky logistics issue, and somewhat what Klaas was getting at with
KDL. Not sure what to recommend here ...
Stephen
Source build requirement a detriment to Orocos adoption
On Sat, May 30, 2009 at 16:14, S Roderick <kiwi [dot] net [..] ...> wrote:
> On May 30, 2009, at 07:25 , Herman Bruyninckx wrote:
>> more global way around this topic, e.g. via the recent RoboBuntu
>> initiative... <http://www.robobuntu.diiga.univpm.it /> This is
>> certainly not
>> yet a very mature initiative, but it _is_ an initiative at least
>> (and at
>> last, too!) :-)
>
> Agreed, this is not an easy issue. And RoboBuntu definitely looks
> interesting as a future candidate.
>
> I see two issues here:
>
> 1) Modify the existing build scripts to produce a combination of
> targets appropriate to the user's situation, so that we can build just
> gnulinux, or gnulinux + xenomai, etc
This must be doable with little effort, but we need the control
and rules files in the debian/ directory to be generated.
>
> 2) Get all/some combinations built and publish the binaries to the
> FMTC website for download.
I no longer have upload rights there. Ubuntu allows to setup PKA's
(Personal Package Archives). We can surely use these for Ubuntu
related builds, I don't know if you can use it for Debian as well.
>
> The first one is just "some coding" and I can take a look at that next
> week (if Peter doesn't beat me to it). The second one sorted out is a
> tricky logistics issue, and somewhat what Klaas was getting at with
> KDL. Not sure what to recommend here ...
There's no reason why the toolkits should be recompiled for each target
on the same Linux distro. They don't depend on OS primitives. However,
because we pack everything in a single library, there's no escaping from
it today. I wonder if we could split up between rtt-runtime (os dependent)
and rtt-services (os independent). Applications link with both, extensions
only with the latter.
A final step would be to make the runtime selectable at, yes, runtime.
But I have serious doubts about stretching this, because then we're
focussing on the wrong priorities.
Also, this solution has only advantages for the unique Linux situation, where
we have three kinds of runtimes on the same OS.
Peter
Source build requirement a detriment to Orocos adoption
On May 31, 2009, at 07:04 , Peter Soetens wrote:
> On Sat, May 30, 2009 at 16:14, S Roderick <kiwi [dot] net [..] ...> wrote:
>> On May 30, 2009, at 07:25 , Herman Bruyninckx wrote:
>>> more global way around this topic, e.g. via the recent RoboBuntu
>>> initiative... <http://www.robobuntu.diiga.univpm.it /> This is
>>> certainly not
>>> yet a very mature initiative, but it _is_ an initiative at least
>>> (and at
>>> last, too!) :-)
>>
>> Agreed, this is not an easy issue. And RoboBuntu definitely looks
>> interesting as a future candidate.
>>
>> I see two issues here:
>>
>> 1) Modify the existing build scripts to produce a combination of
>> targets appropriate to the user's situation, so that we can build
>> just
>> gnulinux, or gnulinux + xenomai, etc
>
> This must be doable with little effort, but we need the control
> and rules files in the debian/ directory to be generated.
I've made some modifications and got the same creation structure
working for both RTT and KDL for rules and control files, with the
user being able to chose between the different Linux OS's. What a
major PITA the debian build structure is! :-(
Also, either dh_install has changed or I'm missing something. The
contents of the install files are not working, and it's only
installing the change-related files. It seems that the install files
should have "path/file path/" for each line, not the "path/file" that
we currently have. Does this ring a bell at all, Peter?
>> 2) Get all/some combinations built and publish the binaries to the
>> FMTC website for download.
>
> I no longer have upload rights there. Ubuntu allows to setup PKA's
> (Personal Package Archives). We can surely use these for Ubuntu
> related builds, I don't know if you can use it for Debian as well.
So who is now responsible? Is FMTC still willing to host an
archive(s)? If not, I consider this effort to be fairly unuseful then.
>> The first one is just "some coding" and I can take a look at that
>> next
>> week (if Peter doesn't beat me to it). The second one sorted out is a
>> tricky logistics issue, and somewhat what Klaas was getting at with
>> KDL. Not sure what to recommend here ...
>
> There's no reason why the toolkits should be recompiled for each
> target
> on the same Linux distro. They don't depend on OS primitives. However,
> because we pack everything in a single library, there's no escaping
> from
> it today. I wonder if we could split up between rtt-runtime (os
> dependent)
> and rtt-services (os independent). Applications link with both,
> extensions
> only with the latter.
>
> A final step would be to make the runtime selectable at, yes, runtime.
> But I have serious doubts about stretching this, because then we're
> focussing on the wrong priorities.
>
> Also, this solution has only advantages for the unique Linux
> situation, where
> we have three kinds of runtimes on the same OS.
YAGNI?
S
Source build requirement a detriment to Orocos adoption
On Tue, Jun 2, 2009 at 02:07, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
> On May 31, 2009, at 07:04 , Peter Soetens wrote:
>>> 1) Modify the existing build scripts to produce a combination of
>>> targets appropriate to the user's situation, so that we can build just
>>> gnulinux, or gnulinux + xenomai, etc
>>
>> This must be doable with little effort, but we need the control
>> and rules files in the debian/ directory to be generated.
>
> I've made some modifications and got the same creation structure working for
> both RTT and KDL for rules and control files, with the user being able to
> chose between the different Linux OS's. What a major PITA the debian build
> structure is! :-(
>
> Also, either dh_install has changed or I'm missing something. The contents
> of the install files are not working, and it's only installing the
> change-related files. It seems that the install files should have "path/file
> path/" for each line, not the "path/file" that we currently have. Does this
> ring a bell at all, Peter?
Which package are you referring to ?
I debug my package contents using 'mc', which allows you to easily visit them.
I get my package tooling info from the man pages, like 'man dh_install'
See the note with the --autodest flag :
"Note that if you list exactly one filename or wildcard-pattern on a
line by itself in a debian/package.install file, with no explicit
destination, then dh_install will automatically guess the destination
even if this flag is not set."
>
>>> 2) Get all/some combinations built and publish the binaries to the
>>> FMTC website for download.
>>
>> I no longer have upload rights there. Ubuntu allows to setup PKA's
>> (Personal Package Archives). We can surely use these for Ubuntu
>> related builds, I don't know if you can use it for Debian as well.
>
> So who is now responsible? Is FMTC still willing to host an archive(s)? If
> not, I consider this effort to be fairly unuseful then.
Orocos.org can host it, or The SourceWorks, or the KULeuven Mechanical
department (PMA). Since PMA already hosts the tar balls, it may as well
host the .deb repository, if there are no objections...
>
>>> The first one is just "some coding" and I can take a look at that next
>>> week (if Peter doesn't beat me to it). The second one sorted out is a
>>> tricky logistics issue, and somewhat what Klaas was getting at with
>>> KDL. Not sure what to recommend here ...
>>
>> There's no reason why the toolkits should be recompiled for each target
>> on the same Linux distro. They don't depend on OS primitives. However,
>> because we pack everything in a single library, there's no escaping from
>> it today. I wonder if we could split up between rtt-runtime (os dependent)
>> and rtt-services (os independent). Applications link with both, extensions
>> only with the latter.
>>
>> A final step would be to make the runtime selectable at, yes, runtime.
>> But I have serious doubts about stretching this, because then we're
>> focussing on the wrong priorities.
>>
>> Also, this solution has only advantages for the unique Linux situation,
>> where
>> we have three kinds of runtimes on the same OS.
>
> YAGNI?
You got it !
Peter
Source build requirement a detriment to Orocos adoption
On Fri, May 29, 2009 at 8:27 AM, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
> On May 29, 2009, at 10:22 , Peter Soetens wrote:
>
>> On Fri, May 29, 2009 at 15:27, <kiwi [dot] net [..] ...> wrote:
>>> A couple of times recently we've had customers or other projects
>>> have serious doubts about Orocos, due to the pain of having to
>>> source build. Being able to build Orocos via package managers
>>> (source or binary) would remove another barrier to people trying/
>>> adopting it.
>>
>> Would people be satisfied with only the gnulinux target packaged ? It
>> would allow easier testing on standard Debian/... environments since
>> no patched kernel nor 3d party packages are required...
>
> No. Personally, we need gnulinux on some machines, and xenomai on
> others. Having a procedure to choose would be best - wonder how
> difficult that will be?
>
>>> We will be creating a Macports portfile in the next few days, and
>>> we will post this to the ML and to Macports (though they're well
>>> known for taking ages to act on new ports). This will alleviate the
>>> issue on the Mac (for Macports users anyway - any Fink users out
>>> there willing to do same?)
>>>
>>> Our primary Linux distro's are Ubuntu/Debian based and while Orocos
>>> has some Debian capability, it is unclear what state it is in, and
>>> there seem to be quite some differences in approach between the
>>> various subprojects (eg RTT, KDL, etc). For RTT itself
>>> * The RTT debian installation instructions do not work completly
>>> for Ubuntu Hardy. They can install the basic RTT, but not rtt-corba
>>> due to some funky versioning problem with ace/tao.
>>
>> I wonder how easy it is to keep both Debian and Ubuntu packaging
>> working in the same tree...
>
> I can take a look next week, and see if I can hack this up. Both
> Ubuntu Hardy and Debain Lenny do not mention the version number within
> the name of the "-dev" packages. Might help.
>
>>> * Building RTT from source via the debian dir in trunk seems to
>>> work, but is only version 1.4 (does require fixing some dependent
>>> packages)
>>
>> No it's not only 1.4. You need to run the scripts to generate the
>> package files:
>> Add a changelog entry using 'debchange -v 1.8.0-0', then run cd
>> debian; ./create-control.sh That should really do it for 1.6 and
>> 1.8,...
>
> I did this the hard way ... :-(
>
> FYI the www.fmtc.be/debian site has v1.6 and v1.4 but trunk/RTT only
> has v1.4.
>
>>> * Neither approach appears to support newer features such as
>>> OmniORB versus ACE/TAO
>>
>> That's true.
>
> Macports variants is nice for this ... though you end up source
> building.
>
>>> * It is unclear whather the build from source approach allows
>>> building a selection of gnulinux, LXRT, and/or Xenomai packages,
>>> instead of building all of them.
>>
>> The problem we have is that the rules file tries to build all targets.
>> We do generate the control file for each target, so maybe we should
>> also generate the rules file.
>
> Agreed.
>
> We will have propogate these changes down into KDL, BFL and OCL too.
> They all the explicit rtai/xenomai dependancy.
I tried to make the debian/ubuntu packaging working for KDL but
because of the different gnulinux/xenomai/rtai targets it was very
hard to create all of the packages on the same machine. Only for KDL I
ended up with 14 different packages for one RTT-KDL version, this was
2 packages for KDL only (lib and dev) and 12 for the RTT-toolkit. I
needed a RTAI-patched kernel, a Xenomai-patched kernel and some hard
to get build-dependencies of the fmtc repos for the amd64 packages.
It became to much hand-crafted and i gave up because at the time i
figured all of it out, a new version of RTT was released and i could
start all over.
> Also, OCL is commited without a generated "debian/control" file. Seems
> to be the only one.
>
>>> Do people feel that as part of the v2.0 push, we should bring all
>>> of this up to date and at least have consistent, buildable Debian/
>>> Ubuntu, Macports, (Fink?) package capability?
>>
>> Of course ! We want it all :-)
>
> :-)))
When is the first Windows auto-installer coming out? :p
Ruben
Source build requirement a detriment to Orocos adoption
We are also using Debian based distro, so being able to build .deb package
is a good opportunity to replace the "make DESTDIR=...".
2009/5/29 <kiwi [dot] net [..] ...>
> A couple of times recently we've had customers or other projects have
> serious doubts about Orocos, due to the pain of having to source build.
> Being able to build Orocos via package managers (source or binary) would
> remove another barrier to people trying/adopting it.
>
> We will be creating a Macports portfile in the next few days, and we will
> post this to the ML and to Macports (though they're well known for taking
> ages to act on new ports). This will alleviate the issue on the Mac (for
> Macports users anyway - any Fink users out there willing to do same?)
>
> Our primary Linux distro's are Ubuntu/Debian based and while Orocos has
> some Debian capability, it is unclear what state it is in, and there seem to
> be quite some differences in approach between the various subprojects (eg
> RTT, KDL, etc). For RTT itself
> * The RTT debian installation instructions do not work completly for Ubuntu
> Hardy. They can install the basic RTT, but not rtt-corba due to some funky
> versioning problem with ace/tao.
> * Building RTT from source via the debian dir in trunk seems to work, but
> is only version 1.4 (does require fixing some dependent packages)
> * Neither approach appears to support newer features such as OmniORB versus
> ACE/TAO
> * It is unclear whather the build from source approach allows building a
> selection of gnulinux, LXRT, and/or Xenomai packages, instead of building
> all of them.
>
> Do people feel that as part of the v2.0 push, we should bring all of this
> up to date and at least have consistent, buildable Debian/Ubuntu, Macports,
> (Fink?) package capability?
>
> S
>
>
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
Source build requirement a detriment to Orocos adoption
A couple of times recently we've had customers or other projects have serious doubts about Orocos, due to the pain of having to source build. Being able to build Orocos via package managers (source or binary) would remove another barrier to people trying/adopting it.
We will be creating a Macports portfile in the next few days, and we will post this to the ML and to Macports (though they're well known for taking ages to act on new ports). This will alleviate the issue on the Mac (for Macports users anyway - any Fink users out there willing to do same?)
Our primary Linux distro's are Ubuntu/Debian based and while Orocos has some Debian capability, it is unclear what state it is in, and there seem to be quite some differences in approach between the various subprojects (eg RTT, KDL, etc). For RTT itself
* The RTT debian installation instructions do not work completly for Ubuntu Hardy. They can install the basic RTT, but not rtt-corba due to some funky versioning problem with ace/tao.
* Building RTT from source via the debian dir in trunk seems to work, but is only version 1.4 (does require fixing some dependent packages)
* Neither approach appears to support newer features such as OmniORB versus ACE/TAO
* It is unclear whather the build from source approach allows building a selection of gnulinux, LXRT, and/or Xenomai packages, instead of building all of them.
Do people feel that as part of the v2.0 push, we should bring all of this up to date and at least have consistent, buildable Debian/Ubuntu, Macports, (Fink?) package capability?
S