Some further updates...
With the rtt-2.0-mainline set, the autoproj build stops at compiling
orocos.rb (the last step). Since I only care for orogen at this point,
and it was succesfully built I created a test project like in the
manual.
I had to set these paths though, probably because installation was not
completed yet:
export RUBYLIB=$HOME/src/orogen/orocos/orogen/lib:$HOME/src/orogen/build/lib/ruby/1.8:$HOME/src/orogen/build/lib/ruby/1.8/x86_64-linux
export PKG_CONFIG_PATH=$HOME/src/orogen/build/lib/pkgconfig
I also sourced env.sh as instructed.
What is the standard way of doing this ? Shouldn't these exports
belong in the env.sh ?
Next I'll try to find out how the renaming scripts work on the
templates of orogen...
Peter
On Thu, Oct 22, 2009 at 17:18, Peter Soetens <peter [..] ...> wrote:
> Hi Sylvain,
>
> Thanks for showing us all these new sweets !
>
> I'm checking out your system, so here are some initial comments:
>
> * The intallation-how-to page of rubyinmotion contains a wrong link
> behind 'from this page'. Google complains about unsufficient rights.
> * I'd like to have autobuild compile the sources it gets with -j8.
> How can I add this option ?
> * For some reason, it didn't pick up my ccache compiler while it's in
> my PATH. Any clues why ?
> * Is using autoproj also the easiest way to get orogen up and running
> if you don't want the rest ?
> * How can I use an already (deb/manually) installed version of a dependency ?
>
> I switched the source.yml to my own git repository/rtt-2.0-mainline to
> see what it gives (compile errors mostly :-)
>
> It looks like you're integrating orogen into the ros build system too?
> People at PMA are setting up Orocos applications using rosbuild as
> well. Which approach would you prefer ? autoproj smells a bit like
> rosbuild...
>
> Peter
>
>
> On Tue, Oct 20, 2009 at 18:42, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
>> Hello everyone ...
>>
>> As I already mentionned on orocos-dev that I was developping at DFKI a
>> toolchain to develop orocos components (rtt + orogen) *and* for (non-realtime)
>> supervision using Ruby scripting (orocos.rb)
>>
>> ... and that I would be releasing it. So here it is !
>>
>> I also built on top of a build system I developed during my PhD at LAAS to
>> create an easy installation tool for these. It is therefore possible to
>> seamlessly install a whole orocos/rtt + orogen + orocos.rb stack.
>>
>> Here is the link with more installation information.
>> http://sites.google.com/site/rubyinmotion
>>
>> Check in particular this page, that links to some more documentation for
>> orogen and orocos.rb
>> http://sites.google.com/site/rubyinmotion/software/rubimorocos
>>
>>
>> Caveats
>> -------------
>> Parts of the installations describe what OS packages to install that are
>> needed by the rest of the code. For now, I included Debian testing/unstable
>> and Ubuntu 9.04. If you have something different, you either look at *.osdeps
>> files in .remotes/* and update them (I think it is quite straightforward), or
>> you drop me a line so that I help you.
>>
>> orogen is currently adapted to my personal RTT new_data_flow branch. I'll try
>> to find some time to move it to Peter's rtt-2.0-mainline as soon as he merged
>> the final data flow interface he talked about recently, and as soon as I can. I
>> really hope that it won't stop you checking it out !
>>
>> Both orogen and orocos.rb are unfortunately not very open to user-defined
>> toolkits and task contexts. I do think that this is an important feature, but
>> unfortunately I'm not paid to solve all the world's problems ... so I have to
>> go on with other things (that revolve around orocos anyway).
>>
>> I welcome all remarks, both positive and (constructively) negative ones !
>> --
>> Dr. Ing. Sylvain Joyeux
>> Space and Security Robotics
>>
>> DFKI Bremen
>> Robert-Hooke-Straße 5
>> 28359 Bremen, Germany
>>
>> Phone: +49 (0)421 218-64136
>> E-Mail: sylvain [dot] joyeux [..] ...
>>
>> Weitere Informationen: http://www.dfki.de/robotik
>> -----------------------------------------------------------------------
>> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
>> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
>> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
>> (Vorsitzender) Dr. Walter Olthoff
>> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
>> Amtsgericht Kaiserslautern, HRB 2313
>> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
>> USt-Id.Nr.: DE 148646973
>> Steuernummer: 19/673/0060/3
>> ---------------------------------------------------------------------
>> --
>> Orocos-Dev mailing list
>> Orocos-Dev [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>>
>
Orocos+Ruby toolchain
On Friday 23 October 2009 11:11:11 Peter Soetens wrote:
> Some further updates...
>
> With the rtt-2.0-mainline set, the autoproj build stops at compiling
> orocos.rb (the last step). Since I only care for orogen at this point,
> and it was succesfully built I created a test project like in the
> manual.
> I had to set these paths though, probably because installation was not
> completed yet:
>
> export
> RUBYLIB=$HOME/src/orogen/orocos/orogen/lib:$HOME/src/orogen/build/lib/ruby
> /1.8:$HOME/src/orogen/build/lib/ruby/1.8/x86_64-linux export
> PKG_CONFIG_PATH=$HOME/src/orogen/build/lib/pkgconfig
>
> I also sourced env.sh as instructed.
>
> What is the standard way of doing this ? Shouldn't these exports
> belong in the env.sh ?
Yes, but the env.sh is generated at the end of a successful build to avoid
overwriting a complete env.sh by a partial one. I'm thinking about the best
way to handle this case. I should probably create a partial env.sh if it does
not exist yet. See my previous mail to disable the build of orocos.rb in your
installation.
> Next I'll try to find out how the renaming scripts work on the
> templates of orogen...
I don't think this is needed. The templates expose very little of the RTT
internals, so the transition should be painless. Right now, the only user-
visible change are the new return values of Port#read().
Sylvain
Orocos+Ruby toolchain
On Fri, Oct 23, 2009 at 11:22, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> On Friday 23 October 2009 11:11:11 Peter Soetens wrote:
>> Some further updates...
>>
>> With the rtt-2.0-mainline set, the autoproj build stops at compiling
>> orocos.rb (the last step). Since I only care for orogen at this point,
>> and it was succesfully built I created a test project like in the
>> manual.
>> I had to set these paths though, probably because installation was not
>> completed yet:
>>
>> export
>> RUBYLIB=$HOME/src/orogen/orocos/orogen/lib:$HOME/src/orogen/build/lib/ruby
>> /1.8:$HOME/src/orogen/build/lib/ruby/1.8/x86_64-linux export
>> PKG_CONFIG_PATH=$HOME/src/orogen/build/lib/pkgconfig
>>
>> I also sourced env.sh as instructed.
>>
>> What is the standard way of doing this ? Shouldn't these exports
>> belong in the env.sh ?
> Yes, but the env.sh is generated at the end of a successful build to avoid
> overwriting a complete env.sh by a partial one. I'm thinking about the best
> way to handle this case. I should probably create a partial env.sh if it does
> not exist yet. See my previous mail to disable the build of orocos.rb in your
> installation.
Ok, will try.
>
>> Next I'll try to find out how the renaming scripts work on the
>> templates of orogen...
> I don't think this is needed. The templates expose very little of the RTT
> internals, so the transition should be painless. Right now, the only user-
> visible change are the new return values of Port#read().
It was quite straightforward, see the patch in attachment for orogen.
I tried it on your example, but it wouldn't compile as long as I used
std::vector (not related to 2.0 transition). There's clearly something
missing in the docs.
Also when running rake dist:test, I get tons of ' warning: instance
variable @toolkit not initialized' warnings. Annoying.
These issues remain when running rake dist:test:
* ReadOnlyPointer does not have a default constructor. It should also
have a copy constructor and assignment operator. This is required for
OutputPort<ReadOnlyPointer
relying on the default copy constructor... How do you suggest to fix
this ?
* One of your tests uses rtt/marsh/XMLMarshaller.hpp. I removed this
class from the 2.0 branch since it's pretty useless. I don't know why
your test needs it.
* template<typename T> struct BufferGetter : public
RTT::types::TypeTransporter in Toolkit.cpp implements createBlob.
TypeTransporter no longer has these functions. How is this used ? The
equivalents in ToolkitCorba.cpp, which inherit from the
CorbaTemplateTypeInfo are ok, but had to be renamed from
createBlob/updateBlob to createAny/updateFromAny.If you require a form
of createBlob, you need to define your own subclass of TypeTransporter
which has these as virtuals, and then inherit BufferGetter from that
class. (it looks like you're not using the ORO_TYPELIB_MARSHALLER_ID
transport though).
Peter
Orocos+Ruby toolchain
Here's a snippet of conversation I had with Peter related to autoproj vs.
rosbuild.
First of all, some of you may (or may not) have noticed that autoproj does use
manifest.xml and osdeps files, using the same format than rosbuild. This is
because autoproj also requires this information and I did not want to reinvent
the wheel.
That being said, I did not "do" autoproj just for the fun of it (disclaimer:
this is not fun).
>> People at PMA are setting up Orocos applications using rosbuild as
>> well. Which approach would you prefer ? autoproj smells a bit like
>> rosbuild...
>
>The main differences are:
> - autoproj manages the VCS for you. In the case of ROS, it is not very
> important as they have a set of big SVNs. In my case, we have one git per
> package so that is very important. autoproj adds some sweetness to that:
> "autoproj status"
> - autoproj handles code generation properly
> - autoproj does autodetection of dependencies for orogen projects (no need
> to fill the manifest.xml with dependencies that are listed in the .orogen
> file ;-))
I would add that rosbuild is *really* too verbose and too difficult to customize
for my taste. But YMMV.
And to answer the "but you could have extended rosbuild instead": I developped
the code that is now the guts of autoproj in early 2006 at LAAS. autoproj just
adds a nicer configuration interface on top of it. Making autoproj-like
functionality on top of rosbuild would have required redevelopping that part,
and therefore would have been much more work.
Sylvain
Orocos+Ruby toolchain
Documentation related to customization can be found there:
http://doudou.github.com/autoproj/customization.html
On Thursday 22 October 2009 17:18:58 Peter Soetens wrote:
> * I'd like to have autobuild compile the sources it gets with -j8.
> How can I add this option ?
Add
Autobuild.parallel_build_level = 8
in autoproj/init.rb
> * For some reason, it didn't pick up my ccache compiler while it's in
> my PATH. Any clues why ?
Autoproj prior to 1.4 were resetting the environment to the a default value.
This is not the case anymore, so that should work fine now. Add
Autoproj.set_initial_env
in autoproj/init.rb to go back to the old behavior.
> * Is using autoproj also the easiest way to get orogen up and running
> if you don't want the rest ?
Yes. The catch being that orogen needs "the rest".
> * How can I use an already (deb/manually) installed version of a
> dependency ?
List it in the ignore_packages section of autoproj/manifest
Orocos+Ruby toolchain
On Sun, Oct 25, 2009 at 13:14, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> Update: I pushed a new version of autobuild/autoproj ...
>
> Documentation related to customization can be found there:
>
> http://doudou.github.com/autoproj/customization.html
>
> On Thursday 22 October 2009 17:18:58 Peter Soetens wrote:
>> * I'd like to have autobuild compile the sources it gets with -j8.
>> How can I add this option ?
> Add
> Autobuild.parallel_build_level = 8
> in autoproj/init.rb
>
>> * For some reason, it didn't pick up my ccache compiler while it's in
>> my PATH. Any clues why ?
> Autoproj prior to 1.4 were resetting the environment to the a default value.
> This is not the case anymore, so that should work fine now. Add
>
> Autoproj.set_initial_env
> in autoproj/init.rb to go back to the old behavior.
>
>> * Is using autoproj also the easiest way to get orogen up and running
>> if you don't want the rest ?
> Yes. The catch being that orogen needs "the rest".
>
>> * How can I use an already (deb/manually) installed version of a
>> dependency ?
> List it in the ignore_packages section of autoproj/manifest
I'm having a dependency problem now, and don't know what caused it. It
always tries to build ocl before rtt. The output is:
$ autoproj force-build autoproj: installing prepackaged dependencies to access the source definitions installing/updating OS dependencies: git autoproj: updating remote definitions of package sets updating git_git___github_com_doudou_rubim_orocos_git autoproj: loading build files and configuring build run 'autoproj --reconfigure' to change configuration values build RTT-related software with CORBA support: true the target operating system for Orocos/RTT (gnulinux or xenomai): gnulinux autoproj: installing prepackaged dependencies for build system & version control installing/updating OS dependencies: cmake autoproj: now building / updating packages updating utilmm updating typelib updating orocos/orogen updating orocos/ocl WARN: orocos/ocl from rubim.orocos does not have a manifest updating utilrb updating orocos/rtt WARN: orocos/rtt from rubim.orocos does not have a manifest installing prepackaged dependencies installing/updating OS dependencies: boost, antlr, doxygen, ruby building and installing packages generating and configuring build system for utilmm building utilmm (100%) installing utilmm setting up Ruby package utilrb generating and configuring build system for typelib building typelib (100%) installing typelib generating and configuring build system for orocos/ocl Build failed: orocos/ocl: failed in configure phase 'cmake -DCMAKE_INSTALL_PREFIX=/home/kaltan/src/orogen/build -DOROCOS_TARGET=gnulinux -DBUILD_CARTESIAN=OFF -DBUILD_MOTION=OFF -DBUILD_TIMER=OFF -DBUILD_DEPLOYMENT=OFF -DBUILD_VIEWER=OFF -DBUILD_NAXES=OFF -DBUILD_TESTS=OFF -DBUILD_HARDWARE=OFF -DBUILD_HELLOWORLD=OFF -DBUILD_REPORTING=OFF /home/kaltan/src/orogen/orocos/ocl' returned status 1 see /home/kaltan/src/orogen/build/log/orocos/ocl-configure.log for details last 10 lines are: Searching RTT in /home/kaltan/src/orogen/build: -- Looking for orocos-rtt >= 1.1.0 -- not found -- Looking for orocos-rtt >= 1.0.0 -- not found CMake Error at config/FindOrocosRTT.cmake:151 (MESSAGE): Can't find Orocos Real-Time Toolkit (orocos-rtt.pc) Call Stack (most recent call first): CMakeLists.txt:143 (INCLUDE) -- Configuring incomplete, errors occurred! <code> Also, I found the overrides.yml file very sensitive to white spaces. It first didn't pickup my overrides, because there was no additional indentation in the sub points. Any clue where I can find how to influence the build order ? PeterOrocos+Ruby toolchain
On Monday 26 October 2009 16:57:18 you wrote:
> I'm having a dependency problem now, and don't know what caused it. It
> always tries to build ocl before rtt. The output is:
Mmmmm ... What is your configuration ? Did you list the orocos/rtt in the
ignored_packages section ?
<snip CMake failure>
My guess is that the OCL cmake code on my git repository (that comes from the
official one) messes up with PKG_CONFIG_PATH, and therefore requires that RTT
and OCL are installed in the same prefix. I discovered that yesterday ....
> Also, I found the overrides.yml file very sensitive to white spaces.
> It first didn't pickup my overrides, because there was no additional
> indentation in the sub points.
The overrides file is YAML so it requires that you write YAML properly. Among
other things, it requires proper indentation. I'll add a note in the
documentation about it.
> Any clue where I can find how to influence the build order ?
Build order is determined by dependencies and then by place in the layout
section. What is your problem ?
Orocos+Ruby toolchain
On Mon, Oct 26, 2009 at 17:27, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> On Monday 26 October 2009 16:57:18 you wrote:
>> I'm having a dependency problem now, and don't know what caused it. It
>> always tries to build ocl before rtt. The output is:
> Mmmmm ... What is your configuration ? Did you list the orocos/rtt in the
> ignored_packages section ?
No. I added this to my overrides.yml file:
version_control:
- orocos/rtt:
type: git
url: git [..] ...:psoetens/orocos-rtt.git
branch: rtt-2.0-mainline
- orocos/ocl:
type: git
url: git [..] ...:psoetens/orocos-ocl.git
branch: ocl-2.0-mainline
- orocos/orogen:
type: git
url: git [..] ...:psoetens/orogen.git
branch: new_data_flow
And changed this in my .remotes:
diff --git a/orocos.autobuild b/orocos.autobuild
index 62e5fe5..842cafe 100644
--- a/orocos.autobuild
+++ b/orocos.autobuild
@@ -30,7 +30,7 @@ end
# Install the OCL only to get the task browser
cmake_package 'orocos/ocl' do |pkg|
- %w{REPORTING HELLOWORLD DEPLOYMENT HARDWARE TESTS TIMER VIEWER}.
+ %w{REPORTING HELLOWORLD DEPLOYMENT HARDWARE TESTS TIMER VIEWER
MOTION CARTESIAN NAXES}.
each { |name| pkg.define "BUILD_#{name}", "OFF" }
target = user_config('rtt_target')
>
> <snip CMake failure>
>
> My guess is that the OCL cmake code on my git repository (that comes from the
> official one) messes up with PKG_CONFIG_PATH, and therefore requires that RTT
> and OCL are installed in the same prefix. I discovered that yesterday ....
No no, I build everything using autoproj.
>
>> Also, I found the overrides.yml file very sensitive to white spaces.
>> It first didn't pickup my overrides, because there was no additional
>> indentation in the sub points.
> The overrides file is YAML so it requires that you write YAML properly. Among
> other things, it requires proper indentation. I'll add a note in the
> documentation about it.
>
>> Any clue where I can find how to influence the build order ?
> Build order is determined by dependencies and then by place in the layout
> section. What is your problem ?
I found it. It looks like when my manifest layout is:
layout:
- typelib
- utilmm
- utilrb
- orocos/orogen
- orocos/ocl
- orocos/rtt
It works, but when I change it to:
layout:
- typelib
- utilmm
- utilrb
- orocos/rtt
- orocos/ocl
- orocos/orogen
It doesn't. It looks like the layout is processed in the wrong direction ??
Peter
Orocos+Ruby toolchain
On Monday 26 October 2009 17:36:32 Peter Soetens wrote:
> On Mon, Oct 26, 2009 at 17:27, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
wrote:
> > On Monday 26 October 2009 16:57:18 you wrote:
> >> I'm having a dependency problem now, and don't know what caused it. It
> >> always tries to build ocl before rtt. The output is:
> >
> > Mmmmm ... What is your configuration ? Did you list the orocos/rtt in the
> > ignored_packages section ?
>
> No. I added this to my overrides.yml file:
>
> version_control:
> - orocos/rtt:
> type: git
> url: git [..] ...:psoetens/orocos-rtt.git
> branch: rtt-2.0-mainline
> - orocos/ocl:
> type: git
> url: git [..] ...:psoetens/orocos-ocl.git
> branch: ocl-2.0-mainline
> - orocos/orogen:
> type: git
> url: git [..] ...:psoetens/orogen.git
> branch: new_data_flow
First, could you work on a rtt2 branch on your orogen so that we don't mix up
unnecessarily ?
Second, I guess you did not add a manifest.xml file that lists the dependencies
of the OCL, so obviously autoproj cannot solve the dependencies. Look at my
version of the OCL to check out the manifest. As a temporary solution you can
add
ocl = Autobuild::Packages['orocos/ocl']
ocl.depends_on "orocos/rtt"
in your autoproj/overrides.rb file.
> And changed this in my .remotes:
>
> diff --git a/orocos.autobuild b/orocos.autobuild
> index 62e5fe5..842cafe 100644
> --- a/orocos.autobuild
> +++ b/orocos.autobuild
> @@ -30,7 +30,7 @@ end
>
> # Install the OCL only to get the task browser
> cmake_package 'orocos/ocl' do |pkg|
> - %w{REPORTING HELLOWORLD DEPLOYMENT HARDWARE TESTS TIMER VIEWER}.
> + %w{REPORTING HELLOWORLD DEPLOYMENT HARDWARE TESTS TIMER VIEWER
> MOTION CARTESIAN NAXES}.
> each { |name| pkg.define "BUILD_#{name}", "OFF" }
>
> target = user_config('rtt_target')
>
What you would better do is edit autoproj/overrides.rb and add
ocl = Autobuild::Package['orocos/ocl']
ocl.define "BUILD_MOTION=NO"
ocl.define "BUILD_CARTESIAN=NO"
ocl.define "BUILD_NAXES=NO"
to avoid issues.
> > Build order is determined by dependencies and then by place in the layout
> > section. What is your problem ?
>
> I found it. It looks like when my manifest layout is:
>
> layout:
> - typelib
> - utilmm
> - utilrb
> - orocos/orogen
> - orocos/ocl
> - orocos/rtt
>
> It works, but when I change it to:
>
> layout:
> - typelib
> - utilmm
> - utilrb
> - orocos/rtt
> - orocos/ocl
> - orocos/orogen
>
> It doesn't. It looks like the layout is processed in the wrong direction ??
This works just by chance. The layout determines order for subdirectories. For
instance, in my project we do:
layout:
- tools:
dfki.orocos
- asguard:
dfki.drivers
In that case, autoproj builds all in tools/ and only then will build all in
asguard/.
But in your case, the build order is only determined by dependencies since
there is only one level in the layout. So, to change it, either fix your
manifest.xml files or add code in the overrides.rb.
Orocos+Ruby toolchain
On Mon, Oct 26, 2009 at 18:01, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> On Monday 26 October 2009 17:36:32 Peter Soetens wrote:
>> On Mon, Oct 26, 2009 at 17:27, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> wrote:
>> > On Monday 26 October 2009 16:57:18 you wrote:
>> >> I'm having a dependency problem now, and don't know what caused it. It
>> >> always tries to build ocl before rtt. The output is:
>> >
>> > Mmmmm ... What is your configuration ? Did you list the orocos/rtt in the
>> > ignored_packages section ?
>>
>> No. I added this to my overrides.yml file:
>>
>> version_control:
>> - orocos/rtt:
>> type: git
>> url: git [..] ...:psoetens/orocos-rtt.git
>> branch: rtt-2.0-mainline
>> - orocos/ocl:
>> type: git
>> url: git [..] ...:psoetens/orocos-ocl.git
>> branch: ocl-2.0-mainline
>> - orocos/orogen:
>> type: git
>> url: git [..] ...:psoetens/orogen.git
>> branch: new_data_flow
>
> First, could you work on a rtt2 branch on your orogen so that we don't mix up
> unnecessarily ?
I was doing so in another repo, you just saw part of my 'messing with
stuff'. I'll push a rtt-2.0-mainline branch to github for orogen.
>
> Second, I guess you did not add a manifest.xml file that lists the dependencies
> of the OCL, so obviously autoproj cannot solve the dependencies. Look at my
> version of the OCL to check out the manifest. As a temporary solution you can
> add
>
> ocl = Autobuild::Packages['orocos/ocl']
> ocl.depends_on "orocos/rtt"
>
> in your autoproj/overrides.rb file.
I'll add the manifest. I tried to merge your new_data_flow changes
into the mainline. git didn't succeed into tracking all my renames ( I
probably shouldn't have done it in one huge commit ). So it fails to
track some files. The result of a merge is:
orocos/rtt(rtt-2.0-mainline-merge-ndf|MERGING) $ git status
src/FileDescriptorActivity.hpp: needs merge
src/PortInterface.cpp: needs merge
src/ReadWritePointer.hpp: needs merge
src/base/DataSourceBase.hpp: needs merge
src/corba/DataFlowI.cpp: needs merge
src/corba/RemotePorts.cpp: needs merge
src/extras/FileDescriptorActivity.cpp: needs merge
src/internal/DataSource.cpp: needs merge
src/os/gnulinux/fosi.h: needs merge
src/transports/corba/CorbaTemplateProtocol.hpp: needs merge
src/types/TypeInfo.hpp: needs merge
src/types/TypeInfoName.hpp: needs merge
src/types/TypeTransporter.hpp: needs merge
# On branch rtt-2.0-mainline-merge-ndf
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: manifest.xml
# modified: src/TaskContext.cpp
# modified: src/TaskContext.hpp
# modified: src/os/rtconversions.cpp
# modified: src/transports/corba/CorbaLib.cpp
# modified: src/types/TemplateTypeInfo.hpp
# modified: src/types/Types.cpp
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# unmerged: src/FileDescriptorActivity.hpp
# unmerged: src/PortInterface.cpp
# unmerged: src/ReadWritePointer.hpp
# unmerged: src/base/DataSourceBase.hpp
# unmerged: src/corba/DataFlowI.cpp
# unmerged: src/corba/RemotePorts.cpp
# unmerged: src/extras/FileDescriptorActivity.cpp
# unmerged: src/internal/DataSource.cpp
# unmerged: src/os/gnulinux/fosi.h
# unmerged: src/transports/corba/CorbaTemplateProtocol.hpp
# unmerged: src/types/TypeInfo.hpp
# unmerged: src/types/TypeInfoName.hpp
# unmerged: src/types/TypeTransporter.hpp
#
The only wrongly tracked files are
src/corba/DataFlowI.cpp,src/corba/RemotePorts.cpp,
FileDescriptorActivity.hpp, PortInterface.cpp and
ReadWritePointer.hpp. There are a bunch of conflicts. I tested a
rebase too, 6 patches applied cleanly, the rest not. The rebase seemed
a bit confused too, we're not gonna use it anyway.
Anyway, dataports&transports changed so much internally, that any
changes will just be harder to back-port.
What I do need from this branch are the bugfixes (there are some) and
the manifest files. There is some stuff going on in TypeInfo and
TypeTransporter that I don't need, or has become obsolete.
Suggested course of action ?
Peter
Orocos+Ruby toolchain
On Monday 26 October 2009 18:01:01 Sylvain Joyeux wrote:
> ocl = Autobuild::Package['orocos/ocl']
> ocl.define "BUILD_MOTION=NO"
> ocl.define "BUILD_CARTESIAN=NO"
> ocl.define "BUILD_NAXES=NO"
The careful reader would have of course have read
ocl = Autobuild::Package['orocos/ocl']
ocl.define "BUILD_MOTION", "NO"
ocl.define "BUILD_CARTESIAN", "NO"
ocl.define "BUILD_NAXES", "NO"
Sylvain
Orocos+Ruby toolchain
On Sun, Oct 25, 2009 at 13:14, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> Update: I pushed a new version of autobuild/autoproj ...
>
> Documentation related to customization can be found there:
>
> http://doudou.github.com/autoproj/customization.html
>
> On Thursday 22 October 2009 17:18:58 Peter Soetens wrote:
>> * I'd like to have autobuild compile the sources it gets with -j8.
>> How can I add this option ?
> Add
> Autobuild.parallel_build_level = 8
> in autoproj/init.rb
>
>> * For some reason, it didn't pick up my ccache compiler while it's in
>> my PATH. Any clues why ?
> Autoproj prior to 1.4 were resetting the environment to the a default value.
> This is not the case anymore, so that should work fine now. Add
>
> Autoproj.set_initial_env
> in autoproj/init.rb to go back to the old behavior.
>
>> * Is using autoproj also the easiest way to get orogen up and running
>> if you don't want the rest ?
> Yes. The catch being that orogen needs "the rest".
>
>> * How can I use an already (deb/manually) installed version of a
>> dependency ?
> List it in the ignore_packages section of autoproj/manifest
Thanks for the updates. I'll try them out.
After re-boostrapping in the same dir, the update fails with:
vader ~/src/orogen $ autoproj update
autoproj: installing prepackaged dependencies to access the source definitions
installing/updating OS dependencies: git
autoproj: updating remote definitions of package sets
updating git_git___github_com_doudou_rubim_orocos_git
Build failed: git_git___github_com_doudou_rubim_orocos_git: failed in
import phase
'git merge 13f2ee22f6e80948b1feba7279aa79ca7b31b1ed' returned status 1
see /home/kaltan/src/orogen/build/log/git_git___github_com_doudou_rubim_orocos_git-import.log
for details
last 5 lines are:
Mon Oct 26 13:50:07 +0100 2009: running
git merge 13f2ee22f6e80948b1feba7279aa79ca7b31b1ed
error: Entry 'orocos.autobuild' not uptodate. Cannot merge.
Updating 3fab3c1..13f2ee2
It seems this is happening in the hidden .remotes directory. The only
thing I changed was importing my orogen branch & remote branches in
the orogen directory.
Peter