Add preprocessor directives for Win32 build

eidetic-av commented 3 years ago

Hi! I don't know what your status on windows builds is because your readme says "Windows build instructions coming soon", but I went ahead and built it for Windows myself using CMake and Visual Studio 2019.

For CMakeLists.txt I just had to remove the compiler flags that are only applicable to gcc. Most of the commit is just swapping header files for windows-specific ones.

Also the 'ushort' type wasn't available for me. I don't know whether u_short is available for gcc/linux etc. so I just wrapped a redefinition in the windows preprocessor directive, too.

After these changes I can then compile the project fine in Visual Studio 2019 after running: cmake .. -G"Visual Studio 16 2019" -DSSP_WITH_KINECT_SUPPORT=ON.....

I did need to manually point to the proper lib and include directory locations in the project properties in VS.

olenkapolak commented 3 years ago

Hey thanks for this! We're going to put a link to your PR on our README until we validate.

amourao commented 3 years ago

Hi @eidetic-av, it is quite exciting to see someone running SSP on Windows.

I'm curious on a couple of details to check how you built SSP on VS, so we could test it and add the instructions to the README file:

did you use the exact dependency versions as the ones in the install file?
did you compile all the dependencies or did you use something like vcpkg?
did you compile with NvPipe support? (I just noticed NvPipe depreciation notice by Nvidia)

Thanks!

eidetic-av commented 3 years ago

did you use the exact dependency versions as the ones in the install file?

I didn't. Sorry about that. I pretty much used what was available to me (most of the time straight from the master branch of the repositories).

did you compile all the dependencies or did you use something like vcpkg?

I didn't use vcpkg. Apart from the Azure Kinect SDK, I compiled the dependencies myself.

did you compile with NvPipe support?

I did not use NvPipe. On my Windows machine, the CPU usage from ssp_server was low enough (3-4%), so I didn't bother trying.

Here are the dependency versions I am using:

OpenCV 3.4.13 — compiled from the opencv github repo on the 3.4 branch.
- I chose this because it was the most up-to-date version of OpenCV 3.
libav master branch
- Unfortunately I couldn't compile this on Windows! I couldn't get the MSYS2 build working...
- I ended up cross-compiling this using mingw on my Arch Linux machine.
Cereal master branch
ZeroMQ master branch and cppzmq master branch
spdlog master branch
yaml-cpp master branch
Zdepth master branch
Latest Azure Kinect SDK and Body Tracking SDK binaries
- Downloaded from the Microsoft website.

The reason I compiled the dependencies from source is because these projects either didn't have prebuilt binaries for Windows, or the publicly available downloads weren't built for Visual Studio 2019, which is what I am using. The ZeroMQ download page, for example, only shares binaries configured up to Visual Studio 2017.

If you like, I could try testing a build with all of the versions listed in your install readme. Let me know.

There are actually a few more build issues that I realised after I submitted this PR. Some semantics in the libav_encoder are not allowed with the MS compiler, and the #undef and redefinition of av_err2str in utils.h is also causing some issues. I will investigate both of these a little further and add some updates.

Thank you for this project! It has been a very straightforward way to implement some of these state-of-the-art compression algorithms (zstd). I am working on a simple client that integrates as a plugin for Unity.

eidetic-av commented 3 years ago

I've added a few more source code changes that ensure all components build in Visual Studio. See the commits above.

There's still a few changes to make in the CMakeLists.txt however. At the moment I only have the build working after manually specifying '.lib' files in the linker options within VS.

amourao commented 3 years ago

@eidetic-av , thanks for the additional commits and build information. They've been very helpful!

I've managed to build part (most?) of the project (ssp_clients) using the vcpkg version of the libs (including libav), which can greatly simplify the build process.

My only (current) issue is building packages that use spdlog (ssp_server), more specifically in the fmt dependency

Error C2668 'fmt::v7::detail::arg_mapper<Context>::map': ambiguous call to overloaded function C:\Users\Andre\source\repos\Sensor-Stream-Pipe\out\build\x64-Debug (default)\Sensor-Stream-Pipe C:\Users\Andre\libs\include\spdlog\fmt\bundled C:\Users\Andre\libs\include\spdlog\fmt\bundled\core.h 1239 1 Build

I've tried both the vcpkg and master versions of spdlog, with no success.

Did you have any similar issues?

eidetic-av commented 3 years ago

I don't have this exact issue, but I looked through my headers and realised I had commented out a static assertion in the bundled fmt that was preventing ssp_server from building. Forgot to document this, d'oh!

So, in spdlog version 1.8.1 the static_assert() that fails the build is inside the fmt::v7::detail::arg_mapper<Context>::map() definition that your error is referencing... This is not the exact same error as yours, but it is preventing the build at the same place... so surely it is related?

I'm able to comment out this function so it looks like:

  int map(...) {
    constexpr bool formattable = sizeof(Context) == 0;
    // static_assert(
    //    formattable,
    //    "Cannot format argument. To make type T formattable provide a "
    //    "formatter<T> specialization: "
    //    "https://fmt.dev/latest/api.html#formatting-user-defined-types");
    return 0;
  }

Obviously this is not an actual solution... but it does allow the build to succeed. If you comment out the same section in spdlog/fmt/bundled/core.h are you able to successfully compile?

eidetic-av commented 3 years ago

I think I figured it out... that's if our build problems are actually caused by the same issue!

The line that is failing the build is line 239 in libav_encoder.cc.

spdlog::info("Codec information:\n {}", codec_parameters_);

If I comment this out the build passes.

I think fmt is not able to implicitly convert a YAML::Node into a printable type? Hence the "Cannot format argument" error that I receive. The solution here seems to be either to create a formatter<YAML::Node> or just retrieve the codec parameters individually and pass them onto spdlog::info(...) as strings already.

It is strange you're receiving a different error, but it is still seems related to the function arguments.

Does removing this line in libav_encoder.cc allow you to build?

amourao commented 3 years ago

Does removing this line in libav_encoder.cc allow you to build?

Yup, that was it! Navigating up the generics C++ error error trace is always a fun challenge. VS Code kept showing the error only on the fmt library with no indication of where the error was originating in SSP.

Finally got everything to built correctly, and, as a bonus, if you use vcpkg, you'll only need to build zdepth manually.

I'll cleanup the CMake file and update the README with instructions.

moetsi / Sensor-Stream-Pipe

Add preprocessor directives for Win32 build #6