Before, I/O errors writing to stdout/stderr (e.g. due to broken pipe)
would result in handleError() being called and execution would
keep running. This would potentially result in an error message for
every log/line failure being printed to stderr.
We change the behavior so I/O failures are fatal and abort
execution.
We test the new behavior by changing a test to pipe to `head`
directly. Since `head` exits once it has seen sufficient output,
this results in an EPIPE which now results in immediate program
termination.
MozReview-Commit-ID: 1UecZJ56h4r
--HG--
extra : rebase_source : b35d9c096621d9698260d29a7d0132c4989200a7
sccache.mk is the only thing that uses MOZ_PREFLIGHT_ALL and
MOZ_POSTFLIGHT_ALL. We're trying to kill client.mk and these
variables are next on the chopping block.
This commit essentially moves the logic of sccache.mk inline into
client.mk. Initially, I wanted to move the management of the
sccache daemon to Python as part of what `mach build` invokes.
However, the sccache daemon needs access to the make jobserver.
Since we don't have an active make process in `mach`, this is
obviously problematic. The sccache daemon is also used by
configure, which is launched from client.mk. So the best we
can do right now is move the sccache daemon logic into client.mk.
As part of the port, we pass the path to the sccache binary via
an environment variable. This feels slightly better than hardcoding
the path that automation uses.
MozReview-Commit-ID: zcOYR4I1OG
--HG--
extra : rebase_source : 305a237dc9f5bd96e4aa83d491ac2498fe3c3ba0
We add a simple cram test that `configure --help` works.
I added the test to build/tests because I'm not sure where else it should go.
This test uncovers a few interesting things:
1) piping `./configure --help` to `head` directly causes a Python
traceback (presumably due to the pipe disappearing once N lines
have been read)
2) "checking for vcs source checkout" is printed for --help
3) It is printed twice (!!)
These will be addressed later. Establishing test coverage is
more important.
MozReview-Commit-ID: 9zQ5X8ulTkc
--HG--
extra : rebase_source : aaf660152cdfe37580f559976bca13ea9bf14c49
Before, the build root was not in a Docker cache or volume. With
current Docker works, that meant AUFS. We know AUFS is slow under
I/O load and can cause random failures due to missing data after
writes.
This commit changes the build root to a known Docker volume, which
will be backed by EXT4 and won't have the problems of AUFS.
MozReview-Commit-ID: 6WOH0yednAv
--HG--
extra : rebase_source : bbff0f00f55acdbe068fdf617a7903b8a303c397
This doesn't need to be in client.mk.
Also, we inline the info to help people correct the failure, as this
results in a better user experience.
MozReview-Commit-ID: KURL3RIGzKf
--HG--
extra : rebase_source : dc79d3f6aa4e91a12cab0e26d5fc0a3e15afa833
extra : source : 2eceb30625acd8cfadda0baa6326a7e9fd07dece
Checks like this are what configure is for.
In addition to moving the check, we also validate topobjdir as well.
MozReview-Commit-ID: 9sVNQJsAnjO
--HG--
extra : rebase_source : 688961fffca5922c7186c0d39182de7220f7dbe3
extra : source : d9a4ea9bc34a1e0c710469fc0a556ed624ea387b
compare-mozconfigs is platform agnostic AFAICT. And it runs fast.
Let's run tests for all the platforms all the time.
MozReview-Commit-ID: GqsFCp3XdZG
--HG--
extra : rebase_source : 4fd8fb48af61bfc95ec6c251ccf6fcf557ff6c0c
The mechanism by which PGO builds are kicked off is kinda wonky.
The MOZ_PGO environment variable is recognized by configure and setting
it will result in MOZ_PGO being defined in substs. In addition, the
build backend (previously client.mk, now Makefile.in) also recognizes
MOZ_PGO (from mozconfig or environment) and takes appropriate action.
In-tree mozconfigs set MOZ_PGO via mk_add_options. mk_add_options
is intended as a mechanism to inject state into client.mk and the
make-based build system.
In addition, there is code in mozharness (unchanged by this commit)
that sets MOZ_PGO if appropriate.
A PGO build configuration is different from a non-PGO build
configuration. Therefore a make-centric environment variable to
control PGO is not ideal. Instead, this should be defined as a
configure-time flag and the build invocation should key off that.
This commit normalizes in-tree mozconfigs to set MOZ_PGO via
ac_add_options and updates the PGO documentation to recommend
this method.
MozReview-Commit-ID: k6AZyJuXjs
--HG--
extra : rebase_source : b1a6348611eba08dd67ec938cca5586fbe8e6910
extra : source : 25c7ebc7c44dd253f421b6de3d0337635d0c99d0
32-bit clang-cl.exe was looking specifically for HostX86\x86\link.exe, which doesn't exist in our automation package. Make it look in HostX64\x86 instead.
This is an ugly hack and it would be preferable to just use a 64-bit compiler (bug 1414287).
In a proper VS install, the path to cl.exe looks like:
...\VC\Tools\MSVC\14.11.25503\bin\HostX64\x64\cl.exe
In our automation, the path is just:
...\VC\bin\HostX64\x64\cl.exe
Clang tries to do some sanity-checking to make sure that the cl.exe it finds is the Microsoft compiler and not some other program. But the checks are a little too strict for us, so just look for "bin\Host*\*\cl.exe".
The new VS package is now based on update 15.4.2, although that release didn't affect any files in our package. I'm picking up the update mostly just to make filename unique.
There are xpcshell tests to verify that the appropriate distrust flag is set
upon reaching an affected end entity certificate; this test checks that the
distrust flag prints a warning to console.
MozReview-Commit-ID: OMG246WOOT
--HG--
rename : devtools/client/webconsole/test/browser_webconsole_certificate_messages.js => devtools/client/webconsole/test/browser_console_certificate_imminent_distrust.js
extra : rebase_source : a5fed5457e7789e742ee461b988463b81cd2c214
Currently mozconfig.cache overrides a few build options for sccache. This
patch moves them into toolchain.configure so that the build system will
set them properly when sccache is in use. Additionally, {CC,CXX}_WRAPPER
are set in config.mk, so just avoid setting them when sccache is in use.
MozReview-Commit-ID: FYlVKRI8OiN
--HG--
extra : rebase_source : 00715beb5fbd2c11311dec43809bd1febab56a11
extra : intermediate-source : 0f2b1b75b83737378d882a3c3e0d8dfb4efecd1f
extra : source : a8032ae9cb2ad1c4574c6ac6f5c2778863cd71e0
getTopActivity calls 'adb shell dumpsys window windows' which intermittently
times out. Instead of ending the test run when that happens, let's try
again, in hopes of recovering. If recovery fails and the browser is
subsequently found running, log an explanation before killing it.
We were adding c_compiler.flags and toolchain_flags to some paths
through this function, but not all. Not adding those flags caused this
function to detect the host's ld.gold instead of the target's ld.gold.
And that, in turn, caused linker errors when the host ld.gold couldn't
understand the target's object files.
MozReview-Commit-ID: vJzWagUGkL
This was mainly used to support Universal MacOS builds, which were
removed several months ago.
In theory, someone could be using this feature to build multiple
applications with one build system invocation. But given that client.mk
is no longer the preferred interface to the build system and multiple
applications can be built by running `mach build` with different
mozconfigs, I don't think support for this feature is worth keeping.
This commit removes support for MOZ_BUILD_PROJECTS and related
functionality from client.mk. Support for recognizing
MOZ_CURRENT_PROJECT in configure and mozconfig evaluation has also
been removed. This includes support for the ac_add_app_options
mozconfig function.
Good riddance.
MozReview-Commit-ID: 7xI2jYxDFFr
--HG--
extra : rebase_source : 91068f3b8ae32fbcda4defb5d4bb086a04387598
Noemi Erli
Margareta Eliza Balazs
Gregory Szorc
Marco Castelluccio
Narcis Beleuzu
Randall Barker
Tom Prince
Sylvestre Ledru
Chris Manchester
Sebastian Hengst
David Major
Coroiu Cristina
Ted Mielczarek
Masatoshi Kimura
Mike Hommey
J.C. Jones
Csoregi Natalia
Geoff Brown
Petr Sumbera
Nathan Froyd