Hi,
I think that I have found two bugs in cmake files. First bug is in UseOROCOS-RTT.cmake
. There is used SHARED
keyword for add_executable command. I'm sure that is a bug:).
Second bug is related to orocos-rtt-config.cmake
and orocos-rtt-config.cmake.in
files. In orocos-rtt-config.cmake
file variable OROCOS_SUFFIX
is used to build path to search orocos' components. But this variable is not set, and cmake tries to find components in (..)/lib/orocos/{,plugins,types}
instead in (..)/lib/orocos-{gnulinux,xenomai,..}/{,plugins,types}
. So, I've decided to set OROCOS_SUFFIX
variable in orocos-rtt-config.cmake.in
file to set(OROCOS_SUFFIX "-@OROCOS_TARGET@")
. I don't know if it is correct place to do it.
Best regards,
Adam
Attachment | Size |
---|---|
orocos-rtt-config.cmake_.in_.patch | 489 bytes |
UseOROCOS-RTT.cmake_.patch | 700 bytes |
UseOROCOS-RTT, orocos-rtt-config.cmake - bugs
Hi Adam,
On Fri, Feb 18, 2011 at 9:36 AM, <adam [dot] oleksy [..] ...> wrote:
> Hi,
> I think that I have found two bugs in cmake files. First bug is in
>
UseOROCOS-RTT.cmake
. There is usedSHARED
keyword> for add_executable command. I'm sure that is a bug:).
> Second bug is related to
orocos-rtt-config.cmake
and>
orocos-rtt-config.cmake.in
files. In>
orocos-rtt-config.cmake
file variable>
OROCOS_SUFFIX
is used to build path to search orocos'> components. But this variable is not set, and cmake tries to find components
> in
(..)/lib/orocos/{,plugins,types}
instead in>
(..)/lib/orocos-{gnulinux,xenomai,..}/{,plugins,types}
. So,> I've decided to set
OROCOS_SUFFIX
variable in>
orocos-rtt-config.cmake.in
file to/>
Both issues are already fixed on the master branch (upcoming 2.3). The 'shared'
bug is fixed on toolchain-2.2 as well, but not yet released.
We didn't want to change the installation path of plugins/types in the
2.2 release
cycle since that would break too much systems of people that only want the
latest bugfixes.
You might consider using the bootstrap.sh script to always get the
latest fixes of
a given release, instead of only using the targz/zip releases.
> Best regards,
> Adam
Peter
Hi Peter, Thank you for your
Hi Peter,
Thank you for your answer. I've tried to build orocos-rtt by bootstrap.sh, but it doesn't work for me (I've got message that there is no autoproj). Frankly, I would like to have debian/ubuntu packages, which are easy to install in my robot's system.
Do you plan to provide precompiled binaries for some distributions (like Ubuntu)? Maybe you want somebody, who will maintain precompiled packages?:)
Hi Peter, Thank you for your
On Monday 21 February 2011 16:24:15 adam [dot] oleksy [..] ... wrote:
> Hi Peter,
> Thank you for your answer. I've tried to build orocos-rtt by bootstrap.sh,
> but it doesn't work for me (I've got message that there is no autoproj).
> Frankly, I would like to have debian/ubuntu packages, which are easy to
> install in my robot's system. After resolving some problems with
> build-dependiences, I've build packages (in launchpad ppa) from tar.bz2
> release. But I don't know how I should work with git repositories, when I
> should update etc. For example yesterday, rtt from git didn't compile
> properly:). So, I don't know how release schedule looks like.
>
> Do you plan to provide precompiled binaries for some distributions (like
> Ubuntu)? Maybe you want somebody, who will maintain precompiled
> packages?:)
Building .deb packages is a step I do with every major release, so the debian/
subdirectory of RTT and OCL are maintained.It's true that I didn't update my
ppa anymore. I wanted to build a hudson job for it, but never got around doing
that... If anyone else wants to create a ppa, he's free to do so, and I'll do
my best to keep supporting the Debian/Ubuntu packages.
Note that Orocos can also be downloaded as a Debian package from ROS, but
without orogen yet.
About the git versions, we try to keep all branches stable/compiling at all
times. Which revision did you hit which broke your build ?
Peter
Hi Peter, Thank you for your
Hi Peter,
2011/2/22 Peter Soetens <peter [..] ...>:
>
> Building .deb packages is a step I do with every major release, so the debian/
> subdirectory of RTT and OCL are maintained.It's true that I didn't update my
> ppa anymore. I wanted to build a hudson job for it, but never got around doing
> that... If anyone else wants to create a ppa, he's free to do so, and I'll do
> my best to keep supporting the Debian/Ubuntu packages.
Ok, I will do it in this way. If I have suggestion about content of
debian directory, where can I send it? I've found some "bugs" in
control files (eg build dependencies).
>
> Note that Orocos can also be downloaded as a Debian package from ROS, but
> without orogen yet.
>
> About the git versions, we try to keep all branches stable/compiling at all
> times. Which revision did you hit which broke your build ?
If I remember corectly, this version was from master branch (there
were some problems with header), but now it is unimportant. If I want
build packages in my ppa, which branch should I use?
>
> Peter
>
Adam
Hi Peter, Thank you for your
On Monday 28 February 2011 09:14:03 Adam Oleksy wrote:
> Hi Peter,
>
> 2011/2/22 Peter Soetens <peter [..] ...>:
> > Building .deb packages is a step I do with every major release, so the
> > debian/ subdirectory of RTT and OCL are maintained.It's true that I
> > didn't update my ppa anymore. I wanted to build a hudson job for it, but
> > never got around doing that... If anyone else wants to create a ppa,
> > he's free to do so, and I'll do my best to keep supporting the
> > Debian/Ubuntu packages.
>
> Ok, I will do it in this way. If I have suggestion about content of
> debian directory, where can I send it? I've found some "bugs" in
> control files (eg build dependencies).
This mailing list of course :-) You can also create a bug report on
bugs.orocos.org if you are more comfortable with that. See also
http://www.orocos.org/wiki/orocos/toolchain/contributing
>
> > Note that Orocos can also be downloaded as a Debian package from ROS, but
> > without orogen yet.
> >
> > About the git versions, we try to keep all branches stable/compiling at
> > all times. Which revision did you hit which broke your build ?
>
> If I remember corectly, this version was from master branch (there
> were some problems with header), but now it is unimportant. If I want
> build packages in my ppa, which branch should I use?
The latest toolchain-2.x branch. Currently, toolchain-2.3 is available on
gitorious, being as-good-as what 2.3.0 will be. So you should work on this
one.
Peter