x64 Development

yitianetie

Member
Joined
Mar 24, 2020
Messages
48
Reaction score
14
Points
23
Location
Brittany
I am seeing the hard work that you perform to build a stable 64 bits version. Could we test it in a near future ?
 

n72.75

Addon Developer
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,297
Reaction score
846
Points
128
Location
Biddeford ME
Website
mwhume.space
Preferred Pronouns
he/him
When migrating the D3D9Client into the Orbiter repository what's gonna happen for the project history. For me it really doesn't matter. I am just asking if I should import the project history from SVN to Git or Not ?
You should be able to import the svn history into git. If the d3d9 client is going to be worked on via commits to the orbiter repository, then it would make sense to have it.

If you were going to still work on it via svn and only "commit" full release versions, then I would say no.

I would advocate the first option l.
 

Zatnikitelman

Addon Developer
Addon Developer
Joined
Jan 13, 2008
Messages
2,302
Reaction score
6
Points
38
Location
Atlanta, GA, USA, North America
I'm curious, for everyone that's been able to build and run an x64 build of Orbiter, has there been a performance improvement, or are we nowhere close to even thinking about that yet?
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,358
Reaction score
513
Points
153
Location
Vienna
I'm curious, for everyone that's been able to build and run an x64 build of Orbiter, has there been a performance improvement, or are we nowhere close to even thinking about that yet?
Well, I can only speak for my build - which is not equal to the latest main - where I can't see any difference in performance. What I do see, though, is a slight increase in memory usage, but that was expected.
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,164
Reaction score
1,500
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
He/Him
Regarding the Orbiter x64 core build process, which build target updates Orbiter.lib and Orbitersdk.lib in the output folder out\build\x64-Debug\Orbitersdk\lib?. (Or were those files just created when I extracted the D3D9 binaries package to get a graphics client working in x64?) When I do a "Rebuild All" for x64 Orbiter Debug, those libraries are not updated, although out\build\x64-Debug\Src\Orbiter\Orbiter_server.lib is. I could make symbolic links from out\build\x64-Debug\Orbitersdk\lib\Orbiter.lib -> out\build\x64-Debug\Src\Orbiter\Orbiter_server.lib, but I'm wondering what the "correct" way to handle this is.

As it is now with only Release versions of the Orbiter libraries in out\build\x64-Debug\Orbitersdk\lib, VS 2019 throws a link error when building XRSound x64 Debug because it tries to link Debug code with Orbiter library Release code:

2>orbitersdk.lib(Orbitersdk.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in ConfigFileParser.obj
2>orbitersdk.lib(Orbitersdk.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in ConfigFileParser.obj
2> Creating library D:\Orbiter_x64\orbiter\Sound\XRSound\XRSound\src\x64\Debug\XRSoundDLL.lib and object D:\Orbiter_x64\orbiter\Sound\XRSound\XRSound\src\x64\Debug\XRSoundDLL.exp
2>LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
2>D:\Orbiter_x64\orbiter\Sound\XRSound\XRSound\src\x64\Debug\XRSoundDLL.dll : fatal error LNK1319: 2 mismatches detected

If I build XRSound Release x64, everything works, because the Orbiter.lib and Orbitersdk.lib in that folder are Release versions.

So to sum up, what I'm trying to do is:
1. Rebuild all for Orbiter x64 Debug, which deploys to orbiter\out\build\x64-Debug.
2. Install D3D9 x64 graphics client (and associated binaries?) so that the x64 build has any graphics at all (or is there a way to run Orbiter with the default DX7 client in x64?).
3. Build and link XRSound Debug x64 and deploy/run that under orbiter\out\build\x64-Debug\Modules\Plugin\.

My "Orbiter root" folder is orbiter\out\build\x64-Debug. How are the rest of you running x64? I get the feeling I'm missing something. :)
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,408
Reaction score
342
Points
83
Website
orbit.medphys.ucl.ac.uk
When migrating the D3D9Client into the Orbiter repository what's gonna happen for the project history. For me it really doesn't matter. I am just asking if I should import the project history from SVN to Git or Not ?
I guess that is a question that is best answered by the people most involved in the D3D9client development - which is you and probably Kuddel. For me the code will essentially be a clean slate, so I will probably be less likely to dig into the history.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,408
Reaction score
342
Points
83
Website
orbit.medphys.ucl.ac.uk
For people annoyed with the Debug/Release subdirectories generated by the CMake VS generator, can I suggest to at least give the Ninja generator a try, just to check if this fixes your problem. I'll try to set out the workflow involved:
  • If you are using VS 2019, there is very little to do. CMake/Ninja is already integrated into the environment
    • Just open the source folder containing the root CMakeLists.txt file as a "local folder" into VS
    • Project | Configure Orbiter (or your own project)
    • Check the CMake settings and modify if required
    • Configure again
    • Build all
  • If you are not using VS 2019, you need the standalone CMake (which you probably have already), and the Ninja generator (which you may not have)
    • You can get Ninja here: https://ninja-build.org/
    • Once you have installed CMake and Ninja:
    • Open your VS command prompt (native x64 or x86, depending on what you want to build)
    • mkdir <build-directory>
    • cd <build-directory>
    • cmake-gui <source-directory>
    • Configure
    • Ninja generator | Use default native compilers
    • Edit parameters as required (e.g. CMAKE_BUILD_TYPE Debug or Release)
    • Configure again
    • Generate
    • Close cmake
    • From the command line inside the build directory: <path-to>\ninja.exe
This should build everything. You should build different configurations (x86/x64, Debug/Release) into different build directories, so you can keep these configurations in parallel without having to wipe and rebuild everything.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,408
Reaction score
342
Points
83
Website
orbit.medphys.ucl.ac.uk
Regarding the Orbiter x64 core build process, which build target updates Orbiter.lib and Orbitersdk.lib in the output folder out\build\x64-Debug\Orbitersdk\lib?. (Or were those files just created when I extracted the D3D9 binaries package to get a graphics client working in x64?)
There should be no Orbitersdk.lib in the build root folder. It should be built in <build-root>/Src/Orbitersdk/Orbitersdk.lib and deployed to <build-root>/Orbitersdk/lib
When I do a "Rebuild All" for x64 Orbiter Debug, those libraries are not updated, although out\build\x64-Debug\Src\Orbiter\Orbiter_server.lib is. I could make symbolic links from out\build\x64-Debug\Orbitersdk\lib\Orbiter.lib -> out\build\x64-Debug\Src\Orbiter\Orbiter_server.lib, but I'm wondering what the "correct" way to handle this is.
This should no longer be necessary with the latest main commit.
As it is now with only Release versions of the Orbiter libraries in out\build\x64-Debug\Orbitersdk\lib, VS 2019 throws a link error when building XRSound x64 Debug because it tries to link Debug code with Orbiter library Release code:
This is probably because I had to hard-code the XRsound build to Release. Hopefully that can be solved more elegantly.
If I build XRSound Release x64, everything works, because the Orbiter.lib and Orbitersdk.lib in that folder are Release versions.

So to sum up, what I'm trying to do is:
1. Rebuild all for Orbiter x64 Debug, which deploys to orbiter\out\build\x64-Debug.
2. Install D3D9 x64 graphics client (and associated binaries?) so that the x64 build has any graphics at all (or is there a way to run Orbiter with the default DX7 client in x64?).
3. Build and link XRSound Debug x64 and deploy/run that under orbiter\out\build\x64-Debug\Modules\Plugin\.

My "Orbiter root" folder is orbiter\out\build\x64-Debug. How are the rest of you running x64? I get the feeling I'm missing something. :)
My suggestion would be:
  • wipe the entire build directory to get rid of stale build fragments in the wrong places
  • pull the latest commits from main or trigger_sound_build branches
  • reconfigure and rebuild everything
Let me know if any of these issues remain, and I'll try to figure it out.
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
1,847
Reaction score
362
Points
83
Regarding D3D9Client repository move to git: I'm fine with using git in the future.
I would still wait some commits until the current subversion repository is worth the move.
It would be very nice if the history could be retained too (Although trunk/-only history does not include all details for merged "feature-branches" for example).
The other branches for Orbiter-2010 and -2016 however can be left out as they are "not working" for any revision of Orbiter available via git.
Future bugfixes for those "old" versions can be handled either via a separate git-repository (Jarmo's github?!) or left at subversion.

Just my thoughts, final decision authority has -of course- Jarmo! ;)
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
1,847
Reaction score
362
Points
83
@DarkWanderer : I was wondering as you did the "Adding x64 artifact to Actions build" PR...
is there a reason why not "Adding x86 artifact to Actions build", too?
The Orbiter-x64 artifact is currently the "thing to get", but still...
as Orbiter-x86 is build by the CI, the artifact would be nice to have, too.
 

N_Molson

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
8,884
Reaction score
2,638
Points
203
Location
Toulouse
This is amazing guys and goes beyond my wildest expectations, a revolution in the small Orbiter universe ! :hailprobe:
 

DarkWanderer

Active member
Orbiter Contributor
Donator
Joined
Apr 27, 2008
Messages
213
Reaction score
80
Points
43
Location
Moscow
@DarkWanderer : I was wondering as you did the "Adding x64 artifact to Actions build" PR...
is there a reason why not "Adding x86 artifact to Actions build", too?
The Orbiter-x64 artifact is currently the "thing to get", but still...
as Orbiter-x86 is build by the CI, the artifact would be nice to have, too.
Main concern is potentially running out of space for artifacts, which is why I didn't include them from start. I'm not sure what the limit is, @martins or @dbeachy1 will probably know, as GitHub "organisation" owners

In case there's enough space - it's trivial to do, here's a PR
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
1,847
Reaction score
362
Points
83
I was already expecting something like that. Thanks for the info!
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,408
Reaction score
342
Points
83
Website
orbit.medphys.ucl.ac.uk
I believe the storage limit for github actions for a free account (which is what I have) is 500MB. Since the 64-bit package artefact is already nearly 100MB, this means 5 packages before I run out of space. This is why I had the idea of each new package generated replacing the previous one. I guess this is not easy to implement, so the 7-day retention is a compromise, although at times of frenetic activity (as now) this will still easily overrun my quota. I don't know what happens if the quota is exceeded. Are the artefacts simply no longer stored? I hope github won't present me with a huge bill by the end of the month ;)
 

DarkWanderer

Active member
Orbiter Contributor
Donator
Joined
Apr 27, 2008
Messages
213
Reaction score
80
Points
43
Location
Moscow
If orbitersim organisation is not attached to your paid plan (if you have one), you will not get a bill, it will just start failing. If it is... Well, at least the bill should not be that huge;)

There is an action which in theory allows to keep "last N" builds, I'm trying it out on my fork. If it works, I'll PR cleanup+x86 builds to main repo
 

n72.75

Addon Developer
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,297
Reaction score
846
Points
128
Location
Biddeford ME
Website
mwhume.space
Preferred Pronouns
he/him
I believe the storage limit for github actions for a free account (which is what I have) is 500MB. Since the 64-bit package artefact is already nearly 100MB, this means 5 packages before I run out of space. This is why I had the idea of each new package generated replacing the previous one. I guess this is not easy to implement, so the 7-day retention is a compromise, although at times of frenetic activity (as now) this will still easily overrun my quota. I don't know what happens if the quota is exceeded. Are the artefacts simply no longer stored? I hope github won't present me with a huge bill by the end of the month ;)

NASSP has a little over 1200 releases, each weighing ~200MB. I'm not sure how that's working...but you might(?) not have anything to worry about.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,391
Reaction score
466
Points
83
Website
users.kymp.net
Regarding the problem with binaries ending up under "debug" or "release" sub-folders, this might help altough it's not perfect:

In the root CMakeList.txt

Makefile:
if (${CMAKE_GENERATOR} STREQUAL "Ninja")
    set(BIN_OUT_DIR RUNTIME_OUTPUT_DIRECTORY)
    set(LIB_OUT_DIR LIBRARY_OUTPUT_DIRECTORY)
else()
    set(BIN_OUT_DIR RUNTIME_OUTPUT_DIRECTORY_DEBUG)
    set(LIB_OUT_DIR LIBRARY_OUTPUT_DIRECTORY_DEBUG)
endif()


And for the other CMakeList.txt's

Makefile:
set_target_properties(Orbiter_server
        PROPERTIES
        LINK_FLAGS "/SUBSYSTEM:WINDOWS"
        ${BIN_OUT_DIR} ${ORBITER_BINARY_MODULE_DIR}/Server
        OUTPUT_NAME Orbiter
        VS_DEBUGGER_WORKING_DIRECTORY ${ORBITER_BINARY_ROOT_DIR}
        COMPILE_DEFINITIONS "NOGRAPHICS;DIRECTINPUT_VERSION=0x0800"
        FOLDER Core
    )

Any thoughts about this kind of approach ?
 

DarkWanderer

Active member
Orbiter Contributor
Donator
Joined
Apr 27, 2008
Messages
213
Reaction score
80
Points
43
Location
Moscow
FWIW, I'm using a CMakePresets.json file in the solution directory (PR), it allows to switch x86/x64 debug/release directly in Visual Studio without having to regenerate the solution. It doesn't have a problem with additional "Debug"\"Release" directory
1629052878880.png1629052900739.png

P.S. PR with x86 artifact is open - let me know your thoughts
 
Last edited:

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,164
Reaction score
1,500
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
He/Him
Today after I installed the version 16.11.1 VS 2019 update and went to open the Orbiter folder again, CMake appears to finish, but the Project and Build folders in VS 2019 remain disabled, with the menu option "Cancel CMake Cache Generation" stays enabled indefinitely. i.e., VS 2019 appears to think that CMake is still generating its cache, and so I can't configure or build the Orbiter project anymore. Here is the CMake log:

Code:
1> CMake generation started for configuration: 'x64-Debug'.
1> Found and using vcpkg toolchain file (D:/GitHub/vcpkg/scripts/buildsystems/vcpkg.cmake).
1> Command line: "C:\WINDOWS\system32\cmd.exe" /c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe"  -G "Ninja"  -DCMAKE_BUILD_TYPE:STRING="Debug" -DCMAKE_INSTALL_PREFIX:PATH="D:\GitHub\orbiter\out\install\x64-Debug" -DIRRKLANG_DIR:PATH="D:\irrKlang_x64" -DORBITER_MAKE_DOC:BOOL="False" -DCMAKE_C_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe" -DCMAKE_CXX_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe"  -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" -DCMAKE_TOOLCHAIN_FILE="D:/GitHub/vcpkg/scripts/buildsystems/vcpkg.cmake" "D:\GitHub\orbiter" 2>&1"
1> Working directory: D:\GitHub\orbiter\out\build\x64-Debug
1> [CMake] -- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
1> [CMake] -- Could NOT find LATEX (missing: LATEX_COMPILER)
1> [CMake] -- Configuring done
1> [CMake] -- Generating done
1> [CMake] -- Build files have been written to: D:/GitHub/orbiter/out/build/x64-Debug
1> Extracted CMake variables.
1> Extracted source files and headers.
1> Extracted code model.
1> Extracted toolchain configurations.
1> Extracted includes paths.
1> CMake generation finished.
...but the VS 2019 project menu is stuck showing this:

CMake hang_Screenshot 2021-08-17 125559.png

...and the Build menu only shows this:

build_menu_Screenshot 2021-08-17 165812.png

So then I tried deleting my Orbiter folder and doing a clean fetch -> opening the folder in Visual Studio, as before, but the same CMake hang results.

So, to sum up, here is what I tried:
  1. Delete old Orbiter folder.
  2. git clone [email protected]:mschweiger/orbiter.git to fetch clean Orbiter tree from GitHub.
  3. Open VS 2019 -> File -> Open Folder -> open Orbiter folder just fetched.
  4. CMake generates its cache and says "CMake generation finished", but I can't open CMake settings or build Orbiter because VS thinks that CMake cache generation is still in progress (see above screenshot). It hangs in this state indefinitely.
Is this still working for anyone else? This is proving to be frustrating...

I also tried running CMake manually from the command line, but that results in the "Debug" / "Release" problems mentioned above, and doesn't generate an installation folder than can run.

EDIT:
Enabling verbose logging for CMake in Tools -> Options -> CMake -> General, then setting "Never run configure step automatically", then enabling "Verbose internal diagnostic logging" shows this log when clicking Project -> Generate Cache:

Code:
14:14:45.2007294 [Info, Thread 71]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.ParseCache: ClearSingleConfigurationAsync: Clearing cache entry for CMakeLists.txt.
14:14:45.2007294 [Info, Thread 71]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.ParseCache: ClearSingleConfigurationAsync: Clearing cache entry for CMakeLists.txt.
14:14:45.2007294 [Info, Thread 71]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.ParseCache: ClearSingleConfigurationAsync: Clearing cache entry for CMakeLists.txt.
14:14:45.2207340 [Debug, Thread 114]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService: GetScanToken:    at Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService.GetScanToken(String root, Guid providerGuid)
   at Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService.<ScanContentAsync_Impl>d__50`1.MoveNext()
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)
   at Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService.ScanContentAsync_Impl[T](String fileToScan, CancellationToken cancelToken, Guid projectProvider, Boolean triggeredManually)
   at Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService.<RescanAsync_Impl>d__94.MoveNext()
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)
   at Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService.RescanAsync_Impl(String rootFile, Guid projectProvider, Boolean triggeredManually, CancellationToken cancelToken)
   at Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService.<>c__DisplayClass65_0.<<RescanAsync>b__0>d.MoveNext()
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.InvokeMoveNext(Object stateMachine)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.Run()
   at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(Action action, Boolean allowInlining, Task& currentTask)
   at System.Threading.Tasks.Task.FinishContinuations()
   at System.Threading.Tasks.Task.FinishStageThree()
   at System.Threading.Tasks.Task`1.TrySetResult(TResult result)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.SetResult(TResult result)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.SetResult(Task`1 completedTask)
   at Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.ParseCache.<ClearSingleConfigurationAsync>d__19.MoveNext()
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.InvokeMoveNext(Object stateMachine)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.Run()
   at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(Action action, Boolean allowInlining, Task& currentTask)
   at System.Threading.Tasks.Task.FinishContinuations()
   at System.Threading.Tasks.Task.FinishStageThree()
   at System.Threading.Tasks.Task`1.TrySetResult(TResult result)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.SetResult(TResult result)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.SetResult(Task`1 completedTask)
   at Microsoft.VisualStudio.VisualC.Logging.Logger.<LogNamedAsync>d__21.MoveNext()
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.InvokeMoveNext(Object stateMachine)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.Run()
   at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(Action action, Boolean allowInlining, Task& currentTask)
   at System.Threading.Tasks.Task.FinishContinuations()
   at System.Threading.Tasks.Task.FinishStageThree()
   at System.Threading.Tasks.Task`1.TrySetResult(TResult result)
   at System.Threading.Tasks.Task.WhenAllPromise.Invoke(Task completedTask)
   at System.Threading.Tasks.Task.FinishContinuations()
   at System.Threading.Tasks.Task.FinishStageThree()
   at System.Threading.Tasks.Task`1.TrySetResult(TResult result)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.SetResult(TResult result)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.SetResult(Task`1 completedTask)
   at Microsoft.VisualStudio.VisualC.Logging.PrefixFilterLoggerListener.<LogAsync>d__6.MoveNext()
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.InvokeMoveNext(Object stateMachine)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.Run()
   at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(Action action, Boolean allowInlining, Task& currentTask)
   at System.Threading.Tasks.Task.FinishContinuations()
   at System.Threading.Tasks.Task.FinishStageThree()
   at System.Threading.Tasks.Task`1.TrySetResult(TResult result)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.SetResult(TResult result)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.SetResult(Task`1 completedTask)
   at Microsoft.VisualStudio.VisualC.Logging.FileLoggerListener.<LogAsync>d__11.MoveNext()
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.InvokeMoveNext(Object stateMachine)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.Run()
   at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(Action action, Boolean allowInlining, Task& currentTask)
   at System.Threading.Tasks.Task.FinishContinuations()
   at System.Threading.Tasks.Task.FinishStageThree()
   at System.Threading.Tasks.Task`1.TrySetResult(TResult result)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.SetResult(TResult result)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.SetResult(Task`1 completedTask)
   at System.IO.StreamWriter.<WriteAsyncInternal>d__55.MoveNext()
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.InvokeMoveNext(Object stateMachine)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.Run()
   at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(Action action, Boolean allowInlining, Task& currentTask)
   at System.Threading.Tasks.Task.FinishContinuations()
   at System.Threading.Tasks.Task.FinishStageThree()
   at System.Threading.Tasks.Task`1.TrySetResult(TResult result)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.SetResult(TResult result)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.SetResult(Task`1 completedTask)
   at System.IO.StreamWriter.<FlushAsyncInternal>d__68.MoveNext()
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.InvokeMoveNext(Object stateMachine)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.Run()
   at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction(Action action, Boolean allowInlining, Task& currentTask)
   at System.Threading.Tasks.Task.FinishContinuations()
   at System.Threading.Tasks.Task.FinishStageThree()
   at System.Threading.Tasks.Task.FinishStageTwo()
   at System.Threading.Tasks.Task.Finish(Boolean bUserDelegateExecuted)
   at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot)
   at System.Threading.Tasks.Task.ExecuteEntry(Boolean bPreventDoubleExecution)
   at System.Threading.Tasks.Task.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

14:14:45.2217337 [Debug, Thread 114]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService: Getting Scan Token - scancount 8
14:14:45.2217337 [Info, Thread 114]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService: Scanner Parsing starting: projectfilepath CMakeLists.txt FileScanType: System.Collections.Generic.IReadOnlyDictionary`2[System.Type,System.Object] Config Name:x64-Debug (default)
14:14:45.2227341 [Warning, Thread 16]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.ParseCache: Skipping cache generation. Config not found: root:CMAKELISTS.TXTx64-Debug (default) CMakeLists.txt x64-Debug (default)
14:14:45.2257344 [Info, Thread 104]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService: Scanner Parsing done: projectfilepath CMakeLists.txt FileScanType: System.Collections.Generic.IReadOnlyDictionary`2[System.Type,System.Object] Config Name:x64-Debug (default)
14:14:45.2277350 [Info, Thread 15]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService: Compute file data values for CMakeLists.txt Config x64-Debug (default)
14:14:45.2297356 [Error, Thread 121]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService: FDV Error for CMakeLists.txt Config x64-Debug (default) Canceled False AutoGenerateCanceled False
14:14:45.2387376 [Info, Thread 99]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService: OnFileScannerCompleted for CMakeLists.txt
14:14:45.2217337 [Info, Thread 114]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService: Scanner Parsing starting: projectfilepath CMakeLists.txt FileScanType: System.Collections.Generic.IReadOnlyDictionary`2[System.Type,System.Object] Config Name:x64-Debug (default)
14:14:45.2227341 [Warning, Thread 16]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.ParseCache: Skipping cache generation. Config not found: root:CMAKELISTS.TXTx64-Debug (default) CMakeLists.txt x64-Debug (default)
14:14:45.2257344 [Info, Thread 104]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService: Scanner Parsing done: projectfilepath CMakeLists.txt FileScanType: System.Collections.Generic.IReadOnlyDictionary`2[System.Type,System.Object] Config Name:x64-Debug (default)
14:14:45.2277350 [Info, Thread 15]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService: Compute file data values for CMakeLists.txt Config x64-Debug (default)
14:14:45.2297356 [Error, Thread 121]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService: FDV Error for CMakeLists.txt Config x64-Debug (default) Canceled False AutoGenerateCanceled False
14:14:45.2387376 [Info, Thread 99]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService: OnFileScannerCompleted for CMakeLists.txt
14:14:45.2217337 [Info, Thread 114]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService: Scanner Parsing starting: projectfilepath CMakeLists.txt FileScanType: System.Collections.Generic.IReadOnlyDictionary`2[System.Type,System.Object] Config Name:x64-Debug (default)
14:14:45.2227341 [Warning, Thread 16]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.ParseCache: Skipping cache generation. Config not found: root:CMAKELISTS.TXTx64-Debug (default) CMakeLists.txt x64-Debug (default)
14:14:45.2257344 [Info, Thread 104]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService: Scanner Parsing done: projectfilepath CMakeLists.txt FileScanType: System.Collections.Generic.IReadOnlyDictionary`2[System.Type,System.Object] Config Name:x64-Debug (default)
14:14:45.2277350 [Info, Thread 15]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService: Compute file data values for CMakeLists.txt Config x64-Debug (default)
14:14:45.2297356 [Error, Thread 121]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService: FDV Error for CMakeLists.txt Config x64-Debug (default) Canceled False AutoGenerateCanceled False
14:14:45.2387376 [Info, Thread 99]    Microsoft.VisualStudio.Workspace.ExternalBuildFramework.Impl.Services.BuildProjectScannerService: OnFileScannerCompleted for CMakeLists.txt

Anyone know of another way to build a working Orbiter installation folder without using the CMake support built-in to VS 2019 (Ninja)? Or do any of you have a working solution & set of .vcxproj files you'd be willing to share that doesn't require CMake?
 
Last edited:

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,408
Reaction score
342
Points
83
Website
orbit.medphys.ucl.ac.uk
That doesn't sound good. I haven't yet upgraded to the 16.11.1 version, and maybe I should hold off for now.
I also tried running CMake manually from the command line, but that results in the "Debug" / "Release" problems mentioned above, and doesn't generate an installation folder than can run.
I just checked that, and while the build folder does have the Debug/Release subdirectory problems, my install folder is ok and does produce a working Orbiter setup. And if I build the D3D9Client in the install folder that seems to work too.

The only thing I usually change is the default install prefix, which CMake sets to C:\Program Files\Orbiter.

Just to be clear, by "install" I mean the target that CMake builds with the "CMakePredefinedTargets | INSTALL" project. Do you know what the problem is with your installation folder? Are there any files missing?
 
Top