Running orogen's test suite

When you modify the typekit's code, I would be glad if you could run
the corresponding part of the test suite ... The ROS modifications to
the build system nicely broke orogen's integrated typekits.

This is as simple as

testrb test/test_typekit.rb

Thanks in advance.

Sylvain

Running orogen's test suite

On 11/08/2010 11:08 AM, Peter Soetens wrote:
>> Yes, that would be a way.
>>
>> But be my guest here. I'm tired of having people run on code I don't
>> run, so I'm pushing very hard the RTT2 migration here. Which means I
>> really don't have time fixing bugs that other people introduce. I will
>> continue answering questions, but I am not going to investigate as to
>> the issues themselves.
> I'm completely on your side: if a patch breaks stuff, we have to revert it,
> until a proper one is proposed. But since my use case leans closer to
> Steven's, I'm eager to help him out fixing all remaining issues. It's clear now
> that these issues were not so minor, and all should have happened on a
> separate branch. If we knew about the unit tests, this would have been
> avoided, in the first place.
In general, do *not* push non-trivial patches to oroGen until I give the
all-clear. You are using 10% of oroGen's functionality, so you *will*
most probably break stuff. The test suite is OK but not comprehensive.

>> I would advise to wait a bit on your investigations, though, as I am
>> going to refactor the opaque-handling code to make it a lot simpler
>> (hence, easier to debug for you).
> So I propose we try to branch out all possible show-stoppers to a
> toolchain-2.1-ros branch. I can do a bisect to find that intersection point and
> revert all patches upto that point. You would then confirm that toolchain-2.1
> is stable again, we merge all remaining work, and Steven and I continue to
> rebase the -ros branch on that work until we get the unit tests working again,
> and you see no problem either. Then we merge all that for 2.2.
Sounds fine.

>> That was one of the paths in the future. There is this
>> RTT-typekit/all-other-typekits dichotomy in orogen right now, and I'd
>> rather have all orogen projects depend on orogen typekits. But I am not
>> sure I can even do it, so I'll see in the future.
>>
>> The "load everything" problem is that I don't see the point of loading
>> 100+ type definitions in every components while the tooling *knows* what
>> are the typekits these components need.
> OR 2. install the typekits in project specific subdirs of the
> lib/orocos tree, which will never be searched by default by the plugin loader.
> Only the lib/orocos/types dir is loaded by default (and any other dir in the
> RTT_COMPONENT_PATH).

Running orogen's test suite

On Monday 08 November 2010 11:29:29 Sylvain Joyeux wrote:
> On 11/08/2010 11:08 AM, Peter Soetens wrote:
> >> Yes, that would be a way.
> >>
> >> But be my guest here. I'm tired of having people run on code I don't
> >> run, so I'm pushing very hard the RTT2 migration here. Which means I
> >> really don't have time fixing bugs that other people introduce. I will
> >> continue answering questions, but I am not going to investigate as to
> >> the issues themselves.
> >
> > I'm completely on your side: if a patch breaks stuff, we have to revert
> > it, until a proper one is proposed. But since my use case leans closer
> > to Steven's, I'm eager to help him out fixing all remaining issues. It's
> > clear now that these issues were not so minor, and all should have
> > happened on a separate branch. If we knew about the unit tests, this
> > would have been avoided, in the first place.
>
> In general, do *not* push non-trivial patches to oroGen until I give the
> all-clear. You are using 10% of oroGen's functionality, so you *will*
> most probably break stuff. The test suite is OK but not comprehensive.
>
> >> I would advise to wait a bit on your investigations, though, as I am
> >> going to refactor the opaque-handling code to make it a lot simpler
> >> (hence, easier to debug for you).
> >
> > So I propose we try to branch out all possible show-stoppers to a
> > toolchain-2.1-ros branch. I can do a bisect to find that intersection
> > point and revert all patches upto that point. You would then confirm
> > that toolchain-2.1 is stable again, we merge all remaining work, and
> > Steven and I continue to rebase the -ros branch on that work until we
> > get the unit tests working again, and you see no problem either. Then we
> > merge all that for 2.2.
>
> Sounds fine.

I can't find a 'good' version to start the bisecting. We started modifying
orogen on top of 1a5b0ef which does not pass its own unit tests. I then
forwarded my head to 07f2a8ce "Revert changing findRTT cmake logic" (the one
you proposed), It still doesn't pass.

Could you specify a revision of orogen that certainly works at your side ?

>
> >> That was one of the paths in the future. There is this
> >> RTT-typekit/all-other-typekits dichotomy in orogen right now, and I'd
> >> rather have all orogen projects depend on orogen typekits. But I am not
> >> sure I can even do it, so I'll see in the future.
> >>
> >> The "load everything" problem is that I don't see the point of loading
> >> 100+ type definitions in every components while the tooling *knows* what
> >> are the typekits these components need.
> >
> > OR 2. install the typekits in project specific subdirs of the
> > lib/orocos tree, which will never be searched by default by the plugin
> > loader. Only the lib/orocos/types dir is loaded by default (and any
> > other dir in the RTT_COMPONENT_PATH).
>
> Eeehhh. Fine, but in oroGen's case it will mean having folders with --
> each time -- only one library. Hardly nice.

Why don't you put your stuff then in lib/orocos/orogen ?

Peter

Running orogen's test suite

On 11/08/2010 02:35 PM, Peter Soetens wrote:
> On Monday 08 November 2010 11:29:29 Sylvain Joyeux wrote:
>> On 11/08/2010 11:08 AM, Peter Soetens wrote:
>>>> Yes, that would be a way.
>>>>
>>>> But be my guest here. I'm tired of having people run on code I don't
>>>> run, so I'm pushing very hard the RTT2 migration here. Which means I
>>>> really don't have time fixing bugs that other people introduce. I will
>>>> continue answering questions, but I am not going to investigate as to
>>>> the issues themselves.
>>> I'm completely on your side: if a patch breaks stuff, we have to revert
>>> it, until a proper one is proposed. But since my use case leans closer
>>> to Steven's, I'm eager to help him out fixing all remaining issues. It's
>>> clear now that these issues were not so minor, and all should have
>>> happened on a separate branch. If we knew about the unit tests, this
>>> would have been avoided, in the first place.
>> In general, do *not* push non-trivial patches to oroGen until I give the
>> all-clear. You are using 10% of oroGen's functionality, so you *will*
>> most probably break stuff. The test suite is OK but not comprehensive.
>>
>>>> I would advise to wait a bit on your investigations, though, as I am
>>>> going to refactor the opaque-handling code to make it a lot simpler
>>>> (hence, easier to debug for you).
>>> So I propose we try to branch out all possible show-stoppers to a
>>> toolchain-2.1-ros branch. I can do a bisect to find that intersection
>>> point and revert all patches upto that point. You would then confirm
>>> that toolchain-2.1 is stable again, we merge all remaining work, and
>>> Steven and I continue to rebase the -ros branch on that work until we
>>> get the unit tests working again, and you see no problem either. Then we
>>> merge all that for 2.2.
>> Sounds fine.
> I can't find a 'good' version to start the bisecting. We started modifying
> orogen on top of 1a5b0ef which does not pass its own unit tests. I then
> forwarded my head to 07f2a8ce "Revert changing findRTT cmake logic" (the one
> you proposed), It still doesn't pass.
> Could you specify a revision of orogen that certainly works at your side ?
07f2a8ce passes its test suite on my side (except a few issues with
activity tests but that is expected). I suggest that we move
toolchain-2.1 back to this commit.

Otherwise, can you
- go to 07f2a8ce
- run testrb
- send me the full log (output + test results)

Sylvain

Running orogen's test suite

[...]

>> I can't find a 'good' version to start the bisecting. We started modifying
>> orogen on top of 1a5b0ef which does not pass its own unit tests. I then
>> forwarded my head to 07f2a8ce "Revert changing findRTT cmake logic" (the one
>> you proposed), It still doesn't pass.
>> Could you specify a revision of orogen that certainly works at your side ?
> 07f2a8ce passes its test suite on my side (except a few issues with
> activity tests but that is expected). I suggest that we move
> toolchain-2.1 back to this commit.
>
> Otherwise, can you
>  - go to 07f2a8ce
>  - run testrb
>  - send me the full log (output + test results)

That's the commit I am working on.
The full log from my side is already posted in this thread.

Steven

>
> Sylvain
>
>

Running orogen's test suite

On 11/08/2010 08:30 PM, Steven Bellens wrote:
> [...]
>
>>> I can't find a 'good' version to start the bisecting. We started modifying
>>> orogen on top of 1a5b0ef which does not pass its own unit tests. I then
>>> forwarded my head to 07f2a8ce "Revert changing findRTT cmake logic" (the one
>>> you proposed), It still doesn't pass.
>>> Could you specify a revision of orogen that certainly works at your side ?
>> 07f2a8ce passes its test suite on my side (except a few issues with
>> activity tests but that is expected). I suggest that we move
>> toolchain-2.1 back to this commit.
>>
>> Otherwise, can you
>> - go to 07f2a8ce
>> - run testrb
>> - send me the full log (output + test results)
>
> That's the commit I am working on.
> The full log from my side is already posted in this thread.
This log is pretty useless

* set TEST_KEEP_WC=1 to keep the working copy around
* run
testrb test_typekit.rb -n test_simple_typelib
* go in wc/modules/simple (or something like that, I don't really
remember) and run
make -C build VERBOSE=1
* look at why the typelib header is not found (what is missing ? Are
the cflags listed in typelib's pkg-config used to build the file,
this kind of things)

Sylvain

Running orogen's test suite

2010/11/9 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
> On 11/08/2010 08:30 PM, Steven Bellens wrote:
>> [...]
>>
>>>> I can't find a 'good' version to start the bisecting. We started modifying
>>>> orogen on top of 1a5b0ef which does not pass its own unit tests. I then
>>>> forwarded my head to 07f2a8ce "Revert changing findRTT cmake logic" (the one
>>>> you proposed), It still doesn't pass.
>>>> Could you specify a revision of orogen that certainly works at your side ?
>>> 07f2a8ce passes its test suite on my side (except a few issues with
>>> activity tests but that is expected). I suggest that we move
>>> toolchain-2.1 back to this commit.
>>>
>>> Otherwise, can you
>>>   - go to 07f2a8ce
>>>   - run testrb
>>>   - send me the full log (output + test results)
>>
>> That's the commit I am working on.
>> The full log from my side is already posted in this thread.
> This log is pretty useless
>
>  * set TEST_KEEP_WC=1 to keep the working copy around
>  * run
>    testrb test_typekit.rb -n test_simple_typelib
>  * go in wc/modules/simple (or something like that, I don't really
>    remember) and run
>    make -C build VERBOSE=1
>  * look at why the typelib header is not found (what is missing ? Are
>    the cflags listed in typelib's pkg-config used to build the file,
>    this kind of things)

The typelib include dir is not listed in the make command:

[ 55%] Building CXX object
.orogen/typekit/transports/typelib/CMakeFiles/simple-transport-typelib-gnulinux.dir/Test_BASIC_ENUM.cpp.o
cd /home/u0063509/src/svn/cturtle/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple/build/.orogen/typekit/transports/typelib
&& /usr/bin/c++ -Dsimple_transport_typelib_gnulinux_EXPORTS
-DOROCOS_TARGET=gnulinux -g -fPIC
-I/home/u0063509/src/svn/cturtle/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple/.orogen/typekit/types
-I/home/u0063509/src/svn/cturtle/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple/build/.orogen/typekit
-I/home/u0063509/src/svn/cturtle/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple
-I/home/u0063509/src/svn/cturtle/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple/.orogen
-I/home/u0063509/src/svn/cturtle/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple/.orogen/typekit
-I/home/u0063509/src/svn/cturtle/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/rtt/install/include
-o CMakeFiles/simple-transport-typelib-gnulinux.dir/Test_BASIC_ENUM.cpp.o
-c /home/u0063509/src/svn/cturtle/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple/.orogen/typekit/transports/typelib/Test_BASIC_ENUM.cpp
In file included from
/home/u0063509/src/svn/cturtle/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple/.orogen/typekit/transports/typelib/TypelibMarshaller.hpp:6:0,
from
/home/u0063509/src/svn/cturtle/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple/.orogen/typekit/transports/typelib/Test_BASIC_ENUM.cpp:4:
/home/u0063509/src/svn/cturtle/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple/.orogen/typekit/transports/typelib/TypelibMarshallerBase.hpp:9:32:
fatal error: typelib/value_ops.hh: No such file or directory
compilation terminated.

I'm not that of a Cmake expert to know how to add it. The
CMakeLists.txt however does list
ADD_DEFINITIONS(-DWITH_TYPELIB).

I would be surprised if I'm the only one having this problem...?

Steven

>
> Sylvain
>

Running orogen's test suite

On 11/10/2010 01:59 PM, Steven Bellens wrote:
> I'm not that of a Cmake expert to know how to add it. The
> CMakeLists.txt however does list
> ADD_DEFINITIONS(-DWITH_TYPELIB).
>
> I would be surprised if I'm the only one having this problem...?
rosbuild does not install stuff. I.e. rtt ends up in a different folder
than typelib.

And that's why you get the problem while I am fine, as in my case
typelib's include dir is the same than rtt's include dir, so I don't see
the missing include_directories/link_directories statements in
CMakeLists.txt (which is the actual bug).

I've pushed a fix to master on dfki-ric-orogen.

Running orogen's test suite

2010/11/10 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
>  On 11/10/2010 01:59 PM, Steven Bellens wrote:
>> I'm not that of a Cmake expert to know how to add it. The
>> CMakeLists.txt however does list
>> ADD_DEFINITIONS(-DWITH_TYPELIB).
>>
>> I would be surprised if I'm the only one having this problem...?
> rosbuild does not install stuff. I.e. rtt ends up in a different folder
> than typelib.
>
> And that's why you get the problem while I am fine, as in my case
> typelib's include dir is the same than rtt's include dir, so I don't see
> the missing include_directories/link_directories statements in
> CMakeLists.txt (which is the actual bug).
>
> I've pushed a fix to master on dfki-ric-orogen.

A similar issue appears for the utilmm includes:

[ 92%] Building CXX object
.orogen/typekit/transports/typelib/CMakeFiles/simple-transport-typelib-gnulinux.dir/TransportPlugin.cpp.o
In file included from
/home/u0063509/src/svn/cturtle/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple/.orogen/typekit/transports/typelib/TransportPlugin.cpp:8:0:
/home/u0063509/src/svn/cturtle/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/typelib/install/include/typelib/pluginmanager.hh:7:35:
fatal error: utilmm/singleton/use.hh: No such file or directory
compilation terminated.

which I could solve with the appended patch.

The test now fails at the (almost) very end because the linking path
to the typeLib library is still pointing to the rtt installation
folder.

Linking CXX shared library libsimple-transport-typelib-gnulinux.so
cd /home/u0063509/src/svn/cturtle/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple/build/.orogen/typekit/transports/typelib
&& /usr/bin/cmake -E cmake_link_script
CMakeFiles/simple-transport-typelib-gnulinux.dir/link.txt --verbose=1
/usr/bin/c++ -fPIC -g -shared
-Wl,-soname,libsimple-transport-typelib-gnulinux.so -o
libsimple-transport-typelib-gnulinux.so
CMakeFiles/simple-transport-typelib-gnulinux.dir/Test_BASIC_ENUM.cpp.o
CMakeFiles/simple-transport-typelib-gnulinux.dir/Test_BaseTypes.cpp.o
CMakeFiles/simple-transport-typelib-gnulinux.dir/Test_ComplexArray.cpp.o
CMakeFiles/simple-transport-typelib-gnulinux.dir/Test_ComplexVector.cpp.o
CMakeFiles/simple-transport-typelib-gnulinux.dir/Test_SimpleVector.cpp.o
CMakeFiles/simple-transport-typelib-gnulinux.dir/Test_Test64BitHandling.cpp.o
CMakeFiles/simple-transport-typelib-gnulinux.dir/Test_TestArrayOfDifferentSizes.cpp.o
CMakeFiles/simple-transport-typelib-gnulinux.dir/std_vector__Test_SimpleVector_.cpp.o
CMakeFiles/simple-transport-typelib-gnulinux.dir/std_vector__uint8_t_.cpp.o
CMakeFiles/simple-transport-typelib-gnulinux.dir/TypelibMarshallerBase.cpp.o
CMakeFiles/simple-transport-typelib-gnulinux.dir/TransportPlugin.cpp.o
-L/home/u0063509/src/svn/cturtle/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/rtt/install/lib
-ltypeLib -lutilmm
-Wl,-rpath,/home/u0063509/src/svn/cturtle/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/rtt/install/lib:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
/usr/bin/ld: cannot find -ltypeLib
/usr/bin/ld: cannot find -lutilmm
collect2: ld returned 1 exit status

Steven

>
> --
> Sylvain Joyeux
> Space&  Security Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax:   +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> 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
> -----------------------------------------------------------------------
>
>

Running orogen's test suite

> A similar issue appears for the utilmm includes:
>
> [ 92%] Building CXX object
> .orogen/typekit/transports/typelib/CMakeFiles/simple-transport-typelib-gnulinux.dir/TransportPlugin.cpp.o
> In file included from
> /home/u0063509/src/svn/cturtle/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple/.orogen/typekit/transports/typelib/TransportPlugin.cpp:8:0:
> /home/u0063509/src/svn/cturtle/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/typelib/install/include/typelib/pluginmanager.hh:7:35:
> fatal error: utilmm/singleton/use.hh: No such file or directory
> compilation terminated.
>
> which I could solve with the appended patch.
Fix in the wrong place. The problem is in typelib's pc file.

> The test now fails at the (almost) very end because the linking path
> to the typeLib library is still pointing to the rtt installation
> folder.
[snip]

Weird, I added the link directory of typeLib to the link path. Is the
library dir in typelib's pc OK ?

Running orogen's test suite

2010/11/10 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
>> A similar issue appears for the utilmm includes:
>>
>> [ 92%] Building CXX object
>> .orogen/typekit/transports/typelib/CMakeFiles/simple-transport-typelib-gnulinux.dir/TransportPlugin.cpp.o
>> In file included from
>> /home/u0063509/src/svn/cturtle/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple/.orogen/typekit/transports/typelib/TransportPlugin.cpp:8:0:
>> /home/u0063509/src/svn/cturtle/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/typelib/install/include/typelib/pluginmanager.hh:7:35:
>> fatal error: utilmm/singleton/use.hh: No such file or directory
>> compilation terminated.
>>
>> which I could solve with the appended patch.
> Fix in the wrong place. The problem is in typelib's pc file.
>
>> The test now fails at the (almost) very end because the linking path
>> to the typeLib library is still pointing to the rtt installation
>> folder.
> [snip]
>
> Weird, I added the link directory of typeLib to the link path. Is the
> library dir in typelib's pc OK ?

$ cat typelib.pc
prefix=/home/steven/src/svn/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/typelib/install
exec_prefix=/home/steven/src/svn/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/typelib/install
libdir=${prefix}/lib
includedir=${prefix}/include

Name: typelib
Description: Type model and manipulation library
Version: 1.1
Libs: -L${libdir} -ltypeLib
Cflags: -I${includedir}

[steven@steven-laptop~/src/svn/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/typelib/install/lib]$
ls
libtypeLib.so libtypeLib.so.1 libtypeLib.so.1.1 pkgconfig ruby typelib

Looks OK to me.

Steven

> --
> 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
>

Running orogen's test suite

OK, link_libraries needs to be called before the target is defined.
Before the call to target_link_libraries is not enough.

Anyway, pushed one fix to typelib for the utilmm includes (from
orocos-toolchain), and to orogen for the link directories
(dfki-ric-orogen:master)

You will have to delete the cmake cache as typelib values are stored there.

Sylvain

Running orogen's test suite

2010/11/10 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
> OK, link_libraries needs to be called before the target is defined.
> Before the call to target_link_libraries is not enough.
>
> Anyway, pushed one fix to typelib for the utilmm includes (from
> orocos-toolchain), and to orogen for the link directories
> (dfki-ric-orogen:master)
>
> You will have to delete the cmake cache as typelib values are stored there.

It's (probably) easier if you test all this yourself by making
separate install directories. Fixes work, it now complains about the
test files:

[ 96%] Building CXX object CMakeFiles/test.dir/test.cpp.o
/usr/bin/c++ -DWITH_TYPELIB -g
-I/home/steven/src/svn/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple/.orogen/typekit/types
-I/home/steven/src/svn/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple/.orogen/typekit
-I/home/steven/src/svn/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple
-I/home/steven/src/svn/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple/.orogen
-I/home/steven/src/svn/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/rtt/install/include
-I/home/steven/src/svn/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple/build/.orogen/typekit
-o CMakeFiles/test.dir/test.cpp.o -c
/home/steven/src/svn/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple/test.cpp
In file included from
/home/steven/src/svn/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple/test.cpp:18:
/home/steven/src/svn/stacks/kul-ros-pkg/stacks/orocos_toolchain_ros/orogen/build/orocos-toolchain-orogen/test/wc/modules/typekit_simple/.orogen/typekit/transports/typelib/TypelibMarshallerBase.hpp:9:
fatal error: typelib/value_ops.hh: No such file or directory
compilation terminated.
make[2]: *** [CMakeFiles/test.dir/test.cpp.o] Error 1

which clearly also need the typelib headers.

Steven

>
> Sylvain
>

Running orogen's test suite

On 11/10/2010 07:09 PM, Steven Bellens wrote:
> 2010/11/10 Sylvain Joyeux<sylvain [dot] joyeux [..] ...>:
>> OK, link_libraries needs to be called before the target is defined.
>> Before the call to target_link_libraries is not enough.
>>
>> Anyway, pushed one fix to typelib for the utilmm includes (from
>> orocos-toolchain), and to orogen for the link directories
>> (dfki-ric-orogen:master)
>>
>> You will have to delete the cmake cache as typelib values are stored there.
>
> It's (probably) easier if you test all this yourself by making
> separate install directories. Fixes work, it now complains about the
> test files:
Yes, you are definitely right. I started building that way but had no
time to finish. I'll update you when it is done.

Running orogen's test suite

2010/10/20 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
>  On 10/20/2010 09:27 AM, Steven Bellens wrote:
>> Checked out that master branch.
>> Still failing here - log file in appendix. Apparently it is not
>> finding rtt. Where do I set the correct paths in order to find it?
> For pkg-config to work, you need to add <prefix>/lib/pkgconfig to the
> PKG_CONFIG_PATH environment variable -- where <prefix> is where you
> installed RTT, typelib, utilmm, .... As I stated before, this is
> probably why typegen's cmake code did not find RTT in the first place
> when you were playing with ROS integration.

Making progress, but still some errors show up. Log in appendix.

>
> --
> Sylvain Joyeux
> Space&  Security Robotics
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 218-64136
> Fax:   +49 (0)421 218-64150
> E-Mail: robotik [..] ...
>
> 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
> -----------------------------------------------------------------------
>
>

Running orogen's test suite

On 10/20/2010 01:11 PM, Steven Bellens wrote:
> 2010/10/20 Sylvain Joyeux<sylvain [dot] joyeux [..] ...>:
>> On 10/20/2010 09:27 AM, Steven Bellens wrote:
>>> Checked out that master branch.
>>> Still failing here - log file in appendix. Apparently it is not
>>> finding rtt. Where do I set the correct paths in order to find it?
>> For pkg-config to work, you need to add<prefix>/lib/pkgconfig to the
>> PKG_CONFIG_PATH environment variable -- where<prefix> is where you
>> installed RTT, typelib, utilmm, .... As I stated before, this is
>> probably why typegen's cmake code did not find RTT in the first place
>> when you were playing with ROS integration.
> Making progress, but still some errors show up. Log in appendix.
Still broken in both master and toolchain-2.1

I will revert it to a working state on monday if I one of the two
branches still don't work on my machine until then.

I am willing to publish your patches on ROS integration if and only if
they don't break the rest. Sorry, but ROS is to me a lot less important
than it seems to be to you. So if you want it, do it.

Running orogen's test suite

On Friday 05 November 2010 10:51:17 Sylvain Joyeux wrote:
> On 10/20/2010 01:11 PM, Steven Bellens wrote:
> > 2010/10/20 Sylvain Joyeux<sylvain [dot] joyeux [..] ...>:
> >> On 10/20/2010 09:27 AM, Steven Bellens wrote:
> >>> Checked out that master branch.
> >>> Still failing here - log file in appendix. Apparently it is not
> >>> finding rtt. Where do I set the correct paths in order to find it?
> >>
> >> For pkg-config to work, you need to add<prefix>/lib/pkgconfig to the
> >> PKG_CONFIG_PATH environment variable -- where<prefix> is where you
> >> installed RTT, typelib, utilmm, .... As I stated before, this is
> >> probably why typegen's cmake code did not find RTT in the first place
> >> when you were playing with ROS integration.
> >>
> > Making progress, but still some errors show up. Log in appendix.
>
> Still broken in both master and toolchain-2.1
>
> I will revert it to a working state on monday if I one of the two
> branches still don't work on my machine until then.
>
> I am willing to publish your patches on ROS integration if and only if
> they don't break the rest. Sorry, but ROS is to me a lot less important
> than it seems to be to you. So if you want it, do it.

I wanted to do some post-test digging, but it seems the 'wc' directory is
cleaned up when the test finishes. How can we retain all generated files etc ?

To steven: where did you put your fixes up till now ?

Peter

Running orogen's test suite

2010/11/7 Peter Soetens <peter [..] ...>:
> On Friday 05 November 2010 10:51:17 Sylvain Joyeux wrote:
>>   On 10/20/2010 01:11 PM, Steven Bellens wrote:
>> > 2010/10/20 Sylvain Joyeux<sylvain [dot] joyeux [..] ...>:
>> >>   On 10/20/2010 09:27 AM, Steven Bellens wrote:
>> >>> Checked out that master branch.
>> >>> Still failing here - log file in appendix. Apparently it is not
>> >>> finding rtt. Where do I set the correct paths in order to find it?
>> >>
>> >> For pkg-config to work, you need to add<prefix>/lib/pkgconfig to the
>> >> PKG_CONFIG_PATH environment variable -- where<prefix>  is where you
>> >> installed RTT, typelib, utilmm, .... As I stated before, this is
>> >> probably why typegen's cmake code did not find RTT in the first place
>> >> when you were playing with ROS integration.
>> >>
>> >   Making progress, but still some errors show up. Log in appendix.
>>
>> Still broken in both master and toolchain-2.1
>>
>> I will revert it to a working state on monday if I one of the two
>> branches still don't work on my machine until then.
>>
>> I am willing to publish your patches on ROS integration if and only if
>> they don't break the rest. Sorry, but ROS is to me a lot less important
>> than it seems to be to you. So if you want it, do it.
>
> I wanted to do some post-test digging, but it seems the 'wc' directory is
> cleaned up when the test finishes. How can we retain all generated files etc ?
>
> To steven: where did you put your fixes up till now ?

I don't have any fixes yet, as I'm experiencing a similar problem you
have: the original system tests don't pass.

Steven

>
> Peter
>

Running orogen's test suite

On Sunday 07 November 2010 22:27:12 Peter Soetens wrote:
> On Friday 05 November 2010 10:51:17 Sylvain Joyeux wrote:
> > On 10/20/2010 01:11 PM, Steven Bellens wrote:
> > > 2010/10/20 Sylvain Joyeux<sylvain [dot] joyeux [..] ...>:
> > >> On 10/20/2010 09:27 AM, Steven Bellens wrote:
> > >>> Checked out that master branch.
> > >>> Still failing here - log file in appendix. Apparently it is not
> > >>> finding rtt. Where do I set the correct paths in order to find it?
> > >>
> > >> For pkg-config to work, you need to add<prefix>/lib/pkgconfig to the
> > >> PKG_CONFIG_PATH environment variable -- where<prefix> is where you
> > >> installed RTT, typelib, utilmm, .... As I stated before, this is
> > >> probably why typegen's cmake code did not find RTT in the first place
> > >> when you were playing with ROS integration.
> > >>
> > > Making progress, but still some errors show up. Log in appendix.
> >
> > Still broken in both master and toolchain-2.1
> >
> > I will revert it to a working state on monday if I one of the two
> > branches still don't work on my machine until then.
> >
> > I am willing to publish your patches on ROS integration if and only if
> > they don't break the rest. Sorry, but ROS is to me a lot less important
> > than it seems to be to you. So if you want it, do it.
>
> I wanted to do some post-test digging, but it seems the 'wc' directory is
> cleaned up when the test finishes. How can we retain all generated files
> etc ?
>

So i found the TEST_KEEP_WC=1 and TEST_DONT_CLEAN=1 environment flags burried
in the test.rb code.

Now when I run the testrb, I get as output for example:

6) Failure:
test_simple(TC_GenerationTypekit)
[/home/kaltan/src/git/orocos-toolchain/orogen/lib/orogen/test.rb:193:in
`build_test_component'
/home/kaltan/src/git/orocos-toolchain/orogen/lib/orogen/test.rb:102:in
`chdir'
/home/kaltan/src/git/orocos-toolchain/orogen/lib/orogen/test.rb:102:in
`in_prefix'
/home/kaltan/src/git/orocos-toolchain/orogen/lib/orogen/test.rb:81:in
`chdir'
/home/kaltan/src/git/orocos-toolchain/orogen/lib/orogen/test.rb:81:in
`in_wc'
/home/kaltan/src/git/orocos-toolchain/orogen/lib/orogen/test.rb:94:in
`in_prefix'
/home/kaltan/src/git/orocos-toolchain/orogen/lib/orogen/test.rb:192:in
`build_test_component'
./test/test_typekit.rb:114:in `test_simple']:
<false> is not true.

But when I run it in orogen/test/wc/modules/typekit_simple/build manually, I
get :

$ export
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:../../../prefix/modules/typekit_simple/lib/pkgconfig
$ ./test

...
0.069 [ Info ][TypekitRepository::Import] Transport Typelib did not install
a fallback handler for 'unknown_t'.
Test handling of BaseTypes
- testing composition/decomposition is disabled
- testing Typelib marshalling/unmarshalling ...

- testing composition/decomposition is disabled

- testing composition/decomposition is disabled
- testing Typelib marshalling/unmarshalling ...

Testing simple structure with vector<>
- testing composition/decomposition is disabled
- testing Typelib marshalling/unmarshalling ...

Testing complex structure-in-vector<>
- testing composition/decomposition is disabled
- testing Typelib marshalling/unmarshalling ...

Testing complex structure-in-array
- testing composition/decomposition is disabled
- testing Typelib marshalling/unmarshalling ...
0.069 [ Debug ][Logger] Stopping StartStopManager.
0.069 [ Debug ][Logger] Stopping MainThread.
0.069 [ Info ][Logger] Orocos Logging Deactivated.
$ echo $?
0

So it looks like it does run correctly, but the test scripts couldn't run it ?

On the overall picture: The only major change we did was using the find_package
macro of Orocos instead of the pkg-config style. I don't see how this could
break cases like the ones being reported. Once the generated code compiles,
all should work again as before.

Also: linking with rtt-types is no longer necessary in 2.1-next since the
plugin loader will find that library itself.

In attachment my error log and the patch against toolchain-2.1 to get this
far.

How can I run a single test instead of everything ?

Peter

Running orogen's test suite

On 11/07/2010 11:47 PM, Peter Soetens wrote:
> How can I run a single test instead of everything ?
Forgot to answer that one.

testrb provides the -n option

testrb test_typekit.rb -n name_of_test

where "name_of_test" is the name of the relevant test method.
--

Sylvain Joyeux
Space& Security Robotics

!!! Achtung, neue Telefonnummer!!!

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-454136
Fax: +49 (0)421 218-454150
E-Mail: robotik [..] ...

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
-----------------------------------------------------------------------

Running orogen's test suite

On 11/07/2010 11:47 PM, Peter Soetens wrote:
> So i found the TEST_KEEP_WC=1 and TEST_DONT_CLEAN=1 environment flags burried
> in the test.rb code.
>
> Now when I run the testrb, I get as output for example:
>
> 6) Failure:
> test_simple(TC_GenerationTypekit)
> [/home/kaltan/src/git/orocos-toolchain/orogen/lib/orogen/test.rb:193:in
> `build_test_component'
> /home/kaltan/src/git/orocos-toolchain/orogen/lib/orogen/test.rb:102:in
> `chdir'
> /home/kaltan/src/git/orocos-toolchain/orogen/lib/orogen/test.rb:102:in
> `in_prefix'
> /home/kaltan/src/git/orocos-toolchain/orogen/lib/orogen/test.rb:81:in
> `chdir'
> /home/kaltan/src/git/orocos-toolchain/orogen/lib/orogen/test.rb:81:in
> `in_wc'
> /home/kaltan/src/git/orocos-toolchain/orogen/lib/orogen/test.rb:94:in
> `in_prefix'
> /home/kaltan/src/git/orocos-toolchain/orogen/lib/orogen/test.rb:192:in
> `build_test_component'
> ./test/test_typekit.rb:114:in `test_simple']:
> <false> is not true.
>
> But when I run it in orogen/test/wc/modules/typekit_simple/build manually, I
> get :
>
> $ export
> PKG_CONFIG_PATH=$PKG_CONFIG_PATH:../../../prefix/modules/typekit_simple/lib/pkgconfig
> $ ./test
>
> ...
> 0.069 [ Info ][TypekitRepository::Import] Transport Typelib did not install
> a fallback handler for 'unknown_t'.
> Test handling of BaseTypes
> - testing composition/decomposition is disabled
> - testing Typelib marshalling/unmarshalling ...
>
> - testing composition/decomposition is disabled
>
> - testing composition/decomposition is disabled
> - testing Typelib marshalling/unmarshalling ...
>
> Testing simple structure with vector<>
> - testing composition/decomposition is disabled
> - testing Typelib marshalling/unmarshalling ...
>
> Testing complex structure-in-vector<>
> - testing composition/decomposition is disabled
> - testing Typelib marshalling/unmarshalling ...
>
> Testing complex structure-in-array
> - testing composition/decomposition is disabled
> - testing Typelib marshalling/unmarshalling ...
> 0.069 [ Debug ][Logger] Stopping StartStopManager.
> 0.069 [ Debug ][Logger] Stopping MainThread.
> 0.069 [ Info ][Logger] Orocos Logging Deactivated.
> $ echo $?
> 0
>
> So it looks like it does run correctly, but the test scripts couldn't run it ?
>
> On the overall picture: The only major change we did was using the find_package
> macro of Orocos instead of the pkg-config style. I don't see how this could
> break cases like the ones being reported. Once the generated code compiles,
> all should work again as before.
I did not say that you broke only the build system (even if that was the
major breakage). There are some other commits you made that added stuff
to the generated typekit and caused the opaque-related errors that you
have in your logs. Since it breaks smart-pointer support, it needs to be
fixed as well.

Now, for the test programs not passing, I don't know. I would need the
normal output as well as the test outputs (i.e. stdout output before the
test results).

> Also: linking with rtt-types is no longer necessary in 2.1-next since the
> plugin loader will find that library itself.
It does not hurt to link with it. I don't rely on the plugin loader
loading stuff automatically, as I would rather have it NOT load
everything it finds (in other words: is there a way to tell the plugin
loader to not load all plugins installed somewhere ?)

Running orogen's test suite

On Monday 08 November 2010 07:54:21 Sylvain Joyeux wrote:
> On 11/07/2010 11:47 PM, Peter Soetens wrote:
> > So i found the TEST_KEEP_WC=1 and TEST_DONT_CLEAN=1 environment flags
> > burried in the test.rb code.
> >
> > Now when I run the testrb, I get as output for example:
> > 6) Failure:
> > test_simple(TC_GenerationTypekit)
> >
> > [/home/kaltan/src/git/orocos-toolchain/orogen/lib/orogen/test.rb:193
> > :in
> >
> > `build_test_component'
> >
> > /home/kaltan/src/git/orocos-toolchain/orogen/lib/orogen/test.rb:102
> > :in
> >
> > `chdir'
> >
> > /home/kaltan/src/git/orocos-toolchain/orogen/lib/orogen/test.rb:102
> > :in
> >
> > `in_prefix'
> >
> > /home/kaltan/src/git/orocos-toolchain/orogen/lib/orogen/test.rb:81:
> > in
> >
> > `chdir'
> >
> > /home/kaltan/src/git/orocos-toolchain/orogen/lib/orogen/test.rb:81:
> > in
> >
> > `in_wc'
> >
> > /home/kaltan/src/git/orocos-toolchain/orogen/lib/orogen/test.rb:94:
> > in
> >
> > `in_prefix'
> >
> > /home/kaltan/src/git/orocos-toolchain/orogen/lib/orogen/test.rb:192
> > :in
> >
> > `build_test_component'
> >
> > ./test/test_typekit.rb:114:in `test_simple']:
> > <false> is not true.
> >
> > But when I run it in orogen/test/wc/modules/typekit_simple/build
> > manually, I get :
> >
> > $ export
> > PKG_CONFIG_PATH=$PKG_CONFIG_PATH:../../../prefix/modules/typekit_simple/l
> > ib/pkgconfig $ ./test
> >
> > ...
> > 0.069 [ Info ][TypekitRepository::Import] Transport Typelib did not
> > install a fallback handler for 'unknown_t'.
> > Test handling of BaseTypes
> > - testing composition/decomposition is disabled
> > - testing Typelib marshalling/unmarshalling ...
> >
> > - testing composition/decomposition is disabled
> >
> > - testing composition/decomposition is disabled
> > - testing Typelib marshalling/unmarshalling ...
> >
> > Testing simple structure with vector<>
> > - testing composition/decomposition is disabled
> > - testing Typelib marshalling/unmarshalling ...
> >
> > Testing complex structure-in-vector<>
> > - testing composition/decomposition is disabled
> > - testing Typelib marshalling/unmarshalling ...
> >
> > Testing complex structure-in-array
> > - testing composition/decomposition is disabled
> > - testing Typelib marshalling/unmarshalling ...
> > 0.069 [ Debug ][Logger] Stopping StartStopManager.
> > 0.069 [ Debug ][Logger] Stopping MainThread.
> > 0.069 [ Info ][Logger] Orocos Logging Deactivated.
> > $ echo $?
> > 0
> >
> > So it looks like it does run correctly, but the test scripts couldn't run
> > it ?
> >
> > On the overall picture: The only major change we did was using the
> > find_package macro of Orocos instead of the pkg-config style. I don't
> > see how this could break cases like the ones being reported. Once the
> > generated code compiles, all should work again as before.
>
> I did not say that you broke only the build system (even if that was the
> major breakage). There are some other commits you made that added stuff
> to the generated typekit and caused the opaque-related errors that you
> have in your logs. Since it breaks smart-pointer support, it needs to be
> fixed as well.

If the build system errors are fixed with the latest patch, we could tear it in
two branches (or rebase on all build changes) and git-bisect to it. I wasn't
aware of any harmful/fragile patches, ie, I thought I only added stuff.

>
> Now, for the test programs not passing, I don't know. I would need the
> normal output as well as the test outputs (i.e. stdout output before the
> test results).
>
> > Also: linking with rtt-types is no longer necessary in 2.1-next since the
> > plugin loader will find that library itself.
>
> It does not hurt to link with it. I don't rely on the plugin loader
> loading stuff automatically, as I would rather have it NOT load
> everything it finds (in other words: is there a way to tell the plugin
> loader to not load all plugins installed somewhere ?)

The rough way is to set RTT_COMPONENT_PATH to the empty string. This will
override the default, compiled in path, which equals the CMAKE_PREFIX_PATH, or
which you can override using the DEFAULT_PLUGIN_PATH variable in cmake.

You could also disable the plugin loader, but that will disable also
marshalling etc. Another option is not to build the rtt-typekit and provide
one yourself. Or maybe you have another idea.

Peter

Running orogen's test suite

On 11/08/2010 09:40 AM, Peter Soetens wrote:
>> I did not say that you broke only the build system (even if that was the
>> major breakage). There are some other commits you made that added stuff
>> to the generated typekit and caused the opaque-related errors that you
>> have in your logs. Since it breaks smart-pointer support, it needs to be
>> fixed as well.
> If the build system errors are fixed with the latest patch, we could tear it in
> two branches (or rebase on all build changes) and git-bisect to it. I wasn't
> aware of any harmful/fragile patches, ie, I thought I only added stuff.
Yes, that would be a way.

But be my guest here. I'm tired of having people run on code I don't
run, so I'm pushing very hard the RTT2 migration here. Which means I
really don't have time fixing bugs that other people introduce. I will
continue answering questions, but I am not going to investigate as to
the issues themselves.

I would advise to wait a bit on your investigations, though, as I am
going to refactor the opaque-handling code to make it a lot simpler
(hence, easier to debug for you).

> The rough way is to set RTT_COMPONENT_PATH to the empty string. This will
> override the default, compiled in path, which equals the CMAKE_PREFIX_PATH, or
> which you can override using the DEFAULT_PLUGIN_PATH variable in cmake.
>
> You could also disable the plugin loader, but that will disable also
> marshalling etc. Another option is not to build the rtt-typekit and provide
> one yourself. Or maybe you have another idea.
That was one of the paths in the future. There is this
RTT-typekit/all-other-typekits dichotomy in orogen right now, and I'd
rather have all orogen projects depend on orogen typekits. But I am not
sure I can even do it, so I'll see in the future.

The "load everything" problem is that I don't see the point of loading
100+ type definitions in every components while the tooling *knows* what
are the typekits these components need.

Running orogen's test suite

On Monday 08 November 2010 10:35:26 Sylvain Joyeux wrote:
> On 11/08/2010 09:40 AM, Peter Soetens wrote:
> >> I did not say that you broke only the build system (even if that was the
> >> major breakage). There are some other commits you made that added stuff
> >> to the generated typekit and caused the opaque-related errors that you
> >> have in your logs. Since it breaks smart-pointer support, it needs to be
> >> fixed as well.
> >
> > If the build system errors are fixed with the latest patch, we could tear
> > it in two branches (or rebase on all build changes) and git-bisect to
> > it. I wasn't aware of any harmful/fragile patches, ie, I thought I only
> > added stuff.
>
> Yes, that would be a way.
>
> But be my guest here. I'm tired of having people run on code I don't
> run, so I'm pushing very hard the RTT2 migration here. Which means I
> really don't have time fixing bugs that other people introduce. I will
> continue answering questions, but I am not going to investigate as to
> the issues themselves.

I'm completely on your side: if a patch breaks stuff, we have to revert it,
until a proper one is proposed. But since my use case leans closer to
Steven's, I'm eager to help him out fixing all remaining issues. It's clear now
that these issues were not so minor, and all should have happened on a
separate branch. If we knew about the unit tests, this would have been
avoided, in the first place.

>
> I would advise to wait a bit on your investigations, though, as I am
> going to refactor the opaque-handling code to make it a lot simpler
> (hence, easier to debug for you).

So I propose we try to branch out all possible show-stoppers to a
toolchain-2.1-ros branch. I can do a bisect to find that intersection point and
revert all patches upto that point. You would then confirm that toolchain-2.1
is stable again, we merge all remaining work, and Steven and I continue to
rebase the -ros branch on that work until we get the unit tests working again,
and you see no problem either. Then we merge all that for 2.2.

>
> > The rough way is to set RTT_COMPONENT_PATH to the empty string. This will
> > override the default, compiled in path, which equals the
> > CMAKE_PREFIX_PATH, or which you can override using the
> > DEFAULT_PLUGIN_PATH variable in cmake.
> >
> > You could also disable the plugin loader, but that will disable also
> > marshalling etc. Another option is not to build the rtt-typekit and
> > provide one yourself. Or maybe you have another idea.
>
> That was one of the paths in the future. There is this
> RTT-typekit/all-other-typekits dichotomy in orogen right now, and I'd
> rather have all orogen projects depend on orogen typekits. But I am not
> sure I can even do it, so I'll see in the future.
>
> The "load everything" problem is that I don't see the point of loading
> 100+ type definitions in every components while the tooling *knows* what
> are the typekits these components need.

I agree fully here. That's why we are: 1. putting typekits in ros packages for
the ros users, and allow them to 'import' specific packages + their deps at
runtime OR 2. install the typekits in project specific subdirs of the
lib/orocos tree, which will never be searched by default by the plugin loader.
Only the lib/orocos/types dir is loaded by default (and any other dir in the
RTT_COMPONENT_PATH).

Peter

Running orogen's test suite

2010/11/5 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
>  On 10/20/2010 01:11 PM, Steven Bellens wrote:
>> 2010/10/20 Sylvain Joyeux<sylvain [dot] joyeux [..] ...>:
>>>   On 10/20/2010 09:27 AM, Steven Bellens wrote:
>>>> Checked out that master branch.
>>>> Still failing here - log file in appendix. Apparently it is not
>>>> finding rtt. Where do I set the correct paths in order to find it?
>>> For pkg-config to work, you need to add<prefix>/lib/pkgconfig to the
>>> PKG_CONFIG_PATH environment variable -- where<prefix>  is where you
>>> installed RTT, typelib, utilmm, .... As I stated before, this is
>>> probably why typegen's cmake code did not find RTT in the first place
>>> when you were playing with ROS integration.
>>   Making progress, but still some errors show up. Log in appendix.
> Still broken in both master and toolchain-2.1
>
> I will revert it to a working state on monday if I one of the two
> branches still don't work on my machine until then.
>
> I am willing to publish your patches on ROS integration if and only if
> they don't break the rest. Sorry, but ROS is to me a lot less important
> than it seems to be to you. So if you want it, do it.

I'm willing to fix it, but I can't fix a system which didn't work here
at the first place.

Steven

>
> --
> Sylvain Joyeux
> Space&  Security Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax:   +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> 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
> -----------------------------------------------------------------------
>
>

Running orogen's test suite

On 11/05/2010 11:26 AM, Steven Bellens wrote:
> 2010/11/5 Sylvain Joyeux<sylvain [dot] joyeux [..] ...>:
>> On 10/20/2010 01:11 PM, Steven Bellens wrote:
>>> 2010/10/20 Sylvain Joyeux<sylvain [dot] joyeux [..] ...>:
>>>> On 10/20/2010 09:27 AM, Steven Bellens wrote:
>>>>> Checked out that master branch.
>>>>> Still failing here - log file in appendix. Apparently it is not
>>>>> finding rtt. Where do I set the correct paths in order to find it?
>>>> For pkg-config to work, you need to add<prefix>/lib/pkgconfig to the
>>>> PKG_CONFIG_PATH environment variable -- where<prefix> is where you
>>>> installed RTT, typelib, utilmm, .... As I stated before, this is
>>>> probably why typegen's cmake code did not find RTT in the first place
>>>> when you were playing with ROS integration.
>>> Making progress, but still some errors show up. Log in appendix.
>> Still broken in both master and toolchain-2.1
>>
>> I will revert it to a working state on monday if I one of the two
>> branches still don't work on my machine until then.
>>
>> I am willing to publish your patches on ROS integration if and only if
>> they don't break the rest. Sorry, but ROS is to me a lot less important
>> than it seems to be to you. So if you want it, do it.
> I'm willing to fix it, but I can't fix a system which didn't work here
> at the first place.
What did not work, under what, which commit and with which build system ?

What I see in the problem you reported is that you are building it under
ROS. Did you try it under autoproj instead ?

Which commit are you on ? Try out 'master' from

git://gitorious.org/+orocos-dfki-maintainers/dfki-ric-orogen.git

which is the furthest I could go on September's changes (includes one
commit reverted). Have a look at the history.

Moreover, pkg-config is broken UNDER ROSBUILD. It works perfectly well
if PKG_CONFIG_PATH is set (and updated) properly. So, I would suggest
that you do NOT change that.

Sylvain

Running orogen's test suite

2010/11/5 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
>  On 11/05/2010 11:26 AM, Steven Bellens wrote:
>> 2010/11/5 Sylvain Joyeux<sylvain [dot] joyeux [..] ...>:
>>>   On 10/20/2010 01:11 PM, Steven Bellens wrote:
>>>> 2010/10/20 Sylvain Joyeux<sylvain [dot] joyeux [..] ...>:
>>>>>    On 10/20/2010 09:27 AM, Steven Bellens wrote:
>>>>>> Checked out that master branch.
>>>>>> Still failing here - log file in appendix. Apparently it is not
>>>>>> finding rtt. Where do I set the correct paths in order to find it?
>>>>> For pkg-config to work, you need to add<prefix>/lib/pkgconfig to the
>>>>> PKG_CONFIG_PATH environment variable -- where<prefix>    is where you
>>>>> installed RTT, typelib, utilmm, .... As I stated before, this is
>>>>> probably why typegen's cmake code did not find RTT in the first place
>>>>> when you were playing with ROS integration.
>>>>    Making progress, but still some errors show up. Log in appendix.
>>> Still broken in both master and toolchain-2.1
>>>
>>> I will revert it to a working state on monday if I one of the two
>>> branches still don't work on my machine until then.
>>>
>>> I am willing to publish your patches on ROS integration if and only if
>>> they don't break the rest. Sorry, but ROS is to me a lot less important
>>> than it seems to be to you. So if you want it, do it.
>> I'm willing to fix it, but I can't fix a system which didn't work here
>> at the first place.
> What did not work, under what, which commit and with which build system ?
>
> What I see in the problem you reported is that you are building it under
> ROS. Did you try it under autoproj instead ?
>
> Which commit are you on ? Try out 'master' from
>
>   git://gitorious.org/+orocos-dfki-maintainers/dfki-ric-orogen.git
>
> which is the furthest I could go on September's changes (includes one
> commit reverted). Have a look at the history.
>
> Moreover, pkg-config is broken UNDER ROSBUILD. It works perfectly well
> if PKG_CONFIG_PATH is set (and updated) properly. So, I would suggest
> that you do NOT change that.

I've checked out that git repository and I've set the PKG_CONFIG_PATH,
no problems there.
See also my reply in this thread dated October 20th and the
corresponding log file

Steven

>
> Sylvain
>
>

Running orogen's test suite

On 11/06/2010 11:23 AM, Steven Bellens wrote:
> 2010/11/5 Sylvain Joyeux<sylvain [dot] joyeux [..] ...>:
>> On 11/05/2010 11:26 AM, Steven Bellens wrote:
>>> 2010/11/5 Sylvain Joyeux<sylvain [dot] joyeux [..] ...>:
>>>> On 10/20/2010 01:11 PM, Steven Bellens wrote:
>>>>> 2010/10/20 Sylvain Joyeux<sylvain [dot] joyeux [..] ...>:
>>>>>> On 10/20/2010 09:27 AM, Steven Bellens wrote:
>>>>>>> Checked out that master branch.
>>>>>>> Still failing here - log file in appendix. Apparently it is not
>>>>>>> finding rtt. Where do I set the correct paths in order to find it?
>>>>>> For pkg-config to work, you need to add<prefix>/lib/pkgconfig to the
>>>>>> PKG_CONFIG_PATH environment variable -- where<prefix> is where you
>>>>>> installed RTT, typelib, utilmm, .... As I stated before, this is
>>>>>> probably why typegen's cmake code did not find RTT in the first place
>>>>>> when you were playing with ROS integration.
>>>>> Making progress, but still some errors show up. Log in appendix.
>>>> Still broken in both master and toolchain-2.1
>>>>
>>>> I will revert it to a working state on monday if I one of the two
>>>> branches still don't work on my machine until then.
>>>>
>>>> I am willing to publish your patches on ROS integration if and only if
>>>> they don't break the rest. Sorry, but ROS is to me a lot less important
>>>> than it seems to be to you. So if you want it, do it.
>>> I'm willing to fix it, but I can't fix a system which didn't work here
>>> at the first place.
>> What did not work, under what, which commit and with which build system ?
>>
>> What I see in the problem you reported is that you are building it under
>> ROS. Did you try it under autoproj instead ?
>>
>> Which commit are you on ? Try out 'master' from
>>
>> git://gitorious.org/+orocos-dfki-maintainers/dfki-ric-orogen.git
>>
>> which is the furthest I could go on September's changes (includes one
>> commit reverted). Have a look at the history.
>>
>> Moreover, pkg-config is broken UNDER ROSBUILD. It works perfectly well
>> if PKG_CONFIG_PATH is set (and updated) properly. So, I would suggest
>> that you do NOT change that.
>
> I've checked out that git repository and I've set the PKG_CONFIG_PATH,
> no problems there.
> See also my reply in this thread dated October 20th and the
> corresponding log file
Obviously, the generated orogen projects have problem getting typelib
headers. Check the typelib.pc file. Is the Cflags: line right (i.e.,
does it point to the right place ?). If not, what is the right folder
and what does the .pc file list ?

Sylvain

Running orogen's test suite

[...]

>> I've checked out that git repository and I've set the PKG_CONFIG_PATH,
>> no problems there.
>> See also my reply in this thread dated October 20th and the
>> corresponding log file
> Obviously, the generated orogen projects have problem getting typelib
> headers. Check the typelib.pc file. Is the Cflags: line right (i.e.,
> does it point to the right place ?). If not, what is the right folder
> and what does the .pc file list ?

The typelib.pc file is correct. The directory listed there is indeed
the place where the headers are installed. Can I get more debug
information somehow?

regards,

Steven

>
> Sylvain
>