[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
Analogously to the existing `linux64-clang-8-android-cross` build, this
build is a linux x86-64 build with runtime library support for aarch64.
Depends on D28405
Differential Revision: https://phabricator.services.mozilla.com/D28406
--HG--
extra : moz-landing-system : lando
This change enables us to build compiler-rt and related
libraries (e.g. address sanitizer, etc.) for whatever targets we like,
assuming that we have an accessible sysroot for the target on the build
machine.
Depends on D28404
Differential Revision: https://phabricator.services.mozilla.com/D28405
--HG--
extra : moz-landing-system : lando
CMake errors can be pretty opaque, especially if CMake is being run
inside the Ninja build process. Let's try to surface those errors to
make problems easier to debug.
Differential Revision: https://phabricator.services.mozilla.com/D28360
--HG--
extra : moz-landing-system : lando
We've landed some recent changes that implicitly require SDK
10.0.17134.0. Since we've been building with that version for some time
in automation, let's go ahead and raise the minimum version accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D28671
--HG--
extra : moz-landing-system : lando
We've landed some recent changes that implicitly require SDK
10.0.17134.0. Since we've been building with that version for some time
in automation, let's go ahead and raise the minimum version accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D28671
--HG--
extra : moz-landing-system : lando
We moved fuzzing options out of `toolkit/moz.configure` into `js`'s
configure a while back, but we seem to have snuck some fuzzing-related
options into `toolchain.configure` in the interim. But we can't make
the `toolchain.configure` bits depend on the `js` bits; let's just put
everything in `toolchain.configure`.
Differential Revision: https://phabricator.services.mozilla.com/D28084
--HG--
extra : moz-landing-system : lando
We were never adjusting `last` in this loop, so we were computing the
wrong addresses for all sections beyond the first. Which in turn meant
that we would compute the wrong size for the section data we needed to
allocate.
Differential Revision: https://phabricator.services.mozilla.com/D28195
--HG--
extra : moz-landing-system : lando
It seems better to set switches enabling runtime libraries and switches
enabling runtime libraries to build in different places, as future
changes might only enable runtime libraries for certain targets, but not
need any special switches for building.
Depends on D27594
Differential Revision: https://phabricator.services.mozilla.com/D27595
--HG--
extra : moz-landing-system : lando
`android_targets` here is a dict, not a sequence, and while `iter` on a
dict object implicitly means `dict.iterkeys()`, that's not really
obvious. We should instead be explicit about what we're doing here.
Depends on D27593
Differential Revision: https://phabricator.services.mozilla.com/D27594
--HG--
extra : moz-landing-system : lando
We don't need them and we might as well be explicit about not building them.
Depends on D27592
Differential Revision: https://phabricator.services.mozilla.com/D27593
--HG--
extra : moz-landing-system : lando
The setup for compiler-rt is currently done before the stage 2 build,
which happens to be the final stage for our android runtime libraries
build. But we may also want to build runtime libraries on 3-stage
bootstrap builds, in which case we don't want compiler-rt to be active
for the second stage. Move the setup into build_one_stage so that the
setup is controllable by is_final_stage, which is set in all the place
that we care about.
Differential Revision: https://phabricator.services.mozilla.com/D27592
--HG--
extra : moz-landing-system : lando
Before this patch, we first find an executable, then check the version. So if
the first executable we find is outdated, we won't look for others.
Instead, check each of them for different versions manually. This will also
unblock bug 1540533, since at that point we know that we'll be able to find
a cbindgen with the right version.
Differential Revision: https://phabricator.services.mozilla.com/D27890
--HG--
extra : moz-landing-system : lando
We were allocating ElfSection's data with `new[]` and modifying it with
`realloc` in some places, which causes allocator mismatches.
Consistently manage the data with `malloc`, `realloc`, and `free` instead.
Differential Revision: https://phabricator.services.mozilla.com/D27327
--HG--
extra : moz-landing-system : lando
Bug 1500504 added a version check for the SDK, but it only does the
check if --with-macos-sdk is used. We should also check the version when
using the default SDK.
Note that this means we now set MACOS_SDK_DIR to be the default SDK even
if it wasn't set explicitly from --with-macos-sdk
Differential Revision: https://phabricator.services.mozilla.com/D17727
--HG--
extra : moz-landing-system : lando
If mozbuild parsing fails due to a missing file (eg: a file not existing
in UNIFIED_SOURCES), then no Makefiles are written out, but
config.status exists. This would cause mozbuild to think that configure
doesn't need to run, and rely on make to perform the backend-out-of-date
check in rebuild-backend.mk. Unfortunately since no Makefiles were
written, the make command fails immediately and no attempt is made to
re-create the backend. Note that this is only a problem if the first
mozbuild parsing from a clobber build fails, otherwise there is
typically a top-level Makefile from a previous build to call into (at
which point make can determine it is out-of-date, and re-invoke itself).
The fix is to have the RecursiveMake backend re-use the same logic that
was introduced into mozbuild for alternate backends, and remove
rebuild-backend.mk. This way, mozbuild can always determine if the
backend needs to be regenerated, even if the initial parsing failed.
Test code was also relying on rebuild-backend.mk to generate the
TestBackend, but moving backend_out_of_date() into MozbuildObject allows
this code to be shared.
Differential Revision: https://phabricator.services.mozilla.com/D26262
--HG--
rename : build/gen_test_backend.py => python/mozbuild/mozbuild/gen_test_backend.py
extra : moz-landing-system : lando
Bug 1500504 added a version check for the SDK, but it only does the
check if --with-macos-sdk is used. We should also check the version when
using the default SDK.
Note that this means we now set MACOS_SDK_DIR to be the default SDK even
if it wasn't set explicitly from --with-macos-sdk
Differential Revision: https://phabricator.services.mozilla.com/D17727
--HG--
extra : moz-landing-system : lando
Interestingly, the change makes one configure test have a different
result (localeconv ends up being found when it used not to be found),
but the result of that check is actually not used on Windows because we
set HAVE_LOCALECONV manually.
Differential Revision: https://phabricator.services.mozilla.com/D25902
--HG--
extra : moz-landing-system : lando
If mozbuild parsing fails due to a missing file (eg: a file not existing
in UNIFIED_SOURCES), then no Makefiles are written out, but
config.status exists. This would cause mozbuild to think that configure
doesn't need to run, and rely on make to perform the backend-out-of-date
check in rebuild-backend.mk. Unfortunately since no Makefiles were
written, the make command fails immediately and no attempt is made to
re-create the backend. Note that this is only a problem if the first
mozbuild parsing from a clobber build fails, otherwise there is
typically a top-level Makefile from a previous build to call into (at
which point make can determine it is out-of-date, and re-invoke itself).
The fix is to have the RecursiveMake backend re-use the same logic that
was introduced into mozbuild for alternate backends, and remove
rebuild-backend.mk. This way, mozbuild can always determine if the
backend needs to be regenerated, even if the initial parsing failed.
Test code was also relying on rebuild-backend.mk to generate the
TestBackend, but moving backend_out_of_date() into MozbuildObject allows
this code to be shared.
Differential Revision: https://phabricator.services.mozilla.com/D26262
--HG--
rename : build/gen_test_backend.py => python/mozbuild/mozbuild/gen_test_backend.py
extra : moz-landing-system : lando
This imports the changes from wheezy-lts (http://deb.freexian.com/extended-lts/)
and creates a package we install in the debian7-based images (with a
modified version number to work around bug #1419577.
This leaves out debian7-raw and debian7-packages as unpatched, because
of the chicken-and-egg problem.
Depends on D26100
Differential Revision: https://phabricator.services.mozilla.com/D26102
--HG--
extra : moz-landing-system : lando
When cross-building with clang, we use `--target` with a target that is
derived from the configure target, with the vendor removed. So for
`configure --target=aarch64-unknown-linux-gnu`, we use
`clang --target=aarch64-linux-gnu`.
Then, clang itself looks for tools as `$target-$tool` first, then
`$tool`, which means for the assembler, it's looking for
`aarch64-linux-gnu-as` before `as`, but not
`aarch64-unknown-linux-gnu-as`.
Building GNU as with `--target=aarch64-unknown-linux-gnu` creates the
`aarch64-unknown-linux-gnu-as`, but we really want `aarch64-linux-gnu`,
so we adjust the target in the binutils build script.
Differential Revision: https://phabricator.services.mozilla.com/D25684
--HG--
extra : moz-landing-system : lando
As of clang 8, llvm-config doesn't return all flags clang was built
with, and omits some flags that do impact the libclang ABI,
-stdlib=libc++ being one of them (it might well be the only one).
Building clang with LLVM_ENABLE_LIBCXX=ON does build it with
-stdlib=libc++, but is unrelated to whether or not libc++ is built and
shipped with clang, which still happens without it.
So while versions older than clang 8 are not really affected, it doesn't
hurt to build clang without -stdlib=libc++ (especially when it
currently only applies to the clang used to cross build android with
PGO, not even the other android cross builds), in preparation for
switching to clang 8.
Differential Revision: https://phabricator.services.mozilla.com/D25031
--HG--
extra : moz-landing-system : lando
There is no concern that the Android NDK clang may not support it, as
the flag was added in clang 2.9. The flag is also not supported with
GCC, which is not ideal, but we already crossed that bridge at least
with -gcc-toolchain added in extra_toolchain_flags, which is not
supported by GCC either.
Differential Revision: https://phabricator.services.mozilla.com/D25019
--HG--
extra : moz-landing-system : lando
We shouldn't pass those flags when building C. It doesn't matter /too/
much currently, but will in a subsequent change, which will introduce
a C++-only flag in stlport_cppflags.
Differential Revision: https://phabricator.services.mozilla.com/D25018
--HG--
extra : moz-landing-system : lando
Other than the MediaPipelineFactory references, nothing else is obsolete, so this is a
very minor cleanup, just to improve readability a bit.
Differential Revision: https://phabricator.services.mozilla.com/D25124
--HG--
extra : moz-landing-system : lando
Last time we updated the requirements was in bug 1278456, after we
switched to GTK+3.
While it might be worth checking what would be a reasonable requirement,
the immediate problem is that updating ANGLE hits a snag with a
libstdc++ 4.7 symbol, and the only main distro release that bumping to
that version would make us not support anymore is Ubuntu 12.04 LTS,
EOLed 2 years ago (April 2017).
Bumping to some even newer version would need more consideration.
Desupporting Ubuntu 12.04 LTS at this point is almost a no-brainer.
Differential Revision: https://phabricator.services.mozilla.com/D23979
--HG--
extra : moz-landing-system : lando
We need to have full symbols uploaded for the upcoming EME-enabled
win64-aarch64 nightlies, and the tasks to do that are derived from the
nightly itself, which is going to be an artifact build. Bug 1527463 took
care of adding the option to enable that, and we turn it on for
EME-enabled builds.
MOZ_ARTIFACT_TASK_WIN32_OPT is not exactly the right thing, but we're
already using it to enable EME in
browser/config/mozconfigs/win64-aarch64/common-opt and is only set on
those builds.
Differential Revision: https://phabricator.services.mozilla.com/D23639
When installing JDK 1.8, it writes path to the following registry.
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit\1.8\JavaHome
So we use this registry to detect JDK installation path on Windows if available.
Differential Revision: https://phabricator.services.mozilla.com/D20449
--HG--
extra : rebase_source : d8a380d9839f4de749815f3c81665e8d00226862
The current setup uses different ways for different platforms, with
different workarounds, even using extra configuration items for Windows.
Now that there can't be a difference between the host per the build
system and the host per rust, we can get rid of those configuration
items, and use a more common infrastructure.
We cannot, however, avoid using wrapper scripts, because per-target rust
link-arg flags don't work up great.
The downside is that multiplies the number of wrappers, as we now have
to have a different one for host and target, and then we have .bat files
and shell scripts for, respectively, Windows hosts, and other hosts.
Depends on D24321
Differential Revision: https://phabricator.services.mozilla.com/D24322
--HG--
extra : moz-landing-system : lando
While the substitution pattern is kind of awful in make, it will allow
to more straightforwardly deal with the difference between target and
host.
Differential Revision: https://phabricator.services.mozilla.com/D24321
--HG--
extra : moz-landing-system : lando
The current setup uses different ways for different platforms, with
different workarounds, even using extra configuration items for Windows.
Now that there can't be a difference between the host per the build
system and the host per rust, we can get rid of those configuration
items, and use a more common infrastructure.
We cannot, however, avoid using wrapper scripts, because per-target rust
link-arg flags don't work up great.
The downside is that multiplies the number of wrappers, as we now have
to have a different one for host and target, and then we have .bat files
and shell scripts for, respectively, Windows hosts, and other hosts.
Depends on D24321
Differential Revision: https://phabricator.services.mozilla.com/D24322
--HG--
extra : moz-landing-system : lando
While the substitution pattern is kind of awful in make, it will allow
to more straightforwardly deal with the difference between target and
host.
Differential Revision: https://phabricator.services.mozilla.com/D24321
--HG--
extra : moz-landing-system : lando
Newer versions of rust come with a specialized arm target that matches
more closely our armv7 targets (with neon and thumb2), so use that when
possible.
Depends on D24324
Differential Revision: https://phabricator.services.mozilla.com/D24325
--HG--
extra : moz-landing-system : lando
Some of our builds use --enable-warnings-as-errors and some don't, and I can't
figure out a way to write an expectation comment for that.
Differential Revision: https://phabricator.services.mozilla.com/D24469
--HG--
extra : moz-landing-system : lando
MT is part of the Windows SDK, not MSVC, but an alternative exists for
it: llvm-mt. The official LLVM distribution for Windows doesn't include
it[1], though, so we can't just switch to it.
1. https://bugs.llvm.org/show_bug.cgi?id=40152
While here, remove the .exe suffix from the check, to future-proof for
cross-windows builds.
Differential Revision: https://phabricator.services.mozilla.com/D24326
--HG--
extra : moz-landing-system : lando
The definitions can't be entirely removed yet because NSS still needs them.
Differential Revision: https://phabricator.services.mozilla.com/D23454
--HG--
extra : moz-landing-system : lando
Since these are compile-time constants, they can't exactly go away on us due to
running script, right?
Differential Revision: https://phabricator.services.mozilla.com/D24195
--HG--
extra : moz-landing-system : lando
We need to typecheck the trivials too, not just the final thing after trivials
are stripped, because casts are trivials.
Differential Revision: https://phabricator.services.mozilla.com/D24186
--HG--
extra : moz-landing-system : lando
The old code for member method calls did the following:
1) Find the member method calls.
2) Look at their "this" expression.
3) If the "this" is an operator call, check for any of the arguments of the
operator call being invalid.
4) Otherwise (if not an operator call) check for the "this" value being
invalid.
This wasn't right, because the "is invalid" check checks the type and only
considers refcounted things. So if the code looked something like
"foo[i]->call_method()", we would look at the types of "foo" and "i" and
determine that none of those are refcounted types so there is nothing invalid
here (since "foo" is some sort of array type and "i" is an integer). The new
setup just checks whether the "this" value is invalid, which does the type
check on the "this" value itself; in the "foo[i]->call_method()" case on
"foo[i]". We then adjust the exclusions in InvalidArg to consider operator->
on known-live things valid, to allow the thing that we were really trying to
accomplish with the "check for an operator call" bits:
"stackRefPtr->some_method()".
The test coverage being added for the made-up TArray type is meant to catch
things like the geolocation issue that was being hidden by the buggy behavior.
I'm not using nsTArray itself because some header included by nsTArray.h
tries to define operator new/delete bits inline and that triggers warnings that
then cause a clang-plugin test failure, because they're unexpected.
Differential Revision: https://phabricator.services.mozilla.com/D24117
--HG--
extra : moz-landing-system : lando
"this" is guaranteed to stay alive as long as other MOZ_CAN_RUN_SCRIPT
conditions hold, and its const members can't change value and drop
their refs.
Differential Revision: https://phabricator.services.mozilla.com/D23997
--HG--
extra : moz-landing-system : lando
We need to have full symbols uploaded for the upcoming EME-enabled
win64-aarch64 nightlies, and the tasks to do that are derived from the
nightly itself, which is going to be an artifact build. Bug 1527463 took
care of adding the option to enable that, and we turn it on for
EME-enabled builds.
MOZ_ARTIFACT_TASK_WIN32_OPT is not exactly the right thing, but we're
already using it to enable EME in
browser/config/mozconfigs/win64-aarch64/common-opt and is only set on
those builds.
Differential Revision: https://phabricator.services.mozilla.com/D23639
Since these are compile-time constants, they can't exactly go away on us due to
running script, right?
Differential Revision: https://phabricator.services.mozilla.com/D24195
--HG--
extra : moz-landing-system : lando
We need to typecheck the trivials too, not just the final thing after trivials
are stripped, because casts are trivials.
Differential Revision: https://phabricator.services.mozilla.com/D24186
--HG--
extra : moz-landing-system : lando
The old code for member method calls did the following:
1) Find the member method calls.
2) Look at their "this" expression.
3) If the "this" is an operator call, check for any of the arguments of the
operator call being invalid.
4) Otherwise (if not an operator call) check for the "this" value being
invalid.
This wasn't right, because the "is invalid" check checks the type and only
considers refcounted things. So if the code looked something like
"foo[i]->call_method()", we would look at the types of "foo" and "i" and
determine that none of those are refcounted types so there is nothing invalid
here (since "foo" is some sort of array type and "i" is an integer). The new
setup just checks whether the "this" value is invalid, which does the type
check on the "this" value itself; in the "foo[i]->call_method()" case on
"foo[i]". We then adjust the exclusions in InvalidArg to consider operator->
on known-live things valid, to allow the thing that we were really trying to
accomplish with the "check for an operator call" bits:
"stackRefPtr->some_method()".
The test coverage being added for the made-up TArray type is meant to catch
things like the geolocation issue that was being hidden by the buggy behavior.
I'm not using nsTArray itself because some header included by nsTArray.h
tries to define operator new/delete bits inline and that triggers warnings that
then cause a clang-plugin test failure, because they're unexpected.
Differential Revision: https://phabricator.services.mozilla.com/D24117
--HG--
extra : moz-landing-system : lando
"this" is guaranteed to stay alive as long as other MOZ_CAN_RUN_SCRIPT
conditions hold, and its const members can't change value and drop
their refs.
Differential Revision: https://phabricator.services.mozilla.com/D23997
--HG--
extra : moz-landing-system : lando
This allows calling a C++ MOZ_CAN_RUN_SCRIPT method that takes a callback argument.
The changes to TestCanRunScript.cpp are there to catch an incorrect change I was
going to make to the analysis to make this work, until I figured out that
RootedCallback should be MOZ_IS_SMARTPTR_TO_REFCOUNTED.
Differential Revision: https://phabricator.services.mozilla.com/D23519
--HG--
extra : moz-landing-system : lando
Without this flag, Android PGO profile-use builds may fail with
"Function control flow change detected" errors.
Differential Revision: https://phabricator.services.mozilla.com/D22816
--HG--
extra : moz-landing-system : lando
The file is essentially limited to ARM flag tweaks, so we make the
corresponding python configure code ARM-only. In large parts, the
python code sets things up similarly, although in a few places we try to
be smarter about than the current autoconf-based code.
The resulting config.status have been verified to only have
insignificant differences on both arm and aarch64 android builds.
Depends on D24000
Differential Revision: https://phabricator.services.mozilla.com/D24001
--HG--
extra : moz-landing-system : lando
The file is essentially limited to ARM flag tweaks, so we make the
corresponding python configure code ARM-only. In large parts, the
python code sets things up similarly, although in a few places we try to
be smarter about than the current autoconf-based code.
The resulting config.status have been verified to only have
insignificant differences on both arm and aarch64 android builds.
Depends on D24000
Differential Revision: https://phabricator.services.mozilla.com/D24001
--HG--
extra : moz-landing-system : lando
See https://bugs.llvm.org/show_bug.cgi?id=38944. clang thought it could safely leave out type information for some of our classes, but that information would have been helpful for debugging. The flag in this patch turns off the debug-info limiting.
Differential Revision: https://phabricator.services.mozilla.com/D24073
--HG--
extra : moz-landing-system : lando
Without this flag, Android PGO profile-use builds may fail with
"Function control flow change detected" errors.
Differential Revision: https://phabricator.services.mozilla.com/D22816
--HG--
extra : source : 3dfc0e4f8e7c8cd48b911033222fb3c3edb9762b
In at least some libstdc++ versions, std::pair (which we want to be
memmovable) inherits from __pair_base. We have a similar setup
already for __atomic_base.
Differential Revision: https://phabricator.services.mozilla.com/D23698
--HG--
extra : moz-landing-system : lando
We do this to encourage clang to find an new-enough linker instead of
the system one.
Differential Revision: https://phabricator.services.mozilla.com/D22881
--HG--
extra : moz-landing-system : lando
We want our clang bootstrap to use the GCC headers we're building with,
not whatever sysroot it happens to find on the server we're building on.
The -gcc-toolchain argument we specify when building clang will also be
picked up by llvm-config, so we need to strip it out when building the
plugin. Otherwise, we will get peculiar failures about not being able to
find C++ header files.
Differential Revision: https://phabricator.services.mozilla.com/D22880
--HG--
extra : moz-landing-system : lando
Explicit is better than implicit, and helps ensure that GCC is always
using the binutils we built it with, rather than the system binutils.
Differential Revision: https://phabricator.services.mozilla.com/D22879
--HG--
extra : moz-landing-system : lando
Updating clang indicates that 32-bit compilation is substantially longer
than 64-bit compilation, perhaps due to swapping. The compilation
process is hitting the timeout limit shortly before the compilation
process completes (~3681/3695 tasks according to ninja).
We could tweak our clang build process to accommodate this job. But we
don't support building on 32-bit Windows anymore, and we don't produce a
32-bit Windows clang either. So we shouldn't support a 32-bit Windows
clang-tidy job either. Let's get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D23517
--HG--
extra : moz-landing-system : lando
We do this to encourage clang to find an new-enough linker instead of
the system one.
Differential Revision: https://phabricator.services.mozilla.com/D22881
--HG--
extra : moz-landing-system : lando
We want our clang bootstrap to use the GCC headers we're building with,
not whatever sysroot it happens to find on the server we're building on.
The -gcc-toolchain argument we specify when building clang will also be
picked up by llvm-config, so we need to strip it out when building the
plugin. Otherwise, we will get peculiar failures about not being able to
find C++ header files.
Depends on D22879
Differential Revision: https://phabricator.services.mozilla.com/D22880
--HG--
extra : moz-landing-system : lando
Explicit is better than implicit, and helps ensure that GCC is always
using the binutils we built it with, rather than the system binutils.
Differential Revision: https://phabricator.services.mozilla.com/D22879
--HG--
extra : moz-landing-system : lando
The only place we'd need the compat libraries would be for host
binaries, and those shouldn't be a problem given that our system images
are new enough.
Differential Revision: https://phabricator.services.mozilla.com/D22873
--HG--
extra : moz-landing-system : lando
A newer clang may require newer binutils than the system provides, so we
should ensure that we provide just such a binutils.
Differential Revision: https://phabricator.services.mozilla.com/D23393
--HG--
extra : moz-landing-system : lando
These toolchain tasks are the last ones using the historical
download-tools script from build/unix/build-gcc, which invokes gpg to
validate the downloaded tarballs. The consequence is that gpg-agent is
spawned and stays running, preventing a cleanup script from doing its
job, making the tasks fail.
Fetches are the new way to download sources, and can also do gpg
validation without those caveats.
The download-tools.sh script can then be removed as it's not used
anymore.
Differential Revision: https://phabricator.services.mozilla.com/D22682
--HG--
extra : moz-landing-system : lando
This way if a caller calls a method that has a MOZ_CAN_RUN_SCRIPT override, it
can detect that it's possibly calling a MOZ_CAN_RUN_SCRIPT thing without having
to know about the override.
Differential Revision: https://phabricator.services.mozilla.com/D22839
--HG--
extra : moz-landing-system : lando
It's occasionally useful to know what versions are being discovered for
these variables. It's also convenient for logs from automation to
contain all the relevant information, rather than setting up a loaner
and running all the commands yourself.
Differential Revision: https://phabricator.services.mozilla.com/D22385
--HG--
extra : moz-landing-system : lando
Artifact mozconfigs are not necessarily up-to-date wrt changes to the
nightly mozconfigs, and all in all, shouldn't be much different from
them.
It's just better to use the nightly mozconfigs (or beta on beta, etc.)
and make the mozconfigs themselves handle the few things that need to be
different when the USE_ARTIFACT environment is set (which is now
consistently set by taskcluster)
This does have the side effect of turning builds that actually don't
support artifact builds red when using --artifact on try, instead of
having them silently not be artifact builds as currently happens.
Depends on D21314
Differential Revision: https://phabricator.services.mozilla.com/D21315
--HG--
extra : moz-landing-system : lando
The artifact builds that are automatically derived using the artifact
template set the USE_ARTIFACT environment variable from taskcluster.
After the previous change, --artifact builds from try syntax do that
too.
That leaves us with only the artifact-build build not doing it, so for
consistency, do it there. That makes it not necessary to set
USE_ARTIFACT from mozconfig.artifact.automation anymore.
Depends on D22056
Differential Revision: https://phabricator.services.mozilla.com/D21313
--HG--
extra : moz-landing-system : lando
The existing ANR and tombstone checks in remoteautomation are used
by mochitests and reftests but are awkward for other harnesses like cppunit
that do not use remoteautomation...and easily missed. This patch moves that
code to the mozharness AndroidMixin, treating ANRs and tombstones like the
logcat: Make sure any old logs are deleted when the mozharness script starts,
then move any logs found at the end of the run to the upload directory.
https://treeherder.mozilla.org/#/jobs?repo=try&tier=1%2C2%2C3&revision=f3de1e9836da2b0c9232f5d92c751b979459e19b
demonstrates tombstone artifacts for the Android 7.0 cppunit tests.
Differential Revision: https://phabricator.services.mozilla.com/D21774
--HG--
extra : moz-landing-system : lando
Optimizing jars without preloading/reordering data only moves the
jar central directory to the beginning of the file, which, without
preloading information, is not very useful. Let's just stop doing it if
there's not going to be preloading/reordering information at all.
Differential Revision: https://phabricator.services.mozilla.com/D21170
--HG--
extra : moz-landing-system : lando
This patch adds detection for when icecream is in use to build telemetry.
icecream is commonly enabled in two ways: by either setting CC/CXX to point
to icecream's cc/c++ symlinks, or by setting adding
mk_add_options 'export CCACHE_PREFIX=icecc' to a mozconfig when also using
ccache. For the former, this patch adds a simple configure check to see
if CXX is a symlink to a file named 'icecc'. For the latter this patch adds
CCACHE_PREFIX as a configure subst to capture the value.
We don't currently have a facility for writing telemetry tests that depend on
configure values. Local manual testing shows that it does work as expected.
Differential Revision: https://phabricator.services.mozilla.com/D18138
--HG--
extra : moz-landing-system : lando
Android requires us to use -fprofile-generate / -fprofile-use instead of
-fprofile-instr-generate / -fprofile-instr-use. Additionally, we have
to pass in the path to write out the profile data as /data/local/tmp,
since the cwd from where the Fennec process is invoked is not writeable.
Differential Revision: https://phabricator.services.mozilla.com/D20697
--HG--
extra : moz-landing-system : lando
In bug 1522354, we changed host and target detection to not invoke
config.sub, assuming the output from config.guess would satisfy our
needs in split_target.
It turns out that on some plaforms, that doesn't work out, so, while we
still skip config.sub, we now catch errors from split_target when doing
so, and try again after running config.sub when split_target fails.
Differential Revision: https://phabricator.services.mozilla.com/D19937
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
When the build system compiler is clang, and bindgen autodetection
actually finds a different clang via llvm-config, or a different clang
was given with --with-clang-path, we do want the proper flags to be
used for that clang, so we always get the right flags for that clang
instead of trying to shortcut.
Bug 1526857 will take care of making things more proper, while this is a
quick fix to unbreak builds in some unfortunately common kind of local
setups.
Differential Revision: https://phabricator.services.mozilla.com/D19328
--HG--
extra : moz-landing-system : lando
libclang 3.9 has a bug that makes bindgen unable to distinguish some typedefs
from the underlying type, which matters for bug 1523071.
We have had quite a few workarounds for this bug and I don't really want to add
more, since in this case it is non-trivial. I think requiring libclang 4.0+ is
reasonable at this point.
Of the distros that can't build Firefox out of the box with clang, dropping support
for clang 3.9 would only break Ubuntu 14.04 LTS, which support ends April 2019,
right before we release 67.
Differential Revision: https://phabricator.services.mozilla.com/D18889
--HG--
rename : build/build-clang/clang-3.9-linux64.json => build/build-clang/clang-4.0-linux64.json
rename : taskcluster/scripts/misc/build-clang-3.9-linux.sh => taskcluster/scripts/misc/build-clang-4.0-linux.sh
extra : moz-landing-system : lando
These are copies of the corresponding gcc-based base toolchain tasks,
with FORCE_GCC and the gcc dependency removed.
We also tweak things a little for those builds to actually end up green.
Differential Revision: https://phabricator.services.mozilla.com/D18903
--HG--
extra : moz-landing-system : lando
This apparently was necessary back when Android support was added 8.5
years ago, but is not desirable as a flag set globally. But it turns out
everything builds just fine without it now.
Differential Revision: https://phabricator.services.mozilla.com/D19128
--HG--
extra : moz-landing-system : lando
These are copies of the corresponding gcc-based base toolchain tasks,
with FORCE_GCC and the gcc dependency removed.
We also tweak things a little for those builds to actually end up green.
Differential Revision: https://phabricator.services.mozilla.com/D18903
--HG--
extra : moz-landing-system : lando
basic_bindgen_cflags's function is to set some flags for use with
rust-bindgen through clang/libclang for C++ code. Part of the flags it
sets are for the C++ standard, and the target.
Unfortunately, some of the logic wrt target-specific flags is currently
broken. It wants to apply per-compiler flags on Windows, but fails to do
so. First, because the condition test is wrong, and second, because it
only cares about msvc and not clang-cl.
OTOH, we already have those flags when the compiler is clang or
clang-cl. And we already have code to get the right flags for a given
compiler. So when the compiler is not clang or clang-cl, we can use that
to get the right flags for the clang we're going to use for bindgen.
Depends on D18316
Differential Revision: https://phabricator.services.mozilla.com/D18317
--HG--
extra : moz-landing-system : lando
In upcoming changes, we're going to use the normal compiler flags for
bindgen instead of having a separate logic for essentially the same
flags (and there's not much reason not to use the same flags after all).
One hiccup, though is that for some reason, --target=i686-linux-gnu
doesn't work with bindgen while it works with clang in the same setup.
But -m32 does.
Considering -m32 and -m64 are standard flags and that we're using them
in many cases, it doesn't hurt to use them instead of --target with
clang.
While we're doing that, we might as well refactor a little to avoid the
multiple branches handling the use of -m32/-m64, and fix the theoretical
compile-x86_64-with-x86-clang-cl case, as well as the weird check for
aarch64.
And because only two cases actually require -Xclang, only one of which
requires a condition, and the control flow is not too complex to avoid
flag duplication, we just remove the append_flag function; it was too
confusing, with all the cases we skipped it when -Xclang was not wanted.
Differential Revision: https://phabricator.services.mozilla.com/D18316
--HG--
extra : moz-landing-system : lando
This removes all .flake8 files except for the one at the root of the repo.
Instead we use the new 'per-file-ignores' config introduced in 3.7. To ignore
specific errors in a subdirectory, add a line like this to the root .flake8:
[per-file-ignores]
path/to/subdir/*: E100, F200, ...
The reasons for this change are:
1. Unblock flake8 blacklist (bug 1367092).
2. Simplify configuration and code.
3. Encourage more consistent styling.
4. Improve performance.
5. Greater editor consistency.
Differential Revision: https://phabricator.services.mozilla.com/D18354
--HG--
extra : moz-landing-system : lando
Since ./mach bootstrap installs Android SDK into ~/.mozbuild, we should detect
this location as default SDK install path.
Also, --with-android-max-sdk and --with-android-min-sdk are still in android.m4
because confvars.sh sets MOZ_ANDROID_MIN_SDK_VERSION.
Differential Revision: https://phabricator.services.mozilla.com/D15463
--HG--
extra : moz-landing-system : lando
Sometimes we want to store state that only applies to a particular srcdir, but
there isn't a standard directory where this lives. Let's add an argument to
'get_state_dir()' to provide an "official" place.
The new API to get the local state dir is 'get_state_dir(srcdir=True)'. Like
the global state dir, this directory is not guaranteed to exist. A reference to
this value can also be obtained via 'self._mach_context.local_state_dir' from
within a mach command (in this case it will be created automatically if it
doesn't exist).
Note: we should probably just make sure both exist at mach startup, but it felt
outside the scope of this change.
Differential Revision: https://phabricator.services.mozilla.com/D15724
--HG--
extra : moz-landing-system : lando
mozboot.util.get_state_dir() returns a tuple of (<path>, <bool). The bool
denotes whether or not the state dir came from an environment variable.
But this value is only used in a single place, and is very easy to test for
anyway. It's not worth the added complexity it imposes on all other consumers
of this function. Let's just make this function return the path.
Differential Revision: https://phabricator.services.mozilla.com/D15723
--HG--
extra : moz-landing-system : lando
We default to -Zi for Windows debug flags, which is for generating debug info
into a PDB file, but clang-cl doesn't actually implement that so -Zi is
an alias for -Z7 in clang-cl:
http://clang.llvm.org/docs/UsersManual.html#id9
sccache has special handling for -Zi because multiple compiles writing
to the same PDB file is not cacheable, so we've always overridden -Zi with -Z7
in CI when using sccache.
Given that everyone should be using clang-cl nowadays and MSVC will no longer
be supported soon, this patch changes the default and removes some PDB
file name flag setting from rules.mk, as well as the no-longer-necessary
overrides from mozconfig.cache.
Differential Revision: https://phabricator.services.mozilla.com/D18264
--HG--
extra : moz-landing-system : lando
Also use armv7a as the default when no target is given at all.
Also change bootstrap to create a simpler mozconfig. The downside is
that the resulting mozconfig would not work when building older
revisions.
Add unit tests for this as well as the simplications added in bug
1523341.
Differential Revision: https://phabricator.services.mozilla.com/D17906
--HG--
extra : moz-landing-system : lando
While not related, it turns out this test was opted in by ourselves,
while it's practically useless. Recent autoconf documentation says it's
obsolescent, and even autoconf 2.13 documentation said with "recent
versions of the GNU C compiler", the issue it's detecting "is becoming
a less prevalent problem". Recent as of 20 years ago.
Differential Revision: https://phabricator.services.mozilla.com/D18054
--HG--
extra : moz-landing-system : lando
Now that everything is lined up nicely, we don't need those anymore.
We can fill cargo-linker.bat with HOST_LINKER and HOST_LINKER_LIBPATHS,
which, unfortunately, can't be used as is, so we add a variant for
substitution in .bat files.
Differential Revision: https://phabricator.services.mozilla.com/D18034
--HG--
extra : moz-landing-system : lando
Now that it's automatically derived and that in-tree mozconfigs are
setting DIA_SDK_PATH, we don't need to set WIN_DIA_SDK_BIN_DIR on
automation, or elsewhere, for that matter.
Differential Revision: https://phabricator.services.mozilla.com/D17915
--HG--
extra : moz-landing-system : lando
Clang 8 seems to generate destructor decls from different source
locations which breaks an assertion in the code. This patch updates the
code to remove the assertion and more robustly handle the new
declarations.
Differential Revision: https://phabricator.services.mozilla.com/D17902
--HG--
extra : moz-landing-system : lando
We reject MSVC compilers < 2017 already, there's no point checking for
smaller versions after that.
Differential Revision: https://phabricator.services.mozilla.com/D17770
--HG--
extra : moz-landing-system : lando
And remove all the variables that configure will figure out for us as a
consequence. This has the side effect of making the automation builds a
little more like local builds, in that they don't rely on preset PATH,
LIB, etc. for the build to work.
Differential Revision: https://phabricator.services.mozilla.com/D17789
--HG--
extra : moz-landing-system : lando
We currently rely on WIN_DIA_SDK_BIN_DIR being passed, but we can
actually derive it from the DIA SDK directory. So we now do that, except
when it's given explicitly.
While in the vicinity, move the dia2.h check to python configure.
With WIN_DIA_SDK_BIN_DIR being derived and not set when dia2.h is not
found, we don't really need MSVC_HAS_DIA_SDK anymore, so we just check
for WIN_DIA_SDK_BIN_DIR to determine whether to build dump_syms or not.
One exception to the above is when WIN_DIA_SDK_BIN_DIR is passed in,
which we only keep for the in-tree mozconfigs for now. We'll remove that
possibility after bug 1523201.
Depends on D17892
Differential Revision: https://phabricator.services.mozilla.com/D17893
--HG--
extra : moz-landing-system : lando
It turns out, we don't need to `mk_add_options export` the variables
from the in-tree mozconfigs. If anything, that causes problems when
trying to simplify the mozconfigs, because it makes the variables
exported from .mozconfig.mk, overriding what configure may change and
store in autoconf.mk.
All the variables are handled by configure in a way that makes them
available in autoconf.mk, so there's no loss there, and with the
python/shell-based mozconfig loader, it turns out we don't need to go
through extra normalization via cmd.
autospider.py, being its own pseudo-mozconfig parser, still does need
it, though, but it was hooking into it already, so just inline that.
Differential Revision: https://phabricator.services.mozilla.com/D17769
--HG--
extra : moz-landing-system : lando
Previously, we hardcoded HostX64 because configure would autodetect a
x86 host on x64 machines, but the x86 MSVC compiler wouldn't be
suitable.
While the x86 MSVC compiler might still not be suitable, now that
configure detects x64 hosts properly, when the configure host is
detected as x86, we can't even execute the x64 compiler, so we can at
least try with the x86 one correctly.
Differential Revision: https://phabricator.services.mozilla.com/D17788
--HG--
extra : moz-landing-system : lando
The combination of bug 1515579 and bug 1520394 made things harder for
old-configure, because it doesn't necessarily have a complete view of
the search PATH that has been used. This doesn't actually cause problems
on non-Windows builds because things work out fine, but on Windows,
some of the executions of clang-cl in old-configure insist on being able
to find a MSVC install. That, again, doesn't currently cause problems in
general on local builds because clang-cl finds it through the registry
(presumably), and on automation, because it's in the `mk_add_options
export`'ed PATH, but the latter is due to change.
Depends on D17772
Differential Revision: https://phabricator.services.mozilla.com/D17783
--HG--
extra : moz-landing-system : lando
Also, while here, replace subprocess.check_output with check_cmd_output.
Depends on D17771
Differential Revision: https://phabricator.services.mozilla.com/D17772
--HG--
extra : moz-landing-system : lando
Bug 1520394 changed things such that the configure sandbox is using a
copy of os.environ. So when mozconfig injects environment changes, they
only affect the sandbox. Which means when the which module uses
os.environ to get PATH, it gets the original unmodified environment.
So instead of relying on the which module getting PATH itself, we feed
it with it. It's worth noting that the which module adds `.` on Windows,
but we don't copy this behavior, because in the context of configure,
it's actually not important (`.` would be the topobjdir).
Differential Revision: https://phabricator.services.mozilla.com/D17771
--HG--
extra : moz-landing-system : lando
And use it as an alternative to vswhere, instead of the current late
check. This allows to use VC_PATH when using a MSVC archive that is not
installed through the VS installer, and not have to care about PATH.
Depends on D17786
Differential Revision: https://phabricator.services.mozilla.com/D17787
--HG--
extra : moz-landing-system : lando
- Only expose it as well as --with-visual-studio-version when the host
system is Windows.
- Don't run vswhere twice (once for host and once for target).
Depends on D17785
Differential Revision: https://phabricator.services.mozilla.com/D17786
--HG--
extra : moz-landing-system : lando
config.guess doesn't actually figure out the real host system on
Windows. All it does is end up finding the CPU for which the msys used
for the shell is built for. Which has the unfortunate effect that if you
build on a 64-bits host, configure pretends the host is 32-bits.
So instead, rely on some environment variables that should be set
mostly everywhere, and derive the corresponding triplet.
This has two effects:
- configure now knows that the host is 64-bits when it is.
- consequently, configure will build a 64-bits Firefox on 64-bits hosts
by default (since by default, the target is derived from the host), and
that's actually a desired side effect.
Depends on D17620
Differential Revision: https://phabricator.services.mozilla.com/D17621
--HG--
extra : moz-landing-system : lando
- We assume the output from config.guess is sufficiently normalized for
our needs.
- If we partially derive the target from the host (with only the cpu
given for --target), we assume the derived value doesn't need
canonicalization.
Differential Revision: https://phabricator.services.mozilla.com/D17620
--HG--
extra : moz-landing-system : lando
In fact, "simply" use whatever python configure does to find a shell to
execute config.guess and config.sub, and get both the mozconfig content
and the real, canonicalized target alias. This has the side effect of
making builds with --target=$cpu use a complete obj-$cpu-$os default
objdir instead of obj-$cpu. This will also allow to change the
host-guessing logic without having to duplicate code.
Differential Revision: https://phabricator.services.mozilla.com/D17618
--HG--
extra : moz-landing-system : lando
which, at this point, is only the AC_SUBST, so we don't even need to
give it to old-configure anymore.
Depends on D17207
Differential Revision: https://phabricator.services.mozilla.com/D17208
--HG--
extra : moz-landing-system : lando
which, at this point, is only the AC_SUBST, so we don't even need to
give it to old-configure anymore.
Depends on D17207
Differential Revision: https://phabricator.services.mozilla.com/D17208
--HG--
extra : moz-landing-system : lando
Because old-configure is only refreshed when, essentially,
old-configure.in changes, hardcoded (absolute) paths don't necessarily
match the build environment of the current build.
So instead, use an environment variable that we pass from python
configure when invoking old-configure.
Also do dummy changes to old-configure.in so that old-configure is
refreshed at least once to get the environment-based value.
Differential Revision: https://phabricator.services.mozilla.com/D17077
--HG--
extra : moz-landing-system : lando
Back when those were added, option defaults could not indirectly depend
on `target` or `host`, but that changed with bug 1322025.
As a side effect, this allows to turn them into straight js_options
without resorting to the manual add_old_configure_arg.
Differential Revision: https://phabricator.services.mozilla.com/D16664
--HG--
extra : moz-landing-system : lando
Rust ships with some natvis files that enable nicer display of Rust standard
library types in Microsoft's debuggers. rustc will add the right linker
options to include them when it invokes the linker but since we don't link
libxul with rustc we need to explicitly pass them to the linker ourselves.
This change locates all natvis files in the Rust sysroot and adds them
to the libxul link line.
Differential Revision: https://phabricator.services.mozilla.com/D16544
--HG--
extra : moz-landing-system : lando
Add a dummy change to old-configure.in so that old-configure is
force-refreshed.
Differential Revision: https://phabricator.services.mozilla.com/D16797
--HG--
extra : moz-landing-system : lando
Back when those were added, option defaults could not indirectly depend
on `target` or `host`, but that changed with bug 1322025.
As a side effect, this allows to turn them into straight js_options
without resorting to the manual add_old_configure_arg.
Differential Revision: https://phabricator.services.mozilla.com/D16664
--HG--
extra : moz-landing-system : lando
Before bug 1322025, running configure --help along --host and/or
--target would show the options that are specific to the
host/target/cross-compilation (e.g. those with when=target_is_windows)
which was convenient. Bug 1322025 unfortunately broke that, and this
restores the feature.
Differential Revision: https://phabricator.services.mozilla.com/D16673
--HG--
extra : moz-landing-system : lando
Instead, use the actual log file name as configured through python
logging. This doesn't make a practical difference now, but will when
subconfigure logs to the toplevel log.
Depends on D16666
Differential Revision: https://phabricator.services.mozilla.com/D16667
--HG--
extra : moz-landing-system : lando
We're going to want to log some more. At the moment, this just adds the
output of subconfigure to top-level config.log, but this will become
more useful down the road.
Depends on D16665
Differential Revision: https://phabricator.services.mozilla.com/D16666
--HG--
extra : moz-landing-system : lando
Back when those were added, option defaults could not indirectly depend
on `target` or `host`, but that changed with bug 1322025.
As a side effect, this allows to turn them into straight js_options
without resorting to the manual add_old_configure_arg.
Differential Revision: https://phabricator.services.mozilla.com/D16664
--HG--
extra : moz-landing-system : lando
Use an I/O wrapper on the configure output handler to add the "js/src>"
prefix.
Depends on D16643
Differential Revision: https://phabricator.services.mozilla.com/D16644
--HG--
extra : moz-landing-system : lando
It was manually removed because autoconf's AC_OUTPUT_SUBDIRS passes it,
but we've not been using AC_OUTPUT_SUBDIRS for a while.
Depends on D16637
Differential Revision: https://phabricator.services.mozilla.com/D16638
--HG--
extra : moz-landing-system : lando
The code only actually handles autoconf 2.5 cache, and was useful when
we have such subconfigures, that would die when things changed in ways
that would make the subconfigure abort on its own. But we have no such
things left, and while we may want to clear the cache for old-configure
(for e.g. bug 1520232), this is not helping to get there.
Differential Revision: https://phabricator.services.mozilla.com/D16636
--HG--
extra : moz-landing-system : lando
Instead, include the module and inline its main function.
Depends on D16622
Differential Revision: https://phabricator.services.mozilla.com/D16623
--HG--
extra : moz-landing-system : lando
This happens to remove the last use of perl from configure.
Depends on D16621
Differential Revision: https://phabricator.services.mozilla.com/D16622
--HG--
extra : moz-landing-system : lando
The File class is now used only in one place, only for its mtime
property, which can be replaced with os.path.getmtime.
Depends on D16402
Differential Revision: https://phabricator.services.mozilla.com/D16403
--HG--
extra : moz-landing-system : lando
Because subconfigure.py is only used for js/src and we're not going to
add any more subconfigures, we can hardcode js/src into the script, and
remove the branches that aren't taken as a consequence.
Depends on D16382
Differential Revision: https://phabricator.services.mozilla.com/D16402
--HG--
extra : moz-landing-system : lando
It was useful to run the prepare phase and the actual subconfigure
separately, but it's not anymore after all the recent simplications.
Depends on D16381
Differential Revision: https://phabricator.services.mozilla.com/D16382
--HG--
extra : moz-landing-system : lando
Because we only ever run one subconfigure, the machinery to execute
several is not useful anymore. Inlining it allows to simplify the code
too, because it doesn't need to be generic anymore. This also removes
the last remaining bits of acwinpaths.m4.
Also remove now unused support for --list in build/subconfigure.py.
Depends on D16380
Differential Revision: https://phabricator.services.mozilla.com/D16381
--HG--
extra : moz-landing-system : lando
We only run it for js/src now, so get_config_files always returns empty lists.
Depends on D16378
Differential Revision: https://phabricator.services.mozilla.com/D16379
--HG--
extra : moz-landing-system : lando
This only affects the compiler version in the build system; not the
version reported by the compiler.
--HG--
extra : histedit_source : 37fc1a2090d872ca5e95d022e9f93b620b2d8dbb
When doing cross-compiles for Desktop, system pkg-config is going to be
looking for .pc files for the host, but systems setup for cross-compiles
come with a toolchain-prefixed pkg-config, which we should be looking
for.
Differential Revision: https://phabricator.services.mozilla.com/D16318
--HG--
extra : moz-landing-system : lando
When doing cross-compiles for Desktop, system pkg-config is going to be
looking for .pc files for the host, but systems setup for cross-compiles
come with a toolchain-prefixed pkg-config, which we should be looking
for.
Differential Revision: https://phabricator.services.mozilla.com/D16318
--HG--
extra : moz-landing-system : lando
MOZ_D3D_CPU_SUFFIX and MOZ_HAS_WINSDK_WITH_D3D are not used in the
build, and nothing includes d3d10.h except some angle code in a
preprocessed branch that is only taken for a macro we never define,
so we don't move the code corresponding to those. We also simplify the
detection code, which is convoluted now that it doesn't search for
multiple different DLLs.
Differential Revision: https://phabricator.services.mozilla.com/D16295
--HG--
extra : moz-landing-system : lando
In bug 1494022 there are problems using an SDK that is too new, which
can cause developers to spend many hours debugging an issue that we
could've checked up front.
This patch gets the version from the SDKSettings.plist file at the root
of the SDK directory, and checks it against min and max supported
versions.
The current min version is 10.11, since that is what we build with in
automation. The current max version is 10.13, since 10.14+ currently has
an issue with a black screen at startup.
Differential Revision: https://phabricator.services.mozilla.com/D16140
--HG--
extra : moz-landing-system : lando
Because MSVC compilers only support one architecture, we need to search
"cl" in different toolchain search paths for each of the host and
target, especially when they are different.
Likewise for the library paths for the linker. Ideally we'd pass
-LIBPATH both for host and target, but that has implications for rust
that I don't want to have to figure just now.
Depends on D15263
Differential Revision: https://phabricator.services.mozilla.com/D15264
--HG--
extra : moz-landing-system : lando
While it was preferable to use lld-link with msvc for performance
reasons when we defaulted to compile with msvc, now that we build with
clang-cl by default, it's now better to use msvc's linker when using
msvc's compiler, especially for aarch64, which is the last place where
we actually need msvc.
Differential Revision: https://phabricator.services.mozilla.com/D15262
--HG--
extra : moz-landing-system : lando
In bug 1259382, some workarounds were added to make the build system
alter PATH and not use absolute paths for toolchain programs, because
autoconf and the build system doesn't deal with spaces in those very
well. But later in bug 1290040, we made find_program return Windows
short paths (without spaces), which alleviates the need for those
workarounds.
We still, however, and unfortunately, need to alter PATH to account for
the fact that MSVC DLLs are not necessarily alongside the compiler
executables...
Depends on D15181
Differential Revision: https://phabricator.services.mozilla.com/D15182
--HG--
extra : moz-landing-system : lando
Like for other windows platforms. This currently doesn't make a
difference, but will with next change.
Differential Revision: https://phabricator.services.mozilla.com/D15181
--HG--
extra : moz-landing-system : lando
LLVM_PROFDATA needs the toolchain search dir, per bug 1515579.
Also, most of the options actually don't do anything useful with
artifact builds. In fact, the only one that artifact builds would need
is MOZ_PGO. So we move to options back to toolchain.configure, somewhere
late enough ; except MOZ_PGO, that we move to the top-level
moz.configure (because we don't need a separate file for one option).
Differential Revision: https://phabricator.services.mozilla.com/D16152
--HG--
extra : moz-landing-system : lando
Firefox uses multiple processes. It has intentional leaks, and when
running with ASAN, we have suppressions to eliminate those. When running
ASAN builds through CI tests, when Firefox exits, each of the processes
(parent and child) exits and goes through its leaks and when there are
(which is a given), the ASAN runtime runs llvm-symbolizer to symbolicate
and match against suppressions. So each process runs llvm-symbolizer. At
the same time.
Some of the addresses to symbolicate are in libxul. Which contains all
DWARF info, making it a ~1GB monster. Oh, and because you're lucky,
things align perfectly such that libxul size is a multiple of the page
size. That makes llvm-symbolizer pread() the file instead of mmap()ing
it. Did I say there are multiple processes? So suddenly you have n
processes simultaneously allocating and filling 1GB of memory each, on
CI machines that have enough memory for the job they usually run, but
not enough for a sudden rush of n GB.
And things go awry. When you're lucky and the OOM killer didn't take
care of killing the CI entirely, symbolication couldn't happen and the
suppressions are not matched, and leaks are reported.
This all turns out it originates in how llvm-symbolicate chooses between
pread() and mmap(), which turns out is just defaults not being made for
binary files.
Differential Revision: https://phabricator.services.mozilla.com/D16010
--HG--
extra : moz-landing-system : lando
In bug 1514288 we started to save the output from running Firefox during
PGO builds into log files, but they aren't correctly uploaded if the run
fails. This presents a problem for categorizing failed PGO builds if the
profileserver returns an error code (eg: bug 1517939), since the error
messages could be hidden away in log files that aren't uploaded.
Instead, we can generate them directly into the artifacts directory so
that they are always uploaded. Additionally, the log files are displayed
if the run fails so that the error messages are displayed in the log for
easier bug categorization.
Differential Revision: https://phabricator.services.mozilla.com/D15881
--HG--
extra : moz-landing-system : lando
Instead of per-document. This also allows to reuse this thread-pool if needed
for other stuff, like parallel CSS parsing (#22478), and to share more code with
Gecko, which is always nice.
This cherry-picks https://github.com/servo/servo/pull/22487, with a few minor
fixes to the build that are landing as part of the sync associated to this bug,
and an lsan exception tweak to point to the right module since it's moving.
The output from running the browser during PGO builds can have innocuous
error messages in them, but show up in treeherder as potential messages
to include when filing bugs. We can just save the output from these runs
as files and upload them as artifacts instead, so they don't show up in
the build log but are available for inspection if necessary.
MozReview-Commit-ID: 3VdVCKVkZNI
Differential Revision: https://phabricator.services.mozilla.com/D15154
--HG--
extra : moz-landing-system : lando
In bug 1259382, some workarounds were added to make the build system
alter PATH and not use absolute paths for toolchain programs, because
autoconf and the build system doesn't deal with spaces in those very
well. But later in bug 1290040, we made find_program return Windows
short paths (without spaces), which alleviates the need for those
workarounds.
We still, however, and unfortunately, need to alter PATH to account for
the fact that MSVC DLLs are not necessarily alongside the compiler
executables...
Depends on D15181
Differential Revision: https://phabricator.services.mozilla.com/D15182
--HG--
extra : moz-landing-system : lando
Like for other windows platforms. This currently doesn't make a
difference, but will with next change.
Differential Revision: https://phabricator.services.mozilla.com/D15181
--HG--
extra : moz-landing-system : lando
We remove --disable-libjpeg-turbo because that's only useful when Yasm
is too old, and the required version is now almost 8 years old, so we
can reasonably require people to upgrade rather than workaround with a
--disable option.
The valid_yasm_version function can seem overkill, but that's because
future moves of other things to python configure will pile up.
Differential Revision: https://phabricator.services.mozilla.com/D15184
--HG--
extra : moz-landing-system : lando
Now that we're not even building host static libraries, we don't need
variables for the tools used to build them.
Ironically, we weren't even running HOST_RANLIB.
Depends on D15172
Differential Revision: https://phabricator.services.mozilla.com/D15173
--HG--
extra : moz-landing-system : lando
So far, the main subject of cross-compiles was to cross compile from one
OS to another (e.g. {linux,osx} -> android), but there are a few useful
cases where the OS doesn't change, and, with --host being guessed, we
can just have developers pass --target=$cpu instead of a complete
target triplet. This can be useful to do x86 Linux builds on x86-64
Linux hosts, or aarch64 Windows builds on x86-64 Windows hosts.
Differential Revision: https://phabricator.services.mozilla.com/D15063
--HG--
extra : moz-landing-system : lando
Nick Alexander
Ryan VanderMeulen
Kartikaya Gupta
Razvan Maries
Mike Shal
Dan Minor
Rob Thijssen
Sylvestre Ledru
Geoff Brown
Mike Hommey
Nathan Froyd
Bobby Holley
Mark Banner
Cosmin Sabou
Gabriele Svelto
Ehsan Akhgari
Jesse Schwartzentruber
Emilio Cobos Álvarez
Eric Rahm
Chris Manchester
Oana Pop Rus
Mike Shal
Daniel Varga
Csoregi Natalia
Tom Prince
Andreea Pavel
Masatoshi Kimura
Christian Holler
Noemi Erli
Andi-Bogdan Postelnicu
Ciure Andrei
Thomas Daede
Boris Zbarsky
Gurzau Raul
David Major
Coroiu Cristina
Makoto Kato
Nicholas Nethercote
shindli
Brindusan Cristian
Wes Kocher
Gian-Carlo Pascutto
Nathan Froyd
Carolina Jimenez Gomez
James Willcox
Johann Hofmann
Ted Mielczarek
Bogdan Tara
Chris Hartjes
Marco Castelluccio
Dorel Luca
arthur.iakab
Kris Maglione
Andrew Halberstadt
Tom Ritter
Alex Chronopoulos
Sebastian Hengst
Jan Henning
Margareta Eliza Balazs
Dustin J. Mitchell
Narcis Beleuzu