# XRSound Open-Source Development

#### martins

##### Orbiter Founder
Orbiter Founder
Good news here @martins! I believe what happened before was that I was in the wrong Orbiter folder on my local system -- on the second test, I believe I was in my old cloned repo folder that was not a clean fetch, but was just an update of the previous Orbiter repository folder (sorry about that!). Tonight I did a clean repo clone to a new folder, and XRSound builds (and works!) as part of the Orbiter build now! Nice work!
That is excellent news! Maybe you want to go through the CMakeLists.txt files in the sound directory, just to make sure I didn't miss anything that needs to be built or deployed. Regarding the VS project and solution files - these are strictly speaking no longer necessary with the cmake files. I don't know if you want to keep them in for people who want to build XR sound without cmake, but then both build systems will have to be kept up to date. Once you are happy with the branch we can merge it into main to get rid of the CTDs you mention.
One side note for all -- I was getting a CTD on orbiter_ng.exe startup 50% of the time from the trigger_sound_build_cmake branch (which was forked off an older version of main), and after tracing the cause, it turns out that intermittent startup CTD as well as the rest of the x64 pointer truncation warnings are already fixed in the main branch. So if anyone is running an older version of main, you will want to pull the latest main branch changes to fix that potential CTD on startup.
I think this is thanks to a DarkWanderer pull request. Open source community at work!

#### dbeachy1

Orbiter Contributor
Donator
Beta Tester
That is excellent news! Maybe you want to go through the CMakeLists.txt files in the sound directory, just to make sure I didn't miss anything that needs to be built or deployed. Regarding the VS project and solution files - these are strictly speaking no longer necessary with the cmake files. I don't know if you want to keep them in for people who want to build XR sound without cmake, but then both build systems will have to be kept up to date. Once you are happy with the branch we can merge it into main to get rid of the CTDs you mention.

I definitely want to also keep the .vcxproj + .sln files for XRsound -- I use those to build and debug XRSound. I'm happy to update both the .vcxproj files and the CMake files for XRSound going forward if/when I add or remove source files.

As for the trigger_sound_build_cmake branch, the XRSound build looks good to me except that out\build\x64-Debug\Orbitersdk\XRSound\XRSoundD.lib is not yet built during deployment in the CMake files. However, that will need to invoke the Debug build for the XRSoundLib project to generate the debug version of that static library. Since XRSound.lib and XRSoundD.lib must be static libraries, users need XRSoundD.lib so they can build debug versions of their vessels or plugins that use XRSound. For example, if a user tries to link a debug version of their vessel with the release version of XRSound.lib, the linker fails with this error:

4>XRSound.lib(XRSound.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in DeltaGliderXR1.obj
4>XRSound.lib(XRSound.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in DeltaGliderXR1.obj

Linking with the debug version XRSound.lib, which is XRSoundD.lib, works fine (as expected).

#### martins

##### Orbiter Founder
Orbiter Founder
I have now tried to add a XRSoundD.lib target with manually set debug flags. Could you try if that does the trick? The library file generated this way is not the same size as the one generated by the global x64-debug configuration, so I probably didn't manage to set or replace all flags, but maybe it still works?

#### dbeachy1

Orbiter Contributor
Donator
Beta Tester
Well, it's getting closer, but not quite there yet. (Note that I'm linking with the x86 Orbiter-generated XRSound.lib, since I don't have the XR vessels ported to x64 yet.) The XRSoundD.lib is now a Debug version, so that's good! However, now XRSound.lib is also a debug version, albeit with a very slightly different size, perhaps due to different pathnames in the embedded debug information? Here is the log when I build the XR1 in Release mode using the XRSound.lib from orbiter\out\build\x86-Debug\Orbitersdk\XRSound:

Code:
3>XRSound.lib(XRSound.cpp.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in DeltaGliderXR1.obj
3>XRSound.lib(XRSound.cpp.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value 'MD_DynamicRelease' in DeltaGliderXR1.obj
3>XRSound.lib(XRSoundImpl.cpp.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in DeltaGliderXR1.obj
3>XRSound.lib(XRSoundImpl.cpp.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value 'MD_DynamicRelease' in DeltaGliderXR1.obj

#### GLS

##### Well-known member
Orbiter Contributor
Well, it's getting closer, but not quite there yet. (Note that I'm linking with the x86 Orbiter-generated XRSound.lib, since I don't have the XR vessels ported to x64 yet.) The XRSoundD.lib is now a Debug version, so that's good! However, now XRSound.lib is also a debug version, albeit with a very slightly different size, perhaps due to different pathnames in the embedded debug information? Here is the log when I build the XR1 in Release mode using the XRSound.lib from orbiter\out\build\x86-Debug\Orbitersdk\XRSound:

Code:
3>XRSound.lib(XRSound.cpp.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in DeltaGliderXR1.obj
3>XRSound.lib(XRSound.cpp.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value 'MD_DynamicRelease' in DeltaGliderXR1.obj
3>XRSound.lib(XRSoundImpl.cpp.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in DeltaGliderXR1.obj
3>XRSound.lib(XRSoundImpl.cpp.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value 'MD_DynamicRelease' in DeltaGliderXR1.obj
Could the Release build be linking msvcrtd.dll instead of msvcrt.dll? Check C/C++ > Code Generation > Runtime Library.

#### martins

##### Orbiter Founder
Orbiter Founder
Well, it's getting closer, but not quite there yet. (Note that I'm linking with the x86 Orbiter-generated XRSound.lib, since I don't have the XR vessels ported to x64 yet.) The XRSoundD.lib is now a Debug version, so that's good! However, now XRSound.lib is also a debug version, albeit with a very slightly different size, perhaps due to different pathnames in the embedded debug information? Here is the log when I build the XR1 in Release mode using the XRSound.lib from orbiter\out\build\x86-Debug\Orbitersdk\XRSound:

Code:
3>XRSound.lib(XRSound.cpp.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in DeltaGliderXR1.obj
3>XRSound.lib(XRSound.cpp.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value 'MD_DynamicRelease' in DeltaGliderXR1.obj
3>XRSound.lib(XRSoundImpl.cpp.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in DeltaGliderXR1.obj
3>XRSound.lib(XRSoundImpl.cpp.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value 'MD_DynamicRelease' in DeltaGliderXR1.obj
Did you configure cmake for x86-Release or x86-Debug? Note that XRSound.lib is built in line with cmake configuration (Release or Debug), while XRSoundD.lib is always supposed to be built in Debug mode. So if the build is configured for Debug, both libraries should be identical.

Incidentally, I missed out the flag for debug runtime libraries (/MDd) in the flags for XRSoundD.lib. I've fixed this in the latest commit to trigger_sound_build_cmake. I now get the following file sizes (x86):
 x86-Debug x86-Release XRSound.lib 122,442 20,514 XRSoundD.lib 122,458 122,462
The debug versions are all slightly different size, which is a bit strange, but this may just be a compiler oddity. Anyway, it looks roughly like I would have expected (XRSoundD always a debug build, and XRSound conforming to the build configuration).
I've attached the vcxproj files for XRSound.lib and XRSoundD.lib that the VC generator produced. The interesting section is the Release configuration in XRSound_lib_DBG.vcxproj which should actually provide the flags for a debug build. It disables all optimisations and uses MultiThreadedDebugDLL, so that looks good. Can you spot anything that isn't set as required?

#### Attachments

• XRSound_vcxproj.zip
4.6 KB · Views: 0

#### AnakinSkyobiliviator

##### Member
This is excellent news! Looking forward to see how this develops! Currently I have to flip flop between this and Orbiter Sound, but I hope one day the two key sound mods would work together!

#### dbeachy1

Orbiter Contributor
Donator
Beta Tester
Hmm, I'm still getting the result of both XRSound.lib and XRSoundD.lib both being the same build type (either both Debug or both Release versions) depending on which Orbiter target I build. I tested the generated libraries by linking the XR1 with the generated XRSound.lib for Release and XRSoundD.lib for Debug, as always. However, when building Orbiter x86-Debug, both XRSound libs are a Debug build, and when building Orbiter x86-Release, both XRSound libs are a Release build (the sizes vary a bit due to the different paths in the embedded debug information in each library file).

I've fetched the latest changes in the trigger_sound_build_cmake branch, added the x86-Debug and x86-Release targets in the CMake settings, then clicked Project -> Configure Orbiter, then Rebuild All.

Here are the library sizes when building x86-Release:

Code:
 Directory of D:\GitHub\orbiter\out\build\x86-Release\Orbitersdk\XRSound

07-Aug-2021  02:05 PM    <DIR>          .
07-Aug-2021  02:05 PM    <DIR>          ..
07-Aug-2021  02:05 PM            11,913 XRSound.h
07-Aug-2021  02:05 PM           149,316 XRSound.lib
07-Aug-2021  02:05 PM           138,834 XRSoundD.lib
3 File(s)        300,063 bytes

...and here are the library sizes when building x86-Debug:

Code:
 Directory of D:\GitHub\orbiter\out\build\x86-Debug\Orbitersdk\XRSound

07-Aug-2021  02:19 PM    <DIR>          .
07-Aug-2021  02:19 PM    <DIR>          ..
07-Aug-2021  02:19 PM            11,913 XRSound.h
07-Aug-2021  02:19 PM           144,898 XRSound.lib
07-Aug-2021  02:19 PM           144,930 XRSoundD.lib
3 File(s)        301,741 bytes

Is it possible to configure CMake so that that regardless of which Orbiter target is building built (Debug or Release), XRSound.lib would always be a Release version, and XRSoundD.lib would always be a Debug version? As it is now, it appears that either both libraries are Debug or both libraries are Release, depending on which Orbiter target is being built.

Thinking out loud, is it possible that the set(DBG_COMPILE_FLAGS "/Zi /Ob0 /Od /RTC1") CMake command in Sound/XRSound/XRSound/src/XRSoundLib/CMakeLists.txt only sets those flags for Debug builds? i.e., do those flags have any effect on a Release build? I have not worked with CMake before, though, so that's just a wild guess.

EDIT:
If it helps, I could write up a tiny VS 2019 project that links with XRSound.lib for Release and XRSoundD.lib for debug that I could zip up and post here so that you could use that for quick testing of the generated XRSound*.lib files.

Last edited:

#### martins

##### Orbiter Founder
Orbiter Founder
I'd still like to figure out why we a getting different results. Here is what I get for x86-Release:
Code:
 Directory of C:\Source\Orbiter_devel\Orbiter_build\x86-Release\Orbitersdk\XRSound

07/08/2021  23:04    <DIR>          .
07/08/2021  23:04    <DIR>          ..
07/08/2021  22:45            11,913 XRSound.h
07/08/2021  22:40            24,766 XRSound.lib
07/08/2021  22:40           145,474 XRSoundD.lib
and x86-Debug:
Code:
 Directory of C:\Source\Orbiter_devel\Orbiter_build\x86-Debug\Orbitersdk\XRSound

07/08/2021  23:08    <DIR>          .
07/08/2021  23:08    <DIR>          ..
07/08/2021  22:54            11,913 XRSound.h
07/08/2021  22:47           145,426 XRSound.lib
07/08/2021  22:47           145,458 XRSoundD.lib
I'm scatching my head what could cause the difference in the Release build ...

#### n72.75

Tutorial Publisher
Donator
Local user preferences that aren't part of the git repository?

#### dbeachy1

Orbiter Contributor
Donator
Beta Tester
I'd still like to figure out why we a getting different results. Here is what I get for x86-Release:

Just to double-check, you are building in the trigger_sound_build_cmake branch, right? The latest commit in that branch I have is hash 68f6967e0afd17812d4366f7c5603fc3356da439 from 6-Aug-2021 at 17:14:51.

In any case, since it's clearly working for you, that means the releases will have the correct files, and that's what really matters. I'll just be building and running debug builds anyway here, plus I plan to use the XRSound .vcxproj and .sln files anyway for my XRSound maintenance, so I think the trigger_sound_build_cmake changes looks fine. From my perspective, feel free to merge that branch into main!

#### martins

##### Orbiter Founder
Orbiter Founder
Before letting this go, maybe just one more attempt. I have pushed a new commit to the trigger_sound_build_cmake branch. This uses a different approach for building the XRSoundD.lib library, as an external project explicitly requesting a debug build.

Could you give this a try? If it still doesn't work for you maybe I'll have admit defeat. CMake really doesn't seem to take kindly to bypassing its own configuration settings.

#### dbeachy1

Orbiter Contributor
Donator
Beta Tester
Sure! So I pulled the latest changes from the trigger_sound_build_cmake branch and built the x86-Debug version of the XR1, but it appears that the XRSoundD.lib versions that are being built by both Orbiter x86-Debug and Orbiter-x86-Release is the 64-bit version of XRSoundD.lib:

3> Creating library D:\Orbiter2016_XRSound\Orbitersdk\dougb\XRVessels\XRVessels\Debug\DeltaGliderXR1.lib and object D:\Orbiter2016_XRSound\Orbitersdk\dougb\XRVessels\XRVessels\Debug\DeltaGliderXR1.exp
3>XR1Lib.lib(XRVessel.obj) : error LNK2019: unresolved external symbol "public: static class XRSound * __cdecl XRSound::CreateInstance(class VESSEL *)" ([email protected]@@[email protected]@@@Z) referenced in function "protected: virtual bool __thiscall DeltaGliderXR1::InitSound(void)" ([email protected]@@MAE_NXZ)
3>..\..\..\XRSound\XRSoundD.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'x86'
3>D:\Orbiter2016_XRSound\Orbitersdk\dougb\XRVessels\XRVessels\Debug\DeltaGliderXR1.dll : fatal error LNK1120: 1 unresolved externals

So then I tried building the x86-Release version of the XR1 to test the XRSound.lib versions generated by the Orbiter build. The XRSound.lib built by Orbiter x86-Release is correct (it links cleanly), but the XRSound.lib built by Orbiter x86-Debug is still the debug version for me:

3>XRSound.lib(XRSound.cpp.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in DeltaGliderXR1.obj
3>XRSound.lib(XRSound.cpp.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value 'MD_DynamicRelease' in DeltaGliderXR1.obj

Anyway, what I want to do next is add another (small) project to XRSound.sln in the repo that links with XRSound.lib for Release builds and XRSoundD.lib for Debug builds to make this easier to test for everyone, including myself lol.

#### martins

##### Orbiter Founder
Orbiter Founder
Boy, this is turning into quite a challenge

I've pushed the next release which addressess the x86/x64 issue. Could you check if that problem is solved?

Regarding XRSound.lib being a debug version for the Orbiter x86-Debug build: this is actually the intended behaviour. I wanted the library to conform to the global Orbiter build configuration, so it can be used directly by the rest of the build process whenever referenced, without having create if/else clauses that check for debug/release build. Is that a problem? It seems unlikely that somebody working with an Orbiter debug build would need a release version of XRSound.lib. If I understand correctly, the XRSoundD.lib file is intended for developers who have installed an Orbiter (non-debug) release but want to test their addon in debug mode.

If it is a problem, I could add a further target XRSoundR.lib which is always build as a release version.

A test project that uses XRSound(D).lib for testing is a good idea.

Last edited:

#### dbeachy1

Orbiter Contributor
Donator
Beta Tester
Boy, this is turning into quite a challenge

I've pushed the next release which addressess the x86/x64 issue. Could you check if that problem is solved?

Yeah, definitely a challenge! When I pull those latest changes to CMakeLists.txt, the build fails with a cryptic error for me whenever I try to build Orbiter x86 Debug or Orbiter x86 Release (both x64 builds succeed, however). I triple-checked that it isn't trying to build the documentation, but the build just halts with this generic error:

Code:
[79/593] cmd.exe /C "cd /D D:\GitHub\orbiter\out\build\x86-Release && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy_directory D:/GitHub/orbiter/BinAssets/ D:/GitHub/orbiter/out/build/x86-Release && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy_directory D:/GitHub/orbiter/Scenarios/ D:/GitHub/orbiter/out/build/x86-Release/Scenarios && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy_directory D:/GitHub/orbiter/Textures/ D:/GitHub/orbiter/out/build/x86-Release/Textures && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy_directory D:/GitHub/orbiter/Meshes/ D:/GitHub/orbiter/out/build/x86-Release/Meshes && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy_directory D:/GitHub/orbiter/Script/ D:/GitHub/orbiter/out/build/x86-Release/Script && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy_directory D:/GitHub/orbiter/Config/ D:/GitHub/orbiter/out/build/x86-Release/Config && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy_directory D:/GitHub/orbiter/Flights/ D:/GitHub/orbiter/out/build/x86-Release/Flights && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy_directory D:/GitHub/orbiter/Orbitersdk/include/ D:/GitHub/orbiter/out/build/x86-Release/Orbitersdk/include && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E make_directory D:/GitHub/orbiter/out/build/x86-Release/Orbitersdk/lib/Lua && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy D:/GitHub/orbiter/Extern/Lua/Lua-5.1-x86/dll/lua5.1.lib D:/GitHub/orbiter/out/build/x86-Release/Orbitersdk/lib/Lua/ && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy D:/GitHub/orbiter/Extern/Lua/Lua-5.1-x86/dll/lua5.1.dll D:/GitHub/orbiter/out/build/x86-Release"
ninja: build stopped: subcommand failed.

If I reset the branch to the previous commit, everything still builds fine.

Regarding XRSound.lib being a debug version for the Orbiter x86-Debug build: this is actually the intended behaviour. I wanted the library to conform to the global Orbiter build configuration, so it can be used directly by the rest of the build process whenever referenced, without having create if/else clauses that check for debug/release build. Is that a problem? It seems unlikely that somebody working with an Orbiter debug build would need a release version of XRSound.lib. If I understand correctly, the XRSoundD.lib file is intended for developers who have installed an Orbiter (non-debug) release but want to test their addon in debug mode.

Yes, that's correct -- XRSoundD.lib is necessary for developers who want to build their add-on in Debug mode (which is hopefully all of them, lol). So the only real build targets that matter are Orbiter x86-Release and Orbiter x64-Release, since only those build artifacts will be published for users. So I agree it's fine if the Orbiter Debug targets don't create a Release version of XRSound.lib.

If it is a problem, I could add a further target XRSoundR.lib which is always build as a release version.

I agree that it's fine -- only the Release builds matter.

A test project that uses XRSound(D).lib for testing is a good idea.

I just created a pull request with the new project -- details are in the README.md here. The only build targets in the new test app that are relevant now are these:
• Debug-with-OrbiterRelease x86
• Release-with-OrbiterRelease x86
• Debug-with-OrbiterRelease x64
• Release-with-OrbiterRelease x64
...since only the OrbiterRelease x86 and OrbiterRelease x64 build artifacts will be released to end users. I initially tested the app by manually copying in known good versions of XRSound.lib and XRSoundD.lib to the Orbiter project output folders (e.g., orbiter\out\build\x64-Release\Orbitersdk\XRSound\, etc.).

The good news is that I was then able to test (only) the x64 versions of XRSound.lib and XRSoundD.lib built by Orbiter's CMake (via the test app's Debug-with-OrbiterRelease x64 and Release-with-OrbiterRelease x64 build targets), and both worked! So the only remaining issue is the Orbiter x86 targets not building for me with the latest commit as detailed at the top of this post. But we're getting there! You should also be able to test the generated XRSound.lib and XRSoundD.lib files now by using the new test app.

#### martins

##### Orbiter Founder
Orbiter Founder
Ok, I tried to build XRSound-lib-linktest. Six of them linked successfully. The two that failed were Release-with-OrbiterDebug (x86 and x64) as expected. So I guess what remains to be figured out is why the latest trigger_sound_build_cmake doesn't build for you. Unfortunately the Ninja build log isn't particularly helpful, it seems. Sometimes the actual error message appears considerably up from when the build stops. Could you check if there is anything suspicious higher up the output (maybe search for 'error')? The only thing I added was explicitly specifying the build platform for the XRSoundD.lib target.

#### dbeachy1

Orbiter Contributor
Donator
Beta Tester
Ok, I tried to build XRSound-lib-linktest. Six of them linked successfully. The two that failed were Release-with-OrbiterDebug (x86 and x64) as expected. So I guess what remains to be figured out is why the latest trigger_sound_build_cmake doesn't build for you. Unfortunately the Ninja build log isn't particularly helpful, it seems. Sometimes the actual error message appears considerably up from when the build stops. Could you check if there is anything suspicious higher up the output (maybe search for 'error')? The only thing I added was explicitly specifying the build platform for the XRSoundD.lib target.

Thanks for the tip on searching higher up in the log! There was indeed an error about 30 lines up (highlight added):

[42/593] Performing configure step for 'XRSoundD'
FAILED: Sound/XRSound/XRSound/src/XRSoundLib/tmp/src/XRSoundD-stamp/XRSoundD-configure
cmd.exe /C "cd /D D:\GitHub\orbiter\out\build\x86-Debug\Sound\XRSound\XRSound\src\XRSoundLib\tmp && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -A Win32 -DCMAKE_BUILD_TYPE=Debug -DFORCE_DEBUG=TRUE -DORBITER_SOURCE_SDK_INCLUDE_DIRATH=D:/GitHub/orbiter/Orbitersdk/include -DORBITER_BINARY_SDK_DIRATH=D:/GitHub/orbiter/out/build/x86-Debug/Orbitersdk D:/GitHub/orbiter/Sound/XRSound/XRSound/src/XRSoundLib && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E touch D:/GitHub/orbiter/out/build/x86-Debug/Sound/XRSound/XRSound/src/XRSoundLib/tmp/src/XRSoundD-stamp/XRSoundD-configure"
D:\GitHub\orbiter\out\build\x86-Debug\CMake Error : error : generator platform: Win32
Does not match the platform used previously:

Either remove the CMakeCache.txt file and CMakeFiles directory or choose a different binary directory.

In case anyone else hits this in the future, here is how I fixed it:
1. Deleted the four build output folders under orbiter\out\build.
2. Selected build target x86-Debug in Visual Studio, then saved the CMake JSON settings file.
3. Clicked Project -> Configure Orbiter.
4. Clicked Build -> Rebuild All.
That built cleanly! So then I repeated steps 2-4 for the other build targets -- x86-Release, x64-Debug, and x64-Release, and (this time!) all of them built cleanly.

So then I tested the generated XRSound.lib and XRSoundD.lib files using the XRSound-lib-linktest project for all eight configurations (via Rebuild All in Batch Build), and I'm happy to report that I'm seeing the exactly same results you did, as expected: six configurations passed, and x86-Release-with-OrbiterDebug and x64-Release-with-OrbiterDebug failed, as expected.

To sum up, everything looks good now! Thanks for all your hard work on this.

#### martins

##### Orbiter Founder
Orbiter Founder
Great stuff. I've pushed one more commit to trigger_sound_build_cmake to make the location of the Orbiter build directory a user macro in the XRSound-lib-linktest project. I had to do this because my build directory is set up differently, outside the source directory (I prefer to contaminate my source directory as little as possible). I've reset the macro to your configuration before committing, since this is probably what most users will be configured for.

If you could just check that XRSound-lib-linktest still works out of the box for you, I think we are all set. If you are happy, I'll merge the branch into main.