On 25 March 2017 at 02:24, Brett Cannon <brett@python.org> wrote:
Another option is if we drop a compiler from a debug build we can use it for the coverage run so it's at least being exercised somewhere.
If we drop either compiler I would vote for dropping gcc actually as the compiler messages are much worse on gcc compared to clang. I guess it comes down to whether we think CI should be used as a fallback for a failing test suite or if we think CI might help contributors if they happen to have a bug in their C code that they simply didn't notice (e.g. thought they made an innocuous fix that didn't warrant a rebuild).
Catching "forgot to run make before running the tests" is a useful role, but in that case I'd expect most folks to go "oops" and do a local build, rather than trying to debug compile errors solely from the CI logs (except for the cross-platform case, where something works on Windows but not on *nix, and vice-versa).
However, from the point of view of making it easier for Windows devs to debug *nix debug errors, it probably makes more sense to use clang for the main *nix test run, and then use gcc to do the coverage run.
That setup would give:
- all 3 default compilers running in CI (MSVC in Appveyor, clang for the main Travis tests, gcc for the coverage run)
- Windows devs getting the friendlier clang error messages when they're trying to debug a cross-platform compilation problem
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia