@jacquelinekay @wjwwood I had to make this change so rclpy would compile fine. Is this correct?

CI:

http://ci.ros2.org/job/ci_linux/896/
http://ci.ros2.org/job/ci_osx/751/
http://ci.ros2.org/job/ci_windows/977/

I don't think including the message_type_support_struct.h header directly is necessary, but I'm really not sure. Waiting for William to weigh in here.

rcl and rclpy only need the typesupport structure, which is vendor independent, right? Neither rcl or rclpy need the ROSIDL_GET_MSG_TYPE_SUPPORT macros.

I'm pretty sure this is not the right thing to do, but instead I think what ever code is including these headers needs to also have include directories from exactly one type support system. That header (#include "rosidl_generator_c/message_type_support.h") is provided by each type support system and these rcl header files all include it so that anyone who tries to use these headers gets tied to a particular type support system when they do.

It's possible that your use case needs us to do something different, but what I mean to say is that these headers are intentionally the way they are.

@wjwwood no problem, I made this change so I could continue working on rclpy, but if the solution is somewhere else, that's fine too. I'm still getting up to speed with the new type support refactor 😄

I'm going to withdraw this PR and create an rclpy extension for each implementation. Thanks @jacquelinekay and @wjwwood for helping me understand the type support system.