The current state of python configure sandbox execution is that if a
template imports a module, and a function defined in the template tries
to use the module, it doesn't work. Ideally, it would, but rather than
try to fix this corner case, we remove the unit tests that assume it
works (and consequently pass for half bad reasons), and add a unit test
so that the behavior doesn't change unwillingly.
--HG--
extra : rebase_source : 579ba2bc7c19d4fe7df11bbdb1ceb6171a1ee857
Also allow when=True/False to avoid the chicken-egg problem of using
a generic `when` to use in replacement of @depends('--help') for things
like @dependable.
--HG--
extra : rebase_source : f1571a5b904efb66a361b90f3b7e1edbaa75772e
--help dependencies currently help identify functions that will run when
running configure --help, which we don't want to have spreading too
much. OTOH, when such functions have no side effect, it's not really
that important to have them explicitly marked.
So, allow missing --help dependencies for functions that:
- don't use @imports
- don't have a closure
- don't use global variables
This is a first step towards entirely removing the --help markings (the
end goal being that --help dependencies will indicate actual --help
dependencies). As such, we don't really care about updating the lint
error message.
--HG--
extra : rebase_source : e81ec9b51ff01c2ee75722904e551286aa0b2bec
We want functions without an @imports to not have any side effects, and
to not use external resources. So remove the few functions we expose from
os.path without @imports('os') that do.
--HG--
extra : rebase_source : a9485ec269d4de5785d66d7772eda4fae5a84b4a
Missing such dependencies shouldn't impair running configure itself
after local modifications, but they are currently required for
(mostly) documentation purpose. Which means they are better done in
the linter.
--HG--
extra : rebase_source : 6bfff2342cda2ed1351f561c9eb9623f1fb4e4c4
Both BuildMonitor and BuildOutputManager are doing similar things and
wrapping the build with forms of monitoring. These classes are only
used in the `mach build` command.
Since the BuildOutputManager takes an instance of BuildMonitor as an
argument and since BuildOutputManager behaves as a context manager,
it makes sense for BuildOutputManager to control the lifetime of
BuildMonitor's collection.
So, we teach BuildOutputManager's context manager to start the
BuildMonitor and ensure its resource collection is stopped when it
exits.
MozReview-Commit-ID: 3l9Hwz0Xe7o
--HG--
extra : rebase_source : 600b0231fce050465bdccb2bc11680f77bbc35d9
r?gps for the build changes and ochameau for the rest.
This results in about a 28% speed-up for Jetpack mochitest runs, for me.
MozReview-Commit-ID: K30q7BfvTLs
--HG--
extra : rebase_source : 8074947062c73a329f1d8a255a9601147ba1ba0c
ccache 3.3 added two fields in the status.
1. "cache hit rate"
https://github.com/ccache/ccache/issues/94
2. "cleanups performed"
0769ea3630
We just teach the parser the two fields. Nothing else.
MozReview-Commit-ID: 9kZrDrpCopd
--HG--
extra : rebase_source : ecb55fa9187abb37e668f0d25b40afd41597f7f8
In our current Rust world, we have the following dependency structure:
xul.so --------------------------+
|
xul-gtest.so -+--> xul.a --------+-> gkrust
|
+--> gkrust-gtest
This structure results in link errors with multiply-defined symbols
between gkrust-gtest and gkrust with newer Rust releases when linking
xul-gtest.so. So we have to do something different.
Our new structure is:
xul.so --------------------------+
|
xul-gtest.so -+--> xul.a --------+-> gkrust --+-> gkrust-shared
| |
+--> gkrust-gtest --------------+
and we enforce that a given shared library can only have at most one
Rust library that it depends on. Said Rust library is assumed to
include all significant Rust dependencies of the dependent static
libraries as well. (In the above structure, gkrust is simply a wrapper
around gkrust-shared, so gkrust-gtest doesn't have to include gkrust as
a dependency.)
This moves reading of gyp files to a separate process from the main
reader/emitter pipeline, causing gyp contexts to be consumed after other
contexts.
MozReview-Commit-ID: CevPcpe5cFI
Due to an apparent bug, DIRS are being ouptut inconsistently for directories
with code built by gyp files (as of this writing, they are output for child
directories of media/webrtc but not for some other directories). The DIRS
variable no longer drives compilation, so this was essentially a no-op.
MozReview-Commit-ID: IMfjyrcsWyv
This generalizes the monkey-patching of the main module added
in bug 914563 to allow multiprocessing to be used from config.status
(which triggers the same bug as when it's used with `mach` as main).
MozReview-Commit-ID: AdOdpKzmbsp
This patch allows specifying an objdir path in `SYMBOLS_FILE`, with the
requirement that the file is also listed in `GENERATED_FILES`. This is used
for handling NSS' .def files with their special processing.
I added tests for the existing `SYMBOLS_FILE` case as well as the new case
and a test for the error if the file is not listed in `GENERATED_FILES`.
MozReview-Commit-ID: 3cVbKplltfb
--HG--
extra : rebase_source : 0ae4180dbe9383b09f14554bfda8aec20d7cc094
Now that we access WPT related files from a source checkout, we no
longer need the web-platform tests zip file produced or consumed by
automation. So stop producing it.
MozReview-Commit-ID: Ea8KjKZJ5Yx
--HG--
extra : rebase_source : f22506a02fdd5e78434cdc5d1c1f274db1cd04e2
When attempting to run mach from a make target, there were failures on OSX due to an objdir
mismatch:
https://dxr.mozilla.org/mozilla-central/rev/7c576fe3279d87543f0a03b844eba7bc215e17f1/python/mozbuild/mozbuild/base.py#656
The two detected objdirs were "<objdir>" and "<objdir>/x86_64". I believe this should not
count as a mismatch, otherwise it would not be possible to run a mach command from the
x86_64 directory.
MozReview-Commit-ID: CXDEABNWX8L
--HG--
extra : rebase_source : 9daeaf372d872921e7b2854eee0313b5adc0e707
This command is mostly just a wrapper around `cargo vendor`, but it runs
it the right way and will install the cargo-vendor tool if necessary.
Additionally, the mach command will by default error if there are uncommited
changes to files other than Cargo.{toml,lock} in your working copy, and it
will stage changes to the vendored crates in your VCS after the update.
MozReview-Commit-ID: 2fMDBawNUMO
--HG--
extra : rebase_source : fe72f26aec795eb663c554933432e700ac5089c3
I wanted to be able to do some VCS interaction from a mach command, and we
didn't have anything suitable, so I tore up mozversioncontrol and replaced
it with a framework to hang new features off of. I've only implemented
the bits I need currently (get_modified_files and add_remove_files),
but it should be straightforward to add more functionality there.
This patch also adds a `repository` property to `MozbuildObject`, which will
return a `Repository` object for the topsrcdir to make using these helpers
even easier for `MozbuildObject`-derived classes.
MozReview-Commit-ID: Gw6Ixp1ltiN
--HG--
extra : rebase_source : e619d6642eb86c3f96e679ac22a3e561dfdbb56a
This is a little tricky since tup expects rules in a single Tupfile to
be topologically sorted, and the emitter emits the GeneratedFile object
before it emits the FinalTargetPreprocessedFile object. We work around
this by delaying when we process the application.ini.h GeneratedFile
object, but it's a hack.
MozReview-Commit-ID: 8nVm76nZOKb
--HG--
extra : rebase_source : a82cfbeef739aac791998fb6d45cf88eb7116e32
Now that we access WPT related files from a source checkout, we no
longer need the web-platform tests zip file produced or consumed by
automation. So stop producing it.
MozReview-Commit-ID: Ea8KjKZJ5Yx
--HG--
extra : rebase_source : ee6ec00689696a710faf390d3dec5c5d02d8ec74
Move packaging for Marionette from make to test_archiver by using root manifest files.
MozReview-Commit-ID: 1cxEBYQeJ2Z
**
--HG--
extra : rebase_source : 372a407d9207bfbccbfb88c689df60b8cc1abcaf
This patch also reworks how we set all the boolean flags in mozinfo.py.
MozReview-Commit-ID: IhjXCFsx5J1
--HG--
extra : rebase_source : d984d9ecaed765126600c8d85847a82585ab3e67
Some compilers on some platforms by default #define some of the values
we're using in the source we use in get_compiler_info(). Namely,
mingw-gcc #defines WINNT by default, and the WINNT in the source is then
replaced by 1, breaking the check.
The C preprocessor, fortunately, doesn't expand macros inside C strings.
So instead of `%KERNEL WINNT`, we output `%KERNEL "WINNT"`, and strip
out the double quotes. For good measure, we do this for all values in
the source used in get_compiler_info().
--HG--
extra : rebase_source : dd4cc2b8c3bf0cb508b09598706b74ccc12162be
.mozbuild/last_log.json is opened by the process doing the deleting.
On Windows, you can't delete an opened file.
So stop clobbering the .mozbuild directory.
This directory only holds non-essential artifacts from mach/build
invocations. I don't think keeping it around will break anything.
MozReview-Commit-ID: 9b0AC2ywAAZ
--HG--
extra : rebase_source : 9236e3e282d1db2595e8b36353008bc98e2ae6cf
Some substs values are lists, and some CONFIGURE_SUBST_FILES use them,
and don't expect the substitution to use a pythonic expression of the
value. So serialize those lists.
--HG--
extra : rebase_source : 848962c326236607609bca2b92180c8f6f4ad079
The "remove_objdir" method has been rewritten to support partial
clobber. It still defaults to full clobber. But the "full" argument
can be passed as False to limit to a partial clobber where currently
the "msvc" directory (contains Visual Studio files) is not clobbered.
On Windows, there might be a regression with this change because
we'll be invoking N winrm.exe processes and new processes have
a non-trivial overhead on Windows. However, it is hopefully unlikely
that new processes are more overhead than deleting hundreds of thousands
of files.
MozReview-Commit-ID: 7yeMttztwic
--HG--
extra : rebase_source : 646992be199e1059f0b09cf8bed3334085293fe0
My Python editor told me rmtree has been marked as deprecated. Use
mozfile.remove instead.
MozReview-Commit-ID: FYkXk1fnxvC
--HG--
extra : rebase_source : df392e8832e52501950f09acda208943c9e3d707
This required implementing a utility function to resolve the binary
type. I used GetBinaryTypeW via ctypes because this seems the fastest.
I arbitrarily limited the function to testing 32-bit and 64-bit Windows
executables because hopefully those are the only executables we'll
ever encounter. We can expand the binary detection later, if needed.
This includes support for running on non-Windows platforms.
MozReview-Commit-ID: CYwyDWQrePc
--HG--
extra : rebase_source : 8fd7ca7f253d9e9e18d64784652a5ff934ad2272
And with indentation so it is easier for humans to read.
MozReview-Commit-ID: Kkd6vmfLNUf
--HG--
extra : rebase_source : 9f2b4ad2223f361dd6dd1ec9cdda71bd5a8560e3
Until now, HAVE_64BIT_BUILD was entirely determined by a compiler check.
But we didn't run the check on e.g. artifact builds, while relying on
its result for some non-compilation related things, leading to subtle
discrepancies.
This changes the configure check to derive HAVE_64BIT_BUILD from bitness
determined by the target CPU, and double checked with a compiler check.
--HG--
extra : rebase_source : 5dc0cf2369ed4457bdd9a15736a70265a771d919
Currently, it returns either None or the contents of the compiler's stdout,
which is always expected to be an empty string, and is not very useful. So
instead, return True in the latter case.
--HG--
extra : rebase_source : ee69cdeab38d27178ce759591fb394da65e694ac
As of Python 3, decimal notations of octal values for permission modes
are no longer permitted and will result in a `SyntaxError` exception
(`invalid token`).
Using the proper octal notation which is also Python 2.7 compatible will
fix this issue.
--HG--
extra : rebase_source : 2e897c51f04ad0ee69071f84b98df224f3af72d3
The base compiler check in python configure does some preprocessing,
which ensures the compiler works to some extent. Autoconf used to have
a more complete test, doing a compile/link. We do have plenty of tests
afterwards that do that anyways, but it's better if we fail early if
the toolchain fails somehow.
This refactors try_compile such that the *_compiler variable themselves
can be used to trigger compiler tests. Eventually, we'll want something
similar for preprocessing and possibly other invocations.
This also removes similar tests from build/autoconf/toolchain.m4.
--HG--
extra : rebase_source : c60d1d6e39b6bd2a377516687affd9b8932ebc12
While on automation, there is no MSVC to find through the registry, the
story is different on local builds, and that can interfere with tests.
Specifically, it breaks test_toolchain_configure.py because it's not
expecting the registry to provide a valid path to an almost valid
compiler, and then fails because that compiler doesn't match the
expected target CPU.
And because build/moz.configure/toolchain.configure also affects the PATH
environment variable, subsequent tests end up failing even earlier
because executing the empty mozconfig with the modified environment then
fails because of the unicode value of PATH.
This change implements enough of _winreg to make the get_registry_values
function return nothing.
--HG--
extra : rebase_source : f70e40ddabaed1197f6cddce67832bb112f1969d
Back when it was added, it was used, but it is not anymore, outside
test_base.py.
--HG--
extra : rebase_source : f0b9a4dab2985e89e9950eda774ae853c7de764c
We've been reading the mozconfig in MozbuildObject.from_environment to
check whether the mozconfig topobjdir matches the detected topobjdir.
Since bug 1278415, everything using the buildconfig python module now
calls MozbuildObject.from_environment, which reads the mozconfig. A lot
of things to that during the build. But none of them actually need the
data from the mozconfig, and the topobjdir match test has been breaking
things randomly on multiple occasions.
The topobjdir match test, however, really only needs to happen once:
when a mach command starts. So we can move the test to MachCommandBase,
where it belongs, and anything actively using MozbuildObject.mozconfig
will have the mozconfig read, but everything else won't.
On a Linux64 opt build, this brings down the number of times the
mozconfig is read during `mach build` from 979 to 9.
--HG--
extra : rebase_source : 6b340f1fcf73a3c3987033c37f8f14ef06a44f04
This patch is really two separate changes.
The first change is that rust crates are large, standalone entities that
may contain multitudes of source files. It therefore doesn't make sense
to keep them in SOURCES, as we have been doing. Moving to use cargo
will require a higher-level approach, which suggests that we need a
different, higher-level representation for Rust sources in the build
system.
The representation here is to have the build system refer to things
defined in Cargo.toml files as the entities dealt with in the build
system, and let Cargo deal with the details of actually building things.
This approach means that adding a new crate to an existing library just
requires editing Rust and Cargo.toml files, rather than dealing with
moz.build, which seems more natural to Rust programmers. By having the
source files for libraries (and binaries in subsequent iterations of
this support) checked in to the tree, we can also take advantage of
Cargo.lock files.
The second is that we switch the core build system over to building via
cargo, rather than invoking rustc directly.
We also clean up a number of leftover things from the Old Way of doing
things. A number of tests are added to confirm that we'll only permit
crates to be built that have dependencies in-tree.
rlibs are going to be less important once we start building with cargo:
the focus will move to crates instead, so that's what we should call the
moz.build object.
Through an oversight, we listed librul.a twice when linking libxul: once
as part of the "objects" we were linking, and once as a static library.
This duplication is unnecessary and would cause problems later when we
try to generate librul.a via cargo, as cargo will put it someplace
different from where we expect and the two names will conflict. Let's
have rules.mk be the single source of truth for how librul.a is named,
and then the code to link libxul can simply refer to that name.
This patch is really two separate changes.
The first change is that rust crates are large, standalone entities that
may contain multitudes of source files. It therefore doesn't make sense
to keep them in SOURCES, as we have been doing. Moving to use cargo
will require a higher-level approach, which suggests that we need a
different, higher-level representation for Rust sources in the build
system.
The representation here is to have the build system refer to things
defined in Cargo.toml files as the entities dealt with in the build
system, and let Cargo deal with the details of actually building things.
This approach means that adding a new crate to an existing library just
requires editing Rust and Cargo.toml files, rather than dealing with
moz.build, which seems more natural to Rust programmers. By having the
source files for libraries (and binaries in subsequent iterations of
this support) checked in to the tree, we can also take advantage of
Cargo.lock files.
The second is that we switch the core build system over to building via
cargo, rather than invoking rustc directly.
We also clean up a number of leftover things from the Old Way of doing
things. A number of tests are added to confirm that we'll only permit
crates to be built that have dependencies in-tree.
rlibs are going to be less important once we start building with cargo:
the focus will move to crates instead, so that's what we should call the
moz.build object.
Through an oversight, we listed librul.a twice when linking libxul: once
as part of the "objects" we were linking, and once as a static library.
This duplication is unnecessary and would cause problems later when we
try to generate librul.a via cargo, as cargo will put it someplace
different from where we expect and the two names will conflict. Let's
have rules.mk be the single source of truth for how librul.a is named,
and then the code to link libxul can simply refer to that name.
Mingw python has a different os.path setup from native python, and has
os.sep and os.altsep reversed. In that case, the normsep function was
doing the wrong thing, leading to all sorts of problems.
While fixing this, also ensure the corresponding unit test covers this
peculiarity, even when running under the native win32 python.
--HG--
extra : rebase_source : 8fb18e0d4dc669c1d7e069f73fc44c22d419d43c
This never was a problem since auto-logging was broken on Windows, but
having mach clobber auto-log is a problem on Windows since it tries to
remove the log file while itself has it open, which fails.
--HG--
extra : rebase_source : 6da9f3e6148c201eade01d4598ce9c4becd051a0
We were relying on the log manager's terminal to know whether we're
running on a terminal to turn on auto-logging, but the log manager's
terminal is always None on Windows because blessings imports curses,
which doesn't work on Windows.
So instead, just use a plain os.isatty() call.
The same problem also applies to the show-log command to trigger the
pager (less). At the same time, fix the environment setting for LESS,
as on Windows, unicode literals are not allowed in the environment.
--HG--
extra : rebase_source : 1462849608c8cb86afcb080184efb50caf6d2f9e
The best kind of patch: bulk deletion. This removes two separate but
similar build flags, and an unsupported integration piece. The first
packaged Fennec's resources into an ill-defined GeckoView archive; the
second built on the first to produce an Android ARchive for external
consumption. Neither of these artifacts are supported or have
consumers; in fact, they mislead potential consumers, since they're
known to be broken. The Gradle build work under the --with-gradle
flag, and significant follow-up, is the path forward if Mozilla wants
to invest in packaging GeckoView on Android for external consumption.
That is, rather than hacking together AAR files, we'll use the
well-supported Gradle mechanisms for building and publishing such
libraries.
MozReview-Commit-ID: 4Z1jJ8z0cyJ
--HG--
extra : rebase_source : b8e65f39c286313fe8963bf3832d9b6977ef188f
I have a need to create tar archives deterministically
and reproducibly. Since we already have similar functionality in
mozpack for producting zip/jar archives, I figured it made sense for
this functionality to live in mozpack.
I made the functionality as simple as possible: we only accept
files from the filesystem and the set of files must be known in
advance. No class to hold/buffer state: just a simple function
that takes a mapping of files and writes to a stream.
MozReview-Commit-ID: If0NTcA7wpc
--HG--
extra : rebase_source : 9cbea36347ba2840dd5bff9dffefd994a73a0725
Prevailing style in the file for when read_topsrcdir is being tested for
exception-throwingness is to omit the assignment, so let's make
everything consistent.
And for GCC and clang, try to see if adding -m32, -m64 or --target
works if they don't.
--HG--
extra : rebase_source : 874bc2404a5ccc48e938bc7d9b2fe67ba625cb3e
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
This makes building on msys2 easier since its pip is broken.
MozReview-Commit-ID: 1hQHeu3BKOd
--HG--
extra : rebase_source : 5447d96893a502225980d1dab7b4f89b888ad661
This adds the 'xpcshell-test' command to the mach environment found in the test
package. This will allow developers to easily run xpcshell after checking out
and interactive worker.
MozReview-Commit-ID: fBAbfuG5XQ
--HG--
extra : rebase_source : 71077c9142f33843ed87d4bc4617a780f775939b
Before bin_path would detect msys2 as if it were a windows system which would cause a virtualenv problem since the binaries should go in a /bin folder not a /Scripts folder for msys2.
Based on a patch by :vlad 89b21efe93
MozReview-Commit-ID: IyAukszHGmN
--HG--
extra : rebase_source : 9ada9cf61b76c85cf483ad8212c95d17070a7025
Technically, this includes the mingw64 version of make, but it is still called mingw32-make when installed from pacman with msys2.
This is a necessary step to make Firefox build on a pure msys2 environment.
Also, unlike mozmake, because this make is installed from a package manager. It can be automatically updated.
MozReview-Commit-ID: EAN6xmIgYWd
--HG--
extra : rebase_source : 43fe0d4b35e91f1143ce2ea1d20f5f3c5f1f7c86
The mozconfig detection logic has bitten us on many occasions in the
past. The following changes are made to tentatively improve the
situation:
- The API is modified such that autodetection of the mozconfig has
to be a conscious decision made by the caller, and not triggered
any time there is no mozconfig given, which could be a conscious
decision of the opposite.
- mozinfo.json now stores the actual mozconfig (or lack thereof) used
during configure.
--HG--
extra : rebase_source : c7a632afd414f25daf7bbe7e1a66c3736c26e039
Per froydnj in bug 1186064 comment #23, "it makes sense to proceed with removing
MSVC 2013 support." This commit does that.
We also go a step further and require VS2015 Update 2 instead of just
update 1. This temporarily brings us down to just 1 officially supported
Visual Studio version. However, VS2015u3 was just released and is
unofficially supported.
Since MOZ_CRT is no longer set, references to it have been removed.
MozReview-Commit-ID: 8MUR6qLzQA5
--HG--
extra : rebase_source : 8f5061080a3d56dd484f9be03649fb65f0145f67
Per froydnj in bug 1186064 comment #23, "it makes sense to proceed with removing
MSVC 2013 support." This commit does that.
We also go a step further and require VS2015 Update 2 instead of just
update 1. This temporarily brings us down to just 1 officially supported
Visual Studio version. However, VS2015u3 was just released and is
unofficially supported.
Since MOZ_CRT is no longer set, references to it have been removed.
MozReview-Commit-ID: 8MUR6qLzQA5
--HG--
extra : rebase_source : 22ab4f47661ead4995d0c5261104abfb02b82aa2
Since it conflicts with moz.configure which resolves shortnames since
parts of the build system don't like paths with spaces.
MozReview-Commit-ID: nJkRV4Nafo
--HG--
extra : rebase_source : 9f2db54ec38eb0f05b478b445c0a883ca69b0127
This also fixes the issue of processing the artifacts twice in some
situations (bug 1275673). Note that the artifact download no longer
happens when a specific target is passed to 'mach build'.
MozReview-Commit-ID: Ktys6u3r1kG
The buildconfig module predates MozbuildObject.from_environment, and
it's about time to start factoring things out such that we only have
one way to get config.status data. This is step 1: making the
buildconfig module use MozbuildObject.from_environment.
Eventually, we'll want to remove the buildconfig module uses everywhere.
The topobjdir-finding logic in mozbuild relies on MOZ_CURRENT_PROJECT
being set, and it's currently only set when going through client.mk.
On automation, during universal builds, make check is invoked directly
in one of the objdirs, so MOZ_CURRENT_PROJECT is not set. We've had
other similar problems in the past. Ensuring MOZ_CURRENT_PROJECT is set
in the objdir itself should reduce the risk of other such issues in the
future.
Historically, a mozinfo for js standalone build has not been necessary,
but with the move towards a) having things work with mach and b)
buildconfig using the MozbuildObject.from_environment in next patch,
mozinfo becomes necessary (it's required for
MozbuildObject.from_environment to find the directory is an objdir).
Interestingly, hazard builds do both a js standalone build and a desktop
Firefox build at the same time, both of which are done with MOZCONFIG
set in the environment... with the Firefox mozconfig. The result of now
writing a mozinfo for js standalone builds is that in that case, they
end up with a reference to the mozconfig, which the build system then
reads, and finds a MOZ_OBJDIR, which then doesn't match the js
standalone build objdir. So for those builds, reset MOZCONFIG.
Killing the sccache background daemon is part of postflight_all, but in
the current setup, postflight_all happens at the end of a "normal" build,
but we run automation build steps after that.
What happens then is that more compilations happen (gtests), which start
sccache again, but there's nothing to kill sccache again once this is
all done.
Now that the OSX universal builds postflight is gone, it is not
necessary for postflight_all to happen before the automation build steps.
So ensure postflight_all scripts happen last.
The downside of this change is that this now prevents sccache.log from
being uploaded, but we should probably send processed data to the graph
server instead.
Killing the sccache background daemon is part of postflight_all, but in
the current setup, postflight_all happens at the end of a "normal" build,
but we run automation build steps after that.
What happens then is that more compilations happen (gtests), which start
sccache again, but there's nothing to kill sccache again once this is
all done.
Now that the OSX universal builds postflight is gone, it is not
necessary for postflight_all to happen before the automation build steps.
So ensure postflight_all scripts happen last.
The downside of this change is that this now prevents sccache.log from
being uploaded, but we should probably send processed data to the graph
server instead.
Mike Hommey
Phil Ringnalda
Kim Moir
Eugen Sawin
aleth
Chris Manchester
Grisha Kruglov
Gregory Szorc
Kris Maglione
Mike Shal
Ting-Yu Lin
Nathan Froyd
Kartikaya Gupta
Michael Kaply
Ted Mielczarek
Sebastian Hengst
Carsten "Tomcat" Book
Wes Kocher
Andrew Halberstadt
Matthew Gregan
Henrik Skupin
Michael Layzell
Yen Chi Hsuan
Shing Lyu
Al Tsai
Xidorn Quan
Myk Melez
Ryan VanderMeulen
Elias Probst
Nathan Froyd
Ehsan Akhgari
Nick Alexander
Geoff Brown
Tom Tromey
Xidorn Quan
Nathan Hakkakzadeh
Gijs Kruitbosch
Justin D'Arcangelo
Chris AtLee
Ms2ger