Add support for Windows & OSX

[Tobias-Fischer]

Dear mavros team,

As part of the RoboStack project, we are aiming to provide cross-platform ROS packages that can be installed via conda (see https://github.com/RoboStack/ros-noetic). We were able to successfully compile mavros on Linux, macOS & Windows.

For Windows (which I know is currently not supported by mavros), we needed quite a few patches to get mavros to compile. macOS was much easier. You can see the patches here:

• libmavconn
• mavlink - this includes some conda specific patches around PYHONEXECUTABLE, please ignore these
• mavros-1 - this includes a patch that is required for both Windows and macOS
• mavros-2 - this includes a bunch of patches for Windows specifically, and in the current state would break the other platforms (we only apply this patch on Windows).

Are you interested at all in merging these patches upstream? Most of the patches could be easily guarded by if(WIN) type statements (and most of them are already). For example, I did not find a simple equivalent for set_this_thread_name and would simply disable that on Windows. Other changes are a little more annoying - I needed to move some variables from being private/protected to public, as the Visual Studio compiler complained about trying to access these which is not allowed (I am not sure about the C++ internals, and why it works on Linux but not Windows).

[Tobias-Fischer]

It would also be great to get your input to RoboStack/ros-noetic#59 if you have any.

[Tobias-Fischer]

/cc @wolfv @traversaro

[Tobias-Fischer]

I should add that this is totally untested - all I did is getting it to compile.

[vooon]

Done some review of libmavconn patch:

• please use boost::thread only for windows, you could add something like that

  #ifdef _WIN32
  using thread = boost::thread;
  #else
  using thread = std::thread;
  #endif
  

• leave empty set_this_thread_name() on windows
• #undef PASSTHROUGH looks strange to me, i assume it's only needed for _WIN32 and should be placed in serial.cpp only.

I have a quick look at other patches - couldn't understand why to move protected/private elements.

[Tobias-Fischer]

Thanks for checking. Re moving the protected and private members: the VS compiler otherwise complains with https://docs.microsoft.com/en-us/cpp/error-messages/compiler-errors-1/compiler-error-c2248?view=msvc-160

So you have general interest in this?

[vooon]

In general yes, it's good to have support. If it not involves too much preprocessor magic...

Still do not see reason for that reports at the first place. That members only accessed by the class it self, or by children.

[Tobias-Fischer]

The access violation happens with these kind of casts etc - there's probably a better way but I don't know how.

mavros/mavros/include/mavros/setpoint_mixin.h

Line 91 in ceb53a4

mavros::UAS *m_uas_ = static_cast<D *>(this)->m_uas;

[vooon]

Hmm, try to move friend definition in plugin class to public.