Add GDK actions workflow #8847
Add GDK actions workflow #8847
Conversation
|
I think it's possible to cache paths in But when the cache fetching succeeds, you'd have to fixup the installation to let Visual Studio use the SDK. |
|
Can these scripts be used to cache something? |
So right now I’m using that install script, but other than some quick steps, it just calls the installer passing in /q /norestart, and that step is the one that takes forever. The other script can extract the MSIs pretty quickly, and then you end up with the loose files, but Visual Studio isn’t setup in that case. There is a CMake sample that has an option to build without installing using the ninja generator: in theory we could do something similar, but it seems a bit non-trivial to setup (especially since I’m not familiar with how all the SDL CMake scripts are setup). But conceivably, if we added that, then we could cache those extracted contents. |
|
Haven't dug into it yet but was forwarded this as a possible method of avoiding the installer times: https://github.com/microsoft/Xbox-GDK-Samples/blob/main/Samples/Tools/BWOIExample/readme_en-us.md |
|
Hmm, I had read through that before, but looking at it again makes me wonder if we can get the https://github.com/microsoft/Xbox-GDK-Samples/blob/main/Samples/Tools/BWOIExample/readme_en-us.md#building-in-a-windows-container part to work in actions? |
I just managed to get
Only (not-so-minor) problem is that I cannot get the test binaries to run.
These CMake scripts don't do much special. Am I correct when I say that the Gaming.Desktop.x64 platform only adds a few libraries + targets to run makepkg. |
|
@madebr The action in this PR was trying to do the "install", so I wouldn't be surprised if the approach of extracting the archive is way faster. The xgameruntime.lib and I can reproduce that "[GDK] Could not initialize - aborting" error if delete the MicrosoftGame.config file from the directory that has the sample exe. So my guess would be making sure that with the method you're using, that the post-build copy steps are running properly. For example, testsprite.vcxproj has the following copy rules: SDL/VisualC-GDK/tests/testsprite/testsprite.vcxproj Lines 301 to 328 in 89a4d9a And: SDL/VisualC-GDK/tests/testsprite/testsprite.vcxproj Lines 333 to 376 in 89a4d9a (And we could ignore all the Xbox ones for the purpose of CI, since that won't be possible to build through a public workflow as it requires an NDA install of GDKX) |
|
Update from the GDK side:
I assume it still downloads a lot but maybe it's less than the installer...? |
|
I got it working in the end. I haven't yet written a proper github action to do this automatically. |
|
About GDK, I noticed the executables require a |
|
AFAIK the only way to separate the executables with unique MicrosoftGame.config files is to change the OutputPath, but that will definitely complicate things that depend on BasePath... maybe for CI we should just run testautomation, or maybe treat it like UWP/ARM and do build testing only? |
|
@madebr Apologies for the ping, meant to ask: Do you have the working GDK action in a branch somewhere? Happy to throw the GPU branch at it! |
|
@flibitijibibo I haven't integrated it into ci yet, but I'll do that soon'ish. |
Your turn :) |
This adds a simple workflow that installs the currently supported version of (public) GDK and then builds for Windows GDK using the VisualC-GDK solution file.
I figure having a workflow might be helpful for cases where some SDL3 changes may introduce compile errors that are easy to fix. Annoyingly, the "Install GDK" step takes like 10-15 minutes. I don't think it's possible to cache that in actions since it installs somewhere in program files.