Automated test(s) about freertps HOT 5 CLOSED

Since the package already uses CMake why not use the standard approach:

• clone repo
• invoke cmake
• invoke make test

ament_tools will handle it well even if it is just a plain CMake project.

from freertps.

this repo has another level of indirection due to the desire to build multiple times with different cross-compilers, and (at least, according to my current understanding) CMake only allows one declaration of the C compiler per project. At least, I couldn't figure out how to ask CMake to build with different C compilers. So what currently happens is:

• clone repo
• invoke make
• this spins through the SYSTEMS environment variable, which can have more than one target system (e.g., native-posix, stm32-whatever, etc.). For each of those, it invokes CMake separately

However, the default "make" just builds it natively, assuming it's running on a POSIX host. That is the idea for just a plain "make test" as well, to do a minimal "yes, we can send hello-world from talker to listener" simple standalone test, without any other infrastructure being required. 😀 🐔

On Fri, Jan 8, 2016 at 4:01 PM, Dirk Thomas [email protected]
wrote:

Since the package already uses CMake why not use the standard approach:

• clone repo
• invoke cmake
• invoke make test

ament_tools will handle it well even if it is just a plain CMake project.

—
Reply to this email directly or view it on GitHub
#26 (comment).

from freertps.

how about these steps

• clone repo
• invoke make (which invokes cmake under the hood, with existing machinery)
• invoke make test
• test will run; confirmation of messages getting passed will fly across the terminal

and this too

• clone repo into ROS workspace
• build with ament
• same tests will get run with ament test, maybe with the addition of launch to automatically check console output

Also:

I like the idea of reusing the existing apps by creating a test executable that forks those processes, since code reuse is always great, but this would probably only work on POSIX; is that OK?

from freertps.

👍 that sounds like a good plan. I just fixed it now so that freertps can talk with itself finally, no matter which side is started first 😥 I'm not sure where the existing apps other than the simplest talker/listener string blasters should be moved, since they (should) be using the auto-generated ROS2 message structure and serializers. Perhaps another repo called freertps_ros2_mcu_demos or something? The idea is that such a repo would be using freertps and the freertps ros2 message CDR stuff currently in mega_genmsg.py to create ROS2-compatible messages without incurring the overhead of all of rclc and friends. Although of course eventually the goal is for rclc to be so small that it can be used directly on MCU's, it's always going to be larger than the super-simple, bare-bones "send an IMU message every 100ms" type of thing.

from freertps.

A related task is configuring Jenkins to do what we want once there are automated tests in place 💪 I just added the option to test a branch for the freertps project on ci.ros2.org, which is useful for my workflow since I like branches... I tested it by making a bogus branch test_jenkins which puts trash in the CMakeLists.txt. Predictably, the CI job for that branch failed. So I think the feature works...

http://ci.ros2.org/job/freertps/18/

from freertps.