[Proposal] Build static SDL2 (software renderer) binary with Travis CI #19
Comments
|
I've actually been thinking on-and-off about adding some sort of CI system for a while, so this is definitely on the radar. I'm not sure if we'd want to explicitly use the SDL2 software renderer — if we need something that can run on a headless system, the ideal thing would be to get the id_{vl,in,sd}_null backends working — but the idea of being able to run some tests (e.g., run through the demos mand make sure they produce the same outputs) could be neat. (It'd need the data files, though, which could be problematic.) But it'd certainly save me some time to just have it automatically build for a few Linux archs, as well as windows and maybe DOS. I'll see if I can find some time to look into it. |
As mentioned in issue #19, it'd be nice to have some sort of CI system with which to confirm that pull requests and pushes actually build correctly. This is a first step towards doing this, using GitHub actions to build Omnispeak on the latest Ubuntu, with all options set to default. If this works, I'll look into extending it to build the other versions, which is where it's likely to cause the most problems. But this simple test should be better than nothing. Ultimately, we'll want to actually test the compiled binary, using eith the id_{cl,in,sd}_null backends or something like the SDL software rasteriser. One thought is to have a set of demos and dumps which we can easily compare.
|
I've put some basic CI integration in. I'm using GitHub's builtin "actions" system rather than Travis CI, which wanted a few more permissions on my account than I can give out at the moment, but the basics work. All new commits or pull requests should now be built on Windows (both Win32 and Win64), Linux, and DOS, and the compiled versions will be available to download as artefacts. Note that there's no testing of the builds (if it compiles, it's considered okay), only the default renderer for each platform is compiled, and there's none of the nice packaging that a full release would want to do (the Linux version isn't compiled to be compatible, the dos version needs CWSDPMI to be copied in manually, no README or data files are included). |
|
Nice one. I was suggesting Travis CI from the onset because I was thinking about building / testing against PowerPC64LE platform which AFIAK only available with Travis CI. |
|
FYI: I've quickly hacked a cross-compiler check for ppc64 (big-endian) into the CI system. It's not as useful as a proper SDL build, nor does it do all of the testing yet, but it's a start. :-) Ideally, this should at least start to catch build failures with non-x86 systems. (I develop mostly on x86, x86-64 and occasionally aarch64 here.) |
Travis CI is a popular CI with support for wide range of platforms and integrations. I have seen many projects utilise CI to build and deploy those binaries to artifacts placeholders. This would help projects save time on making new releases.
The text was updated successfully, but these errors were encountered: