We discovered in SERVER-50852 that when unit test binary names do not
end with "_test" it can cause problems with the hang check analyzer. To
prevent such occurrences in the future, all CppUnitTest targets must
will be checked to ensure they are named correctly.
Allow Ninja to rebuild build.ninja any time a SCons tool or the compiler
is changed between iterative rebuilds. This change allows us to ensure
that we don't have any stale object files lying around that may have
been produced by an incompatible toolchain.
Allow Ninja to rebuild build.ninja any time a SCons tool or the compiler
is changed between iterative rebuilds. This change allows us to ensure
that we don't have any stale object files lying around that may have
been produced by an incompatible toolchain.
Some versions of ccache do not know how to handle clang's
-fsanitizer-blacklist flags. Some versions don't handle it at all, while
others only handle one instance, even though it can appear multiple
times on the command line. Because the argument can change the resulting
compiled object, not taking the flags into account properly can cause
ccache to pull an incorrect object file from its cache. The exact
behavior depends on the ccache version and how the arguments are changed
on the command line. We implement a workaround suggested by the ccache
developers until a newer version of ccache with all the required fixes
is in common use.
* Workaround ref: https://github.com/ccache/ccache/issues/174
If CCACHE or ICECC are specified on the SCons command line but the paths
given don't exist, the associated tool would simply be skipped. This
caused confusion when users were expecting the tool to run and the
compile would proceed without it. Now specifying an incorrect path to
the tool will cause a configure failure.
Before this point, remote builds did not work because Icecream did not
copy sanitizer blacklist files to the remote hosts. We had a check in
place that silently turned Icecream builds with sanitizers into local
builds. Now we build the sanitizer blacklist files into the environment
tarball that Icecream uses for remote builds.
A bug spotted in Icecream 1.2+ can cause build failures when building
with gcc. This is, in turn, due to a bug in GCC where the preprocessor
executed via `gcc -E` has different behavior than the one used
internally during compilation. We are working with Icecream, and GCC
to address these problems. For now, we work around the bugs.
* GCC bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88475
* Icecream bug report: icecc/icecream#550
A bug spotted in Icecream 1.2+ can cause build failures when building
with gcc. This is, in turn, due to a bug in GCC where the preprocessor
executed via `gcc -E` has different behavior than the one used
internally during compilation. We are working with Icecream, and GCC
to address these problems. For now, we work around the bugs.
* GCC bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88475
* Icecream bug report: https://github.com/icecc/icecream/issues/550
If any environment variable (including PATH) were to somehow make its
way into your build.ninja, it would cause build failures due to the fact
that the shell splits it into separate arguments. This can happen
sometimes especially on OSX, where the PATHOSX environment variable gets
(incorrectly) copied by SCons into the current build environment.
Regardless of whatever SCons should be doing, we will quote environment
variable values in Ninja builds to ensure it doesn't happen again.
Some compiler flags passed in from the environment can cause icecc to
only build locally because the compiler gives an error saying the flag
is not supported. It may also have been causing problems with using
ccache in general. There may be other negative behaviors that we don't
know of that haven't been reported yet. This wasn't a problem in the
older Ninja build system, but it is in the newer one.
