godotengine
CI: Cross-compile Windows build with mingw
Currently the setup-godot-cpp actions install MinGW but then the scons command doesn't have use_mingw=yes set. This seems like a waste of time. At the last meeting we agreed that it would be a better idea to switch from MSVC to MinGW since binaries are said to have better performance and Link Time Optimizations can be enabled.
Just use_mingw=yes works but with lto=auto it fails.. Can someone diagnose this?
https://github.com/unvermuthet/godot-cpp-template/actions/runs/13672331130/job/38225569652
This can be fixed by cross-compiling on ubuntu-22.04. There the LTO works.
I personally think switching to cross-compiling is acceptable. It may even run faster on CI.
Let's get some more input on this. In the meeting someone suggested that cross-compiling would not play well with running tests for Windows. Was that Enetheru? I didn't quite understand it.
Oh, I suppose if you wanted to run the Windows build in some automated tests, you'd need to be on a Windows runner to do that. But there's no reason you can't cross-compile for Windows, and then if you want to do tests, have a follow-up job that downloads the artifacts and runs them
That's what I do for my project. There is a test job that downloads the merged build artifact, downloads Godot and runs GUT integration tests (Does anyone know of an existing action for this?). You would have to do this on a separate matrix because of the cross-compilation, so that you can actually set windows-latest as the runner os, but I doubt that you'd wanna test every build that's made so a separate smaller matrix sounds reasonable.
That's what I do for my project. There is a test job that downloads the merged build artifact, downloads Godot and runs GUT integration tests (Does anyone know of an existing action for this?)
I'm using the action abarichello/godot-ci for this. I haven't used GUT but I'm imagining it would be possible to run unit tests with a CLI command from there.
It might be worth it to expand the template with at least some boilerplate for this if we go for cross-compilation, but that can be done in another PR.
Well right now there is no boilerplate for testing at all, right? It's really good to have for extension development. But I could also see it as bloat for people trying to make their game logic, and could be considered out of scope for CI on this.
What do you imagine under boilerplate?
could be considered out of scope for CI on this.
Yep, let's postpone that for another PR. It doesn't have to be added now :)
What do you imagine under boilerplate?
I was imagining a short "unit test" per dev OS that runs after the builds run, just one that runs godot and checks if a certain scene crashes. But arguably that's out of scope for godot-cpp-template. Either way should be separately discussed.
Perhaps on "auto". I'd generally be in favor, because then people who don't know what it is could profit from it. But it's not well suited for CI, only for release builds. Maybe that's good to discuss in a meeting.
EDIT: should have kept reading before replying.. nvm.
Let's get some more input on this. In the meeting someone suggested that cross-compiling would not play well with running tests for Windows. Was that Enetheru? I didn't quite understand it.
Not me, but since you mentioned it, how can you test if the system is not the same as the binary you are building for? except by saving artifacts and then loading up a test runner separately that is the correct system?
You could programmatically determine the correct testing OS by setting it according to the ‘target.platform’ parameter, or pass in an extra testing OS parameter into the matrix. Sadly even then, you still wouldn’t be able to change the OS within a job. A separate job and matrix that downloads the artifact is the only way I see.