ctru-rs-old
ctru-rs-old copied to clipboard
rust3ds
Use docker to enable CI builds
No idea what this entails, but it might be useful to have CI builds on PRs.
Not quite, unfortunately. This change (adding alloc_system to Cargo.toml) breaks the build according to Travis-CI. https://github.com/rust3ds/ctru-rs/commit/54d7fc6c88d8e884ed95bdefc3493b09e4e43573
It builds fine here, maybe retry the build (you can do that from within travis).
Wtf, it works fine locally and it breaks on travis. Devkit probably has nothing to do with it since it also built fine with the corresponding env vars unset.
Things seem to be working pretty well now. One suggestion I have though is that the compile-test should separately report success and failure for builds against the pinned nightly vs the latest nightly. If you check out my recent PRs, you'll see that the test reports all green even though there's actually breakage on the latest nightly. Ideally it should say 1 passed, 1 failed
@FenrirWolf If you'd prefer it that way, then just remove the matrix part from the .travis.yml.
I just figure that way we get a better heads-up about upcoming nightly breakage. Then when we fix it, we can re-pin a newer nightly, then wash, rinse, repeat.
Though if the idea is to not do frequent updates to the pinned nightly version, we can probably things the way they are. Just depends on what the goal is I suppose.
Just leaving a note as I tried to build a test executable for fun, and got these linker errors:
$ cargo 3ds test -vv --no-run --lib |& egrep -o 'undefined reference .+' | sort | uniq
undefined reference to `execvp'
undefined reference to `getpwuid_r'
undefined reference to `getuid'
undefined reference to `pipe'
undefined reference to `pthread_sigmask'
undefined reference to `sigemptyset'
undefined reference to `sysconf'
Some of these (particularly pipe + execvp, maybe pthread_sigmask and sigemptyset) seem tricky or maybe impossible for us to stub out, but I believe that would be the minimum set of other symbols we'd need to use the default test implementation. Perhaps using the custom test framework would require less work than shoehorning the existing test runner, but that feature is unstable with very little documentation, so I'm not really sure. Just another option to potentially consider.
If the custom test runner lets us use tests implemented for the default runner, there is no problem trying.
