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. ?