Add GitHub actions build (WIP)

[Shayan-To]

This works partially:

For Ubuntu, it builds, but packaging does not work.

For Windows, I got stuck getting a build. I couldn't figure out how I should get the libraries for cross-compiling on Ubuntu. So I tried building on msys2 on Windows, and scons cannot find anything. I think it is looking for things in the wrong places. And for some reason, the behavior on GitHub actions is different from the behavior on my local machine.

(I did this some time ago. In fact, I think I've forgotten what I was doing... And sorry for the commit messages! I think we should squash them, so I didn't touch anything.)

[Quipyowert2]

I just opened pull request #82 that fixes the build breakage caused because I added a variable Screen::scrollWheelEnabled but forgot to test that the server configuration builds when I added that variable. Now Ubuntu 20.04 should be able to build correctly with server = True set in options_cache.py which defines the YOG_SERVER_ONLY macro.

If you look closely at the include lines in the Windows msys2 build, they seem to be two paths concatenated together for some reason. The include arguments I'm talking about are -Ibuild/libgag/src/D:/a/_temp/msys64/mingw64/include/SDL2 -Ilibgag/src/D:/a/_temp/msys64/mingw64/include/SDL2 which should probably be -ID:/a/_temp/msys64/mingw64/include/SDL2. I'm not sure why this happens; it could be a bug in either SCons or the Sconstruct/SConscript build scripts. Changing the last line under the Windows-Build: heading to echo 'mingw = True' >> options_cache.py && scons -j16 might fix the Windows build.

If this gets merged, it can be used as a fallback if Travis-CI goes down and Travis-CI can still build even if GitHub Actions has a problem in the future. If GitHub itself goes down, well, that could be a problem since the SourceForge mirror hasn't been updated in quite some time.

The Ubuntu 22.04 build is failing because the file debian/compat which specifies the lowest compatible debhelper version has a 6. Ubuntu 22.04 debhelper only supports a compatibility level of 7 or higher, which can be done by adding echo '7' > debian/compat before the scons command in the Ubuntu-Build: section.

[Shayan-To]

@Quipyowert2 I rebased my changes on the latest master, and applied your suggestion for the Windows build.

The issue on Windows side still remains the same, and the error on Ubuntu side is beyond my understanding! (Link to action run)

[Quipyowert2]

Sorry, it's my fault the PR failing to build in Ubuntu 20.04 and 22.04. In PR #78, I changed the #ifdef on the line in TextStream.cpp following the line moved by the 03_headers_order patch. PR #97 should fix the Ubuntu build.

The build failure in the Windows build seems to be an include path problem. I am not sure why SCons smashes the paths together like that. The include argument -Ibuild/libgag/src/C:/msys/1.0/local/include should probably be two separate includes like this: -Ibuild/libgag/src/ -IC:/msys/1.0/local/include. The part of the code causing the problem could possibly be the env.Append calls in the top level SConstruct at line 262 or might be a bug in SCons, like I said in an earlier comment.

In the Windows section of the YAML file, if you instead put mingw64/mingw-w64-x86_64-scons in the list of stuff to install in the MSYS2 environment rather than msys2/scons, does that get past the SDL.h: no such file or directory error?

Note: With SCons 4.4.1, you might have to apply either of the following patches to Glob2 and SCons to build on Windows: SConstruct-changes-for-msys2.patch, Patch for SCons itself.

@stephanemagnenat Do you know how to fix the Windows build in this pull request?