search

microsoft / Azure-Kinect-Sensor-SDK

A cross platform (Linux and Windows) user mode SDK to read data from your Azure Kinect device.
https://Azure.com/Kinect
MIT License
1.47k stars 614 forks source link

libsoundio can't build with CMake 3.18 #1363

Open UnaNancyOwen opened 3 years ago

UnaNancyOwen commented 3 years ago

Describe the bug

libsoundio on which Azure Kinect sensor SDK depends can’t be built with projects generated by CMake 3.18 (or later). However, It can be built with projects generated by CMake 3.17.

I have tried compare the compiler options. The compiler options of projects generated by CMake 3.17 and CMake 3.18 are as follows.

The difference between options is /TP. It is in the compiler option of projects generated by CMake 3.17. But, It is not in the compiler option of projects generated by CMake 3.18.

We need to add /TP to the compiler options of K4A/libsoundio_static project in some way.

To Reproduce

  1. Generate Azure Kinect Sensor SDK project using CMake 3.18.
  2. Open that project using Visual Studio 2019.
  3. Build ALL_BUILD project. (or libsoundio_static project)

Expected behavior

Logs

Screenshots

2020-09-25 180726 2020-09-25 180744

Desktop (please complete the following information):

Additional context

Related Infomation: https://gitlab.kitware.com/cmake/cmake/-/issues/20822

soeroesg commented 3 years ago

I can confirm that the problem exists with CMake 3.18.4, but there is no problem when using CMake 3.17.5

The issue seems to be caused by the change in how CMake treats .C files as C and not C++ as default anymore. Therefore __cplusplus will be not defined, stdatomic.h is searched for, and is not found.

jaygullapalli commented 3 years ago

This is addressed in latest version of Visual Studio 2019 16.9.0 and above which updated cmake to 3.19 I was able to build libsoundio without any issues in Visual Studio 2019 v16.9.4 / cmake 3.19.20122902-MSVC_2

UnaNancyOwen commented 3 years ago

I think it is CMake forked by Microsoft (cmake 3.19.20122902-MSVC_2). But, This issue is reproduces in CMake of Kitware (original) yet.

jaygullapalli commented 3 years ago

I spoke too soon. The issue exists even in cmake 3.19.20122902-MSVC_2, I was using Ninja as the build generator within Visual Studio when I was able to build without any issues. It looks like the issue happens when using Visual Studio Generators with CMake.

Using Ninja as the generator with libsoundio - FLAGS = /DWIN32 /D_WINDOWS /W3 /ZH:SHA_256 /MD /Zi /O2 /Ob1 /DNDEBUG /TP /W4

UnaNancyOwen commented 3 years ago

Thanks for additional info! I understood it. It is looks odd that difference of result between Ninja and Visual Studio generators. I think it is a trap that someone will fall into in the future. I think we needs to continue to be worked about this issue on until a good solution is found.

DavidGoedicke commented 3 years ago

I am getting the same error. What can I do right now to keep working on this before the bug gets fixed?

Thank You :-)

jaygullapalli commented 3 years ago

@DavidGoedicke please use Ninja as the generator with cmake (instead of Visual Studio Generator). If you are building from command line then cmake .. -GNinja (from your build folder) and running ninja should work without issues. If you are building from within Visual Studio you can also change the Generator to Ninja (https://docs.microsoft.com/en-us/cpp/build/customize-cmake-settings?view=msvc-160)

UnaNancyOwen commented 3 years ago

@DavidGoedicke You can work around this problem temporarily by changing the options manually, or using CMake 3.17. (It's not so good work around. I consider that this measure isn’t going to lead to a solution that gets to the roots of the matter.)