Fixes for Windows

[Ace314159]

I changed a couple things to get this working on Windows.

1. For the same reason as disable griper on OSX #192, the gripper controller doesn't work on Windows as well, so I disabled it.
2. M_PI is not defined unless _USE_MATH_DEFINES is also defined
3. I had to export some protected functions of the joint trajectory controller to fix missing symbol errors.
4. Lastly, cxxabi.h doesn't exist on MSVC, so I didn't include it when MSVC was detected. It still still seems to compile fine without it.

[bmagyar]

Could we have _USE_MATH_DEFINES added in the cmake as a flag by any chance? It would move the file-based hack to a more hidden place and may avoid having to add it to more files in the future where we have a need for M_PI.

[bmagyar]

Also please fix uncrustify and cpplint

[Ace314159]

I could add the define using add_definitions and that would fix this issue as well as future issues for only the diff_drive_controller. This would be fine in this case because it is used in a cpp file. However, if M_PI were to be used in a header file, then having it in the CMake would require anyone using the header file to also have that define, which I think is not ideal.

[Karsten1987]

thanks @Ace314159 for picking this up. Let's see what the official ROS2 buildfarm is saying:

• Linux
• Linux-aarch64
• macOS
• Windows

That CI run obviously also incorporates your changes from ros-controls/ros2_control#443

[Ace314159]

They all seem to fail at a similar point involving logging. I don't think I modified that code, and I don't get that error. Do you have any idea what might be causing that?

[Karsten1987]

I think I misconfigured the job, let's try again:

• Linux
• Linux-aarch64
• macOS
• Windows

[Ace314159]

Looks like the only failing test is a linter one in ros2_control. I just put a fix for that.

Is the expected way to fix these linter errors to run ament_uncrustify. Is there a way to tell it to do it for all the packages in a workspace without having to manually specify all the packages.

[Karsten1987]

This would be fine in this case because it is used in a cpp file. However, if M_PI were to be used in a header file, then having it in the CMake would require anyone using the header file to also have that define, which I think is not ideal.

I agree with this logic. I think the current solution pretty neat.

[destogl]

It looks good now.

@Karsten1987 would it be possible to get Windows CI integrated?