Porting RQt plugins to Windows

RQt Porting examples

Here is the ROS 2 port of qt_gui_core.

Here is the ROS 2 port of python_qt_binding.

Considerations for Windows 10

Code that uses __cplusplus and code that requires pluginlib

In some places, notably in the ROS 2 port of pluginlib, there is use of the __cplusplus flag. Unfortunately on Windows Visual Studio does not set this flag correctly regardless of the C++ standard that is actually being used. See this page for more information.

To set it, you need to add the compile option /Zc:__cplusplus.

For example, in CMake you could do something like this:

target_compile_options(${PROJECT_NAME} PUBLIC "/Zc:__cplusplus")

Locations of build artifacts (before install)

This only came up during when building qt_gui_cpp. In that package, a custom command depends on a target library in another part of the package. However, that library isn’t installed until build is complete. Windows builds in a ${configuration} directory. For example:

On Linux, qt_gui_cpp.a would be built in: <ros2_ws>/build/qt_gui_cpp/src/qt_gui_cpp/

But on Windows qt_gui_cpp.lib is built in <ros2_ws>/build/qt_gui_cpp/src/qt_gui_cpp/Release

For compatibility across platforms in this situation, use CMake generator expressions. However, when you need a library to link against be sure to use $<TARGET_LINKER_FILE:_target> instead of $<TARGET_FILE:_target>. The latter will find .dll files, which cannot be linked against on Windows. See an example here.

Compiler and linker flags

In general when porting to Windows, many packages might make use of additional compiler flags. You can find the Windows compiler flags on Microsoft’s documentation. The C++ compiler is called cl.exe.

For linker flags see Microsoft’s documentation. The linker program is called link.exe.

However, CMake actually provides many of these options in variables. This StackOverflow page contains a good example of how to see all the CMake variables available in a script.