e10s profiling or IR-based PGO instrumentation will both produce
multiple `.profraw` files that need to be handled in some way. Since
clang's `-fprofile-generate` option takes a directory, it seems fitting
to make `--with-pgo-profile-path` mirror that by taking a directory, and
letting `merge_profdata.py` deal with whatever files it might find in
said directory.
Differential Revision: https://phabricator.services.mozilla.com/D32389
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
This will match the compiler version Tor would like. We backport several
llvm-objcopy patches that landed right after the 8 branch though. We
also grab some upstream changes from mingw-clang in the build script
Differential Revision: https://phabricator.services.mozilla.com/D31347
--HG--
extra : moz-landing-system : lando
Bug 1548941 restricted under which circumstances we allow the
browser.tabs.remote.autostart pref to turn off e10s. The PGO profileserver.py
script relied on the unittest-required user.js prefs collection to turn off
e10s (see also bug 1196094) via this pref. For PGO builds, we do not set the
MOZ_DISABLE_NONLOCAL_CONNECTIONS env var, which meant that we stopped
honouring the pref to turn off e10s. Unfortunately, this meant that
e10s was inadvertently now switched on for the pgo profiling, which
negatively impacted speedometer on PGO builds (and possibly other tests).
All this change does is re-disable e10s for PGO profiling. We should
investigate how to turn e10s on "properly" for PGO, but we can do that in
bug 1196094, without taking this temporary regression, especially as 68
branches.
Differential Revision: https://phabricator.services.mozilla.com/D31736
--HG--
extra : moz-landing-system : lando
We need this to auto-generate the copy-constructor for TransformOperation,
without which the patch wouldn't build.
Differential Revision: https://phabricator.services.mozilla.com/D30799
--HG--
extra : moz-landing-system : lando
Having `rustc` be `rustup`'s wrapper for `rustc` means that we may
silently honor `rustup`'s override mechanisms. We noticed this first on
OS X, where we use the "real" `cargo` but `rustup`'s `rustc` wrapper,
and problems ensued when `cargo` thought it was using one version of
`rustc`, but actually wound up using something different.
It seems better to avoid silently interposing `rustup`'s toolchain
override mechanisms everywhere, rather than having to special-case OS
X. So let's factor out a general mechanism for removing the wrappers
`rustup` provides and use that for both `rustc` and `cargo`. The tests
need adjusting because we weren't triggering the unwrapping cases
before; we don't yet test the case where we really do need to unwrap.
That test can be left for a future patch.
Differential Revision: https://phabricator.services.mozilla.com/D29531
--HG--
extra : moz-landing-system : lando
We've not been checking the clang-cl version in use. This lack of
checking is bad, for a couple of reasons:
* Released versions of clang-cl differ drastically in their robustness;
* Only the most recent version of clang-cl supports aarch64.
We should check for a minimum version of clang-cl, just like our other
supported compilers. As a bonus, we can then start depending on
features that we know appear in the particular minimum clang-cl
version. (The current patch is motivated by `/clang:` command-line
support, but one could pick other things.)
Differential Revision: https://phabricator.services.mozilla.com/D30723
--HG--
extra : moz-landing-system : lando
This option is for performing LTO between C++ code and Rust code. The
actual build pieces for Rust code are coming in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D28508
--HG--
extra : moz-landing-system : lando
We already do this for the compiler that we detect via
toolchain.configure...but as the comment in `basic_bindgen_cflags`
alludes to, we don't actually use that compiler here. We use a much
more bare-bones compiler, so we have to add the necessary flags manually.
We need to make `--with-macos-sdk` a `js_option` so that uses of bindgen
in the JS engine will receive the proper flags.
Differential Revision: https://phabricator.services.mozilla.com/D30239
--HG--
extra : moz-landing-system : lando
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
Occasionally the taskcluster fetches can fail, so make sure the requests
library automatically retries if possible.
Differential Revision: https://phabricator.services.mozilla.com/D29914
--HG--
extra : moz-landing-system : lando
Some media libraries use gas syntax in their assembly files. Rather than
converting these arm assembly syntax files for aarch64, we can use clang-cl
to build them directly.
Differential Revision: https://phabricator.services.mozilla.com/D27785
--HG--
extra : moz-landing-system : lando
this change comprises the in-tree changes required to make use of sccache in gcp.
specifically:
- a gcp metadata lookup for availability-zone is added to mozconfig, enabling a build to determine its regional gcp sccache bucket
- the sccache cargo build command is modified to include the gcs feature when the environment contains gcs configuration
note that further changes are required on infra to support sccache use. the required changes already [exist](https://github.com/mozilla-releng/OpenCloudConfig/commit/1d515dc) and are enabled for gcp windows infra, including:
- a json credential file on the build instance filesystem, containing credentials valid for the appropriate scm level bucket for the gcp region
- an `SCCACHE_GCS_KEY_PATH` env variable containing the path to the json credential file
- an `SCCACHE_GCS_RW_MODE` env variable containg the text `READ_WRITE`
- sccache buckets must exist for each region and scm levels 1 & 3
- credentials for scm level 1 buckets **must not** be valid for scm level 3 buckets
on gcp systems which do not contain credential files and the above mentioned env variables (eg gecko-[1-3]-b-linux), sccache should fail gracefully without breaking builds.
Differential Revision: https://phabricator.services.mozilla.com/D29622
--HG--
extra : moz-landing-system : lando
Using `ccache` apparently interferes with how flag checking is done when
we're using `clang` as our compiler. We can work around this by adding
a few more flags to flag checking.
Differential Revision: https://phabricator.services.mozilla.com/D28895
--HG--
extra : moz-landing-system : lando
Nathan Froyd
Kagami Sascha Rosylight
Mike Hommey
Chris Manchester
Brindusan Cristian
Andreea Pavel
Coroiu Cristina
Tom Ritter
David Major
Bastien Orivel
Gijs Kruitbosch
Emilio Cobos Álvarez
Ciure Andrei
Kevin Jacobs
Sebastian Streich
Noemi Erli
Alexis Beingessner
Nick Alexander
Ryan VanderMeulen
Kartikaya Gupta
Razvan Maries
Mike Shal
Dan Minor
Rob Thijssen
Sylvestre Ledru
Geoff Brown
Bobby Holley