You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not willing to drop 1, 4, or 5. Perhaps we should drop the gcc build as redundant next to clang and let any gcc buildbots acts as our fallback in case we hit a weird compatibility issue?
So my idea of dropping the C++ header check failed due to $CXX not being exported under the "c" language option in Travis. That slipped into being checked in even though it failed due to the checks of what was changed thought a change to .travis.yml didn't warrant running the test suite.
I'm pointing this out here in case gcc or any other Travis change occurs where the test suite needs to run. Best option is to probably disable the check for whether the suite needs to run and then after it has been fully verified to put the check back to where it was.
An idea that I had from a discussion in python/cpython#743 is we could roll the gcc build into the coverage run. IOW we keep clang for the testing build but use gcc for the coverage build. While failures in the coverage run won't trigger a blocking failure, it will still at least be visible.
Activity
brettcannon commentedon Mar 16, 2017
This would make @1st1 happy. 😉
methane commentedon Mar 17, 2017
I think 3 can be merged into 1 easily, too.
brettcannon commentedon Mar 17, 2017
I created python/cpython#697 to try out the 1+3 idea.
brettcannon commentedon Mar 19, 2017
So my idea of dropping the C++ header check failed due to $CXX not being exported under the "c" language option in Travis. That slipped into being checked in even though it failed due to the checks of what was changed thought a change to .travis.yml didn't warrant running the test suite.
I'm pointing this out here in case gcc or any other Travis change occurs where the test suite needs to run. Best option is to probably disable the check for whether the suite needs to run and then after it has been fully verified to put the check back to where it was.
brettcannon commentedon Mar 21, 2017
An idea that I had from a discussion in python/cpython#743 is we could roll the gcc build into the coverage run. IOW we keep clang for the testing build but use gcc for the coverage build. While failures in the coverage run won't trigger a blocking failure, it will still at least be visible.
brettcannon commentedon Mar 27, 2017
Created python/cpython#853 to try dropping the gcc build.