Home Original page

[python-committers] Is clang testing necessary?

Nick Coghlan ncoghlan at gmail.com
Sat Mar 25 11:27:44 EDT 2017 
On 25 March 2017 at 02:24, Brett Cannon <brett at 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 at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170326/c0622bea/attachment.html>
More information about the python-committers mailing list