This is a status report on Windows support for rviz. I'll describe the current state and list some things I've tried and some things that we need to do in order to get Windows fully supported in our "official release" of ROS 2.

First, the current state is this:

• builds through rviz_common, but fails to link to rviz2 (the executable)
• implicitly requires cmake 3.10 (or at least not 3.9)

The linking issue is due to Ogre symbols not being found by the rviz2_app executable. The reason (I think) is that rviz_common is a static library right now and so is the Ogre library, so it is not getting propagated correctly.

The solution, I believe, is to make both Ogre and rviz_common's library shared. I started doing this last night, but that brought with it some issues with freetype and Ogre as well as needing visibility control (dll import/export) for the API in rviz_common. I got that "done" (not fully tested), but then got hung up on some other Ogre issues. Here's the branch for that work in progress:

#143

Now, I ended up giving up on getting it in, because even with those issues fixed I would likely need a day or two to get rviz on Windows into mergeable shape for our CI, which would mean:

• actually compiling and linking and running
• no warnings (this includes dependencies like Ogre and the things Ogre builds like freetype)
• proper library paths at runtime (like when using our binary and not building from source)
• finding a good way to explicitly require a version of cmake that doesn't have the automoc issue

I simply didn't have time to do that, unfortunately.

I also wanted to point out a few things about the above branch:

• I prevent Ogre from building dependencies
  • I do this because if those dependencies throw warnings then I cannot easily suppress them
• I made Ogre create shared libraries, but the rviz_ogre_vendor package's cmake files were modified in a hacky way, so they need to be fixed up
• I made rviz_common into a shared library, but I think there might be some lingering issues with the dll import/export stuff I did (again not well tested)
• I didn't try debug builds yet, might be broken again

We could alternatively turn back on Ogre building it's own dependencies, but to do that we'd either need to:

• patch ogre so it suppresses warnings when building its dependencies
• make our build farm ignore these warnings some how
  • might be more work than suppressing them

Oh, and on the topic of suppressing warnings, Windows has a silly thing where I try to suppress all warnings with /w but then I get a non-suppressable warning that /w overrides the existing command line argument /W1. I was frustratingly unable to find where that flag was being introduced and that was another reason I didn't think I could get rid of all of the warnings before the release.