In futures 0.1.15, the boxed() method on Future structs was
deprecated. This returned a BoxFuture type which had to be
declared either Send or 'static while wrapping a Future
in Box::new() allows inference of the appropriate trait bounds.
We already don't use the BoxFuture trait, so just call Box::new()
directly instead to avoid the deprecation warning and make it
easier to port to future releases.
See also https://github.com/alexcrichton/futures-rs/issues/228
Increasingly, compilers are integrating with the preprocessor in such a
way that they know some things expanded from the preprocessor don't need
to be warned about. Consequently, this leads to compiling from the
preprocessor output to usually contain a lot of warning noise, that far
outweigh the benefit of compiling from the preprocessor output.
Even worse, in the case of recent GCC, with -fprofile-generate (cached),
this leads to -Wcoverage-mismatch warnings during the -fprofile-use
(not cached) phase.
Also, it has been necessary to implement a "retry" strategy when the
compilation from the preprocessor output fails, and it's not clear we're
not doing that a lot anyways.
As this changes the warnings output, which is part of the cache, we
bump the cache version.
Amazon updated their S3 pricing recently and now standard storage is now cheaper
than reduced redundancy storage. They're trying to phase out reduced redundancy
and so they didn't bother lowering the RR price. In light of that we should just
use standard storage for sccache cache entries.
Running sccache in Jenkins jobs without any virtualization may cause
problems if sccache is not configured properly. This notes tries to
explain this topic and offers two possible solutions for a problem that
occoured in a real world CI setup.
First and foremost, to generically convey the type of compilation, we
normalize the file extension, and will use that information to feed
the right -x argument to the preprocessor and compiler.
When the compiler command sccache is invoked with already contains a -x
argument, we set the normalized file extension accordingly, such that
it matches what the caller wants, rather than what the source file
extension says.
On the preprocessor end, we then always pass one of `-x c`, `-x c++`,
`-x objective-c` or `-x objective-c++` according to the normalized file
extension.
On the compiler end, we always pass one of `-x cpp-output`, `-x
c++-cpp-output`, `-x objective-c-cpp-output` or `-x
objective-c++-cpp-output` accordingly.
Note that we used to pass `-x objc-cpp-output` to gcc, but that's a
deprecated form that it now warns about. The new form has been available
since at least gcc 4.3, so is fine to use.
And because a same source compiled as C or C++ will yield different
object code, include the normalized extension when computing the hashed
value.
Fixes#163.
Each compiler essentially had its own, rather minimalist, argument handling.
It didn't allow to fully handle the vast breadth of arguments that
compilers can take, and wouldn't allow to find out which arguments are
related to preprocessing, and which aren't. Furthermore, gcc-type
arguments are very lax, and allow things like "-includefile" and
"-include file" to mean the same thing, making things even harder.
And then there's rust, that allows "--emit=dep-info" and "--emit dep-info"
to mean the same thing.
We introduce a new generic API that can handle all sorts of arguments,
based on flat descriptions of the arguments that can be handled, and
proceed with defining more of the arguments that the various compilers
support.
While the argument list for gcc/clang is rather exhaustive, it is still
based on a combination of what ccache handles, and what sccache used to
handle, and might still miss some of the arguments that can take values.
The argument list for msvc is not exhaustive and might need some
improvement. For instance, I haven't actually checked whether some of
the arguments allow non-concatenated forms.
While the default is reasonable for developers, CI environment may want
to choose larger timeouts, or to disable it entirely.
The new SCCACHE_IDLE_TIMEOUT environment variable allows to pass a value
in seconds for the idle timeout before shutdown, and a value of 0
disables the timeout entirely.
When the original compiler invocation contains -include, passing the
flag to the compiler invocation for the preprocessed source can lead to
errors because it will cause another pass of the preprocessor (although
arguably, with -x cpp-output, it shouldn't).
Ideally, other flags like -I, -idirafter, etc. should be handled the
same, but there are other issues that should be addressed for those
(as well as -include, but this addresses the most immediate issue)
See https://github.com/mozilla/sccache/issues/117#issuecomment-315569559Fixes#117
When the compiler is invoked for linkage, the command line usually comes
with multiple input arguments. It's confusing that sccache tells that
something is not cached because of the number of input arguments when it
wouldn't cache anyways because it's not a compilation in the first
place.
re-compiling when the first compile fails with -Werror.
People have been seeing this in try pushes where their code is failing to
compile, but instead of getting the compiler error they get a GCC error because
we're passing it bad commandline arguments. We weren't treating -MP as a
preprocessor argument, and we also weren't passing preprocessor arguments
to the compiler when we retry compilation from the source if it fails
with -Werror compiling from the preprocessed source.
This is a regression because we didn't used to retry compilation on failures
with -Werror with gcc, and clang doesn't produce this error in this situation.
The serde_json crate is always needed by src/commands.rs even when
building only with support for Redis, but serde_json would be left
out when the S3 feature is disabled. This make it possible to build
sccache only with Redis support.
Building with S3 disabled trims down a stripped release build from
5.1 MiB down to 4.4 MiB on x86_64.
The MSDN docs for WideCharToMultiByte say:
"WC_ERR_INVALID_CHARS - ... Note that this flag only applies when CodePage is
specified as CP_UTF8 or 54936 (for Windows Vista and later). It cannot be used
with other code page values."
https://msdn.microsoft.com/en-us/library/windows/desktop/dd374130(v=vs.85).aspx
We're currently getting ERROR_INVALID_FLAGS here. I've also added a test
that -deps works for MSVC which catches this error.
Ralph Giles
Alex Crichton
Ted Mielczarek
Mike Hommey
Felix Obenhuber
Adrian Perez de Castro
Taylor Cramer
Ralph Giles
Andre Parodi
F3real
Tetsuharu OHZEKI