-
-
Notifications
You must be signed in to change notification settings - Fork 60
Drop the gcc build from Travis #46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This would make @1st1 happy. 😉 |
I think 3 can be merged into 1 easily, too. |
I created python/cpython#697 to try out the 1+3 idea. |
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. |
Created python/cpython#853 to try dropping the gcc build. |
We currently have 5 builds on Travis:
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?
The text was updated successfully, but these errors were encountered: