FindLibOVR always selects the 32bit version of the Oculus SDK on Visual Studio 16 2019

[S-Dafarra]

FindLibOVR detects the SDK version to be used by using CMAKE_GENERATOR_PLATFORM https://github.com/robotology/ycm/blob/32e544488537e435d61ffe237bb72f3908552c9c/find-modules/FindLibOVR.cmake#L55

On Visual Studio 16 2019 this variable is not set, thus defaulting to the 32bit version.

@traversaro

[traversaro]

Related comment:

From Visual Studio 16 2019, if CMAKE_GENERATOR_PLATFORM is not specified, CMake defaults to x64, while before it was default to Win32, so for Visual Studio <= 2017 the logic is actually valid, but it is broken for VS 2019. A quick fix is just to invoke the CMake of the superbuild or of YARP with the -A x64 option, that explicitly sets the CMAKE_GENERATOR_PLATFORM to x64. A proper fix is to check CMAKE_SIZEOF_VOID_P to know if we are targeting Windows 32-bit or 64-bit. This probably does not work correctly for cross-compilation (Windows on arm64, uwp, etc etc), but I guess that in any case the Oculus SDK is not available on those platforms.

[drdanz]

I'm not completely sure, but I don't think this is an issue of the module, if I understand correctly, CMAKE_GENERATOR_PLATFORM should be x64 when compiling for 64 bit windows, perhaps you are not actually building for x64? Or perhaps the CMAKE_VS_PLATFORM_NAME variable should be considered instead? (Adding also a link to CMAKE_GENERATOR for reference)

@traversaro can you add a link to the "Related comment" above?

[traversaro]

CMAKE_GENERATOR_PLATFORM should be x64 when compiling for 64 bit windows, perhaps you are not actually building for x64?

I did the same assumption, but the key docs is:

Generator-specific target platform specification provided by user.

If the user does not specify anything (i.e. the default generator is used) then the property is empty. So defaulting to 32-bit is ok for VS <= 2017, but not for VS2019 whose CMake generator defaults depend on the host platform, see https://cmake.org/cmake/help/latest/variable/CMAKE_VS_PLATFORM_NAME_DEFAULT.html#cmake-vs-platform-name-default . Probably using CMAKE_VS_PLATFORM_NAME is indeed the correct way to proceed.

CMAKE_VS_PLATFORM_NAME_DEFAULT — CMake 3.18.2 Documentation

[traversaro]

@traversaro can you add a link to the "Related comment" above?

The related comment is the one that I copied, is just something that I copied from a private issue tracker.