| Age | Commit message (Collapse) | Author | Lines |
|
This commit disables building documentation on cross-compiled compilers, for
example ARM/MIPS/PowerPC/etc. Currently I believe we're not getting much use out
of these documentation artifacts and they often take 10-15 minutes total to
build as it requires building rustdoc/rustbook and then also generating all the
documentation, especially for the reference and the book itself.
In an effort to cut down on the amount of work that we're doing on dist CI
builders in light of recent timeouts this was some relatively low hanging fruit
to cut which in theory won't have much impact on the ecosystem in the hopes that
the documentation isn't used too heavily anyway.
While initial analysis in #48827 showed only shaving 5 minutes off local builds
the same 5 minute conclusion was drawn from #48826 which ended up having nearly
a half-hour impact on the bots. In that sense I'm hoping that we can land this
and test out what happens on CI to see how it affects timing.
Note that all tier 1 platforms, Windows, Mac, and Linux, will continue to
generate documentation.
|
|
These arguments are passed to the relevant x.py invocation in all cases
anyway. As such, there is no need to separately configure them. x.py
will ignore the configuration when they are passed on the command line
anyway.
|
|
Looks like the clang with 16.04 fails to compile LLVM 6, but it looks like clang
in 18.04 can indeed compile LLVM 6.
|
|
The main goal here is to use FreeBSD's normal libc++, instead of
statically linking the libstdc++ packaged with GCC, because that
libstdc++ has bugs that cause rustc to deadlock inside LLVM.
But the easiest way to use libc++ is to switch the build from GCC to
Clang, and the Clang package in the Ubuntu image already knows how to
cross-compile (given a sysroot and preferably cross-binutils), so the
toolchain script now uses that instead of building a custom compiler.
This also de-duplicates the `build-toolchain.sh` script.
|
|
On some systems, the bash command could be available in another
directory than /bin. As such, to offer an env shebang is more
convenient.
This make sense even for docker scripts, as you can use Docker
on FreeBSD or SmartOS for example.
|
|
Newer versions of Docker have a `--init` argument which spawns an init process
in the container, which we should be able to use everywhere now.
|
|
When working through bugs for the LLVM 5.0 upgrade it looks like the FreeBSD
cross compilers we're currently using are unable to build LLVM, failing with
references to the function `std::to_string` claiming it doesn't exist. I don't
actually know what this function is, but assuming that it was added in a more
recent version of a C++ standard I've updated the gcc versions for the
toolchains we're using. This made the error go away!
|
|
|
|
|
|
This commit updates the sccache binaries to fix a cache load failure seen
on #41926, fixed by mozilla/sccache#119
|
|
Pulls in mozilla/sccache@ef0d77543 to fix #40240 again after the builds included
in #41447 forgot to include the mio fixed included in #41076.
Closes #40240
|
|
Now that the final bug fixes have been merged into sccache we can start
leveraging sccache on the MSVC builders on AppVeyor instead of relying on the
ad-hoc caching strategy of trigger files and whatnot.
|
|
This build is no longer a forked version with temporary bugfixes, everything
should be upstreamed!
|
|
I've tracked down what I believe is the last spurious sccache failure on #40240
to behavior in mio (carllerche/mio#583), and this commit updates the binaries to
a version which has that fix incorporated.
|
|
Previously we would use one builder on Travis to produce two sets of host
compilers for two different targets. Unfortunately though we've recently
increased how much we're building for each target so this is starting to take
unnecessarily long (#40804). This commit splits the dist builders in two by
ensuring that we only dist one target on each builder, which should take a much
shorter amount of time. This should also unblock other work such as landing the
RLS (#40584).
|