I've gone ahead and dropped the gcc test build and switched the coverage test to gcc. If we find in time that clang's speed is really an issue compared to its better error messages we can swap the compilers' roles.

On Sun, 26 Mar 2017 at 04:31 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 26 March 2017 at 03:54, Antoine Pitrou <antoine@python.org> wrote:
>
> Le 25/03/2017 à 16:27, Nick Coghlan a écrit :
>>
>> 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.
>
> What's the problem exactly? Situations where MSVC is more lenient than
> either gcc or clang? Usually it's the reverse :-)

I'm mainly thinking of situations where the Windows way of doing
something is different from the *nix way of doing it (e.g. I hit one
in the other direction recently, where setenv becomes something like
SetEnvironmentVarW on the Windows side of things).

While those are generally pretty straightforward complaints about
undefined symbols, it doesn't hurt to favour the compiler that's known
for easier to read messages.

Cheers,
Nick.



--
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia