On 25 March 2017 at 02:24, Brett Cannon <br...@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 | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/