On Fri, 24 Mar 2017 at 06:43 Antoine Pitrou <[email protected]> wrote:
> > Hello, > > I am curious about the decision to have Travis-CI tests with both clang > and gcc. It was when I was trying to maximize Travis usefulness before the migration. It's also because we as a project have found bugs in both compilers previously (I know I personally reported a bug that affected both of them once upstream). > clang is a compiler which strives to be very compatible with > gcc. I would understand testing under OS X with clang in addition to > Linux with gcc, but I'm skeptical we gain much from testing both gcc and > clang under Linux. Also, it lengthens CI times, as clang produces > slower code in debug mode than gcc does (because we use "-Og" on gcc). > Is there an equivalent flag for clang we should be using? > > Or perhaps we could switch the clang build to produce a non-debug > interpreter (and therefore a faster test suite)? > 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).
_______________________________________________ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
