ratchet up travis to build stage1 #27028
Conversation
|
is there any way to turn on |
| script: | ||
| - make tidy | ||
| - make rustc-stage1 -j8 |
There was a problem hiding this comment.
travis build machines have 2 cores, i think you want -j2 here
There was a problem hiding this comment.
Is there a negative impact of giving too big of a number? In my experience you just don't gain anything.
There was a problem hiding this comment.
I'd expect the normal context switching cost. Maybe worth testing?
On Jul 14, 2015 11:19 AM, "Alexis Beingessner" [email protected]
wrote:
In .travis.yml
#27028 (comment):script:
- make tidy
- make rustc-stage1 -j8
Is there a negative impact of giving too big of a number? In my experience
you just don't gain anything.—
Reply to this email directly or view it on GitHub
https://github.com/rust-lang/rust/pull/27028/files#r34579851.
There was a problem hiding this comment.
Typically too much saturation can lead to a decrease in build times, this may want to be ratcheted down to -j4 instead of 8
|
I'm also somewhat dubious that ccache is being used, and it would probably be very nice to enable it. I think a 42 minute build with ccache enabled is definitely indicative of something going wrong. The logs for this PR show a failure to upload an archive about the cache, so maybe that helps diagnose? |
|
Yeah sometimes it just fails. The logs I linked at the top of the PR show a completely successful load/save with no difference. |
This worries me that we may not be actually using ccache at all. If it's correctly saving/restoring and actually using Perhaps try adding |
|
I ran ccache -s on the last run and can confirm ccache wasn't even touched. Also, upon closer inspection it looks like the cache is PR-local regardless:
So every PR will take 40 minutes regardless. On subsequent pushes it can potentially go faster, though this is clearly not happening. |
|
It works!!!!!!!!!!!! LLVM is built before travis makes it to 6 minutes now. I had to hack up In addition, I was mistaken about how the cache works. The docs seem to suggest that any PR posted against master will try to grab master's cache on the first build. |
| - ./configure --llvm-root=path/to/nowhere | ||
| - ./configure --enable-ccache | ||
| - cat config.mk | ||
| - which ccache |
There was a problem hiding this comment.
This, cat config.mk, and ccache -s can probably be removed
|
Looks like |
|
This is a huge win |
|
Setting |
Tidy is still run first for failing fast on the easy stuff. To accomplish this we have travis actually persist ccache across builds. This has LLVM built within 6 minutes, and all of stage1 built within 18. Caching should work on fresh PRs (cache acquired from the master branch). Because all we persist is ccache, there is minimal danger of persisting corrupt build state. I had to mangle `configure` a bit to make --enable-ccache work when custom compilers are provide via CC and CXX.
| language: c | ||
| compiler: /usr/bin/gcc-4.7 |
There was a problem hiding this comment.
as an alternative to this, is travis' clang recent enough to compile llvm?
There was a problem hiding this comment.
I am a big fan of trying to make this as vanilla as possible. Historically anything really custom has caused travis to spuriously break (e.g. check-stage-1)
There was a problem hiding this comment.
I don't follow. I only meant to ask: would the following work (out of the box)?
language: c++
compiler: clang
There was a problem hiding this comment.
Ah, I had been scared away from trying clang due to existence of --enable-clang flags and previous nasty hacks surrounding clang and travis in the past. However it's worth a try.
There was a problem hiding this comment.
😿 looks like it's clang 3.4 which also doesn't support c++11. thanks for trying it.
|
@bors: rollup |
This has travis build LLVM and rustc up to stage1, but not run any tests. It seems wasteful to have the ultimate might of travis running on every PR just to check for whitespace errors. This is a pure subset of the bootstrap, so it shouldn't ever spuriously break. `make tidy` still runs first, so we still get \"fast errors\" on bad style. However once make tidy passes, the build will simply keep running to try to make rustc. `tidy` takes ~3 mins to complete, so if your build runs longer you can be confident we've gone on to build LLVM/rustc. In principle this is configured to use ccache (it shows up in the build logs as uploaded/downloaded), but I found no actual performance changes in using it. Maybe someone at @travis-ci knows what's up with that. For reference, here is a successful build with ccache enabled: https://travis-ci.org/Gankro/rust/builds/70821237 and one without: https://travis-ci.org/Gankro/rust/builds/70812814 Builds seem to take about 41mins regardless. r? @alexcrichton
This has travis build LLVM and rustc up to stage1, but not run any tests. It seems wasteful to have the ultimate might of travis running on every PR just to check for whitespace errors. This is a pure subset of the bootstrap, so it shouldn't ever spuriously break.
make tidystill runs first, so we still get "fast errors" on bad style. However once make tidy passes, the build will simply keep running to try to make rustc.tidytakes ~3 mins to complete, so if your build runs longer you can be confident we've gone on to build LLVM/rustc. In principle this is configured to use ccache (it shows up in the build logs as uploaded/downloaded), but I found no actual performance changes in using it.Maybe someone at @travis-ci knows what's up with that.
For reference, here is a successful build with ccache enabled: https://travis-ci.org/Gankro/rust/builds/70821237
and one without: https://travis-ci.org/Gankro/rust/builds/70812814
Builds seem to take about 41mins regardless.
r? @alexcrichton