After removing `optional` in Bug 1712804, we need to add a variant back
here because there's fallible dependencies. However, I've tweaked the
re-introduction of the feature to require a specific repercussion
message as well. This seemed like a decent tradeoff - the developer
becomes aware that the failure is bad, it has repercussions, but it's
not a blocking issue. Additionally, since we're printing pip's output,
the developer will be able to see the underlying error causing the
warning.
I also added comment functionality to requirements definitions to allow
adjacent documentation of why some requirements are fallible. (Related:
I'm looking forward to `mach_bootstrap` not needing to parse
requirements definitions. Almost there!)
Note that we'll temporarily lose the "pinned" nature of the
three moved dependencies until dependency locking is implemented
for Mach requirements definitions. Also note that the pinned
`zstandard_requirements.txt` can't be removed like the other
files because it still has a dangling usage.
Finally, in preparation for review: I didn't make
`PypiOptionalSpecifier` extend `PypiSpecifier` because I figured that
the benefit of flexibility (easier to allow implementations to diverge
without needing to untangle an inheritance relationship) was larger than
the cost of needing to add properties to both specifiers.
If we wanted re-use, I'd probably have `PypiOptionalSpecifier` _contain_
a `PypiSpecifier`, but then you have to reach deeper into the object to
get data, so *shrug*.
Differential Revision: https://phabricator.services.mozilla.com/D119835
The three removed paths don't exist in-repo, and after a cursory glance
they don't appear to be populated dynamically.
Note that the removal of the `six` path for WPT is different: it's
technically just incorrect, and should amended to point to
`$WPT/tools/third_party/six`. However, Python only allows a single
instance of a library to exist in import scope, and we're already
consuming `six` from the Firefox-wide vendored 3rd-party libs.
Differential Revision: https://phabricator.services.mozilla.com/D119825
After removing `optional` in Bug 1712804, we need to add a variant back
here because there's fallible dependencies. However, I've tweaked the
re-introduction of the feature to require a specific repercussion
message as well. This seemed like a decent tradeoff - the developer
becomes aware that the failure is bad, it has repercussions, but it's
not a blocking issue. Additionally, since we're printing pip's output,
the developer will be able to see the underlying error causing the
warning.
I also added comment functionality to requirements definitions to allow
adjacent documentation of why some requirements are fallible. (Related:
I'm looking forward to `mach_bootstrap` not needing to parse
requirements definitions. Almost there!)
Note that we'll temporarily lose the "pinned" nature of the
three moved dependencies until dependency locking is implemented
for Mach requirements definitions. Also note that the pinned
`zstandard_requirements.txt` can't be removed like the other
files because it still has a dangling usage.
Finally, in preparation for review: I didn't make
`PypiOptionalSpecifier` extend `PypiSpecifier` because I figured that
the benefit of flexibility (easier to allow implementations to diverge
without needing to untangle an inheritance relationship) was larger than
the cost of needing to add properties to both specifiers.
If we wanted re-use, I'd probably have `PypiOptionalSpecifier` _contain_
a `PypiSpecifier`, but then you have to reach deeper into the object to
get data, so *shrug*.
Differential Revision: https://phabricator.services.mozilla.com/D119835
The three removed paths don't exist in-repo, and after a cursory glance
they don't appear to be populated dynamically.
Note that the removal of the `six` path for WPT is different: it's
technically just incorrect, and should amended to point to
`$WPT/tools/third_party/six`. However, Python only allows a single
instance of a library to exist in import scope, and we're already
consuming `six` from the Firefox-wide vendored 3rd-party libs.
Differential Revision: https://phabricator.services.mozilla.com/D119825
Originally, we only were using bindgen for stylo, and we also went a bit
overkill by including a lot of extra CFLAGS in there, which end up
being unnecessary. So we now only pass a more minimal set of flags, and
add some extra CFLAGS in cases where they are necessary.
Differential Revision: https://phabricator.services.mozilla.com/D121043
While the use of toml allows the flags to be separated, the split is
done via some shell shenanigans anyways, and servo's build.rs can
handle the same just fine.
Differential Revision: https://phabricator.services.mozilla.com/D121042
We do that with everything else (i.e. clang, cbindgen, etc.). We weren't
doing it for sysroots because the support was experimental and the path
was independent of the target, so there was no guarantee that the
sysroot would actually work for the target. As that's not the case
anymore, we can go with more consistency with the bootstrapped
toolchains.
Differential Revision: https://phabricator.services.mozilla.com/D120417
After removing `optional` in Bug 1712804, we need to add a variant back
here because there's fallible dependencies. However, I've tweaked the
re-introduction of the feature to require a specific repercussion
message as well. This seemed like a decent tradeoff - the developer
becomes aware that the failure is bad, it has repercussions, but it's
not a blocking issue. Additionally, since we're printing pip's output,
the developer will be able to see the underlying error causing the
warning.
I also added comment functionality to requirements definitions to allow
adjacent documentation of why some requirements are fallible. (Related:
I'm looking forward to `mach_bootstrap` not needing to parse
requirements definitions. Almost there!)
Note that we'll temporarily lose the "pinned" nature of the
three moved dependencies until dependency locking is implemented
for Mach requirements definitions. Also note that the pinned
`zstandard_requirements.txt` can't be removed like the other
files because it still has a dangling usage.
Finally, in preparation for review: I didn't make
`PypiOptionalSpecifier` extend `PypiSpecifier` because I figured that
the benefit of flexibility (easier to allow implementations to diverge
without needing to untangle an inheritance relationship) was larger than
the cost of needing to add properties to both specifiers.
If we wanted re-use, I'd probably have `PypiOptionalSpecifier` _contain_
a `PypiSpecifier`, but then you have to reach deeper into the object to
get data, so *shrug*.
Differential Revision: https://phabricator.services.mozilla.com/D119835
The three removed paths don't exist in-repo, and after a cursory glance
they don't appear to be populated dynamically.
Note that the removal of the `six` path for WPT is different: it's
technically just incorrect, and should amended to point to
`$WPT/tools/third_party/six`. However, Python only allows a single
instance of a library to exist in import scope, and we're already
consuming `six` from the Firefox-wide vendored 3rd-party libs.
Differential Revision: https://phabricator.services.mozilla.com/D119825
After removing `optional` in Bug 1712804, we need to add a variant back
here because there's fallible dependencies. However, I've tweaked the
re-introduction of the feature to require a specific repercussion
message as well. This seemed like a decent tradeoff - the developer
becomes aware that the failure is bad, it has repercussions, but it's
not a blocking issue. Additionally, since we're printing pip's output,
the developer will be able to see the underlying error causing the
warning.
I also added comment functionality to requirements definitions to allow
adjacent documentation of why some requirements are fallible. (Related:
I'm looking forward to `mach_bootstrap` not needing to parse
requirements definitions. Almost there!)
Note that we'll temporarily lose the "pinned" nature of the
three moved dependencies until dependency locking is implemented
for Mach requirements definitions. Also note that the pinned
`zstandard_requirements.txt` can't be removed like the other
files because it still has a dangling usage.
Finally, in preparation for review: I didn't make
`PypiOptionalSpecifier` extend `PypiSpecifier` because I figured that
the benefit of flexibility (easier to allow implementations to diverge
without needing to untangle an inheritance relationship) was larger than
the cost of needing to add properties to both specifiers.
If we wanted re-use, I'd probably have `PypiOptionalSpecifier` _contain_
a `PypiSpecifier`, but then you have to reach deeper into the object to
get data, so *shrug*.
Differential Revision: https://phabricator.services.mozilla.com/D119835
The three removed paths don't exist in-repo, and after a cursory glance
they don't appear to be populated dynamically.
Note that the removal of the `six` path for WPT is different: it's
technically just incorrect, and should amended to point to
`$WPT/tools/third_party/six`. However, Python only allows a single
instance of a library to exist in import scope, and we're already
consuming `six` from the Firefox-wide vendored 3rd-party libs.
Differential Revision: https://phabricator.services.mozilla.com/D119825
The background hang monitor uses the same timing thresholds as the one used by
the compositor thread, for similar reasons.
Differential Revision: https://phabricator.services.mozilla.com/D120117
This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
We will only run the processes in CET compatible modules only mode when not
using the JIT code. So marking xul.dll as compatible should be OK.
Differential Revision: https://phabricator.services.mozilla.com/D117551
Clang >= 11 ignores PYTHON_EXECUTABLE entirely (and uses python3, which
is not even what we pass, but that's actually fine), and all the build
tasks we have on older versions find the python executable they need on
their own.
Differential Revision: https://phabricator.services.mozilla.com/D120049
I'm guessing that the code moved to the bootstrap command but the
associated comment was forgotten and left abandoned, which is very sad.
Differential Revision: https://phabricator.services.mozilla.com/D120098
There's a "minimum Python check" that happens when Mach
bootstraps that makes the bootstrap command's check obsolete.
Since we want to use modern Python features throughout Mach, we need to
move Python-out-of-date logic up to the front of the process.
We're duplicating the OS-detection logic a bit, but now we regain
per-platform Python instructions.
Differential Revision: https://phabricator.services.mozilla.com/D120093
Bug 1692137 added code that would end up calling
toolchain_task_definitions twice, once for each of host and target.
With the recent changes from bug 1719229, that is not useful anymore.
We also don't need the toolchain prefixes for toolchains on unsupported
hosts (which were useful before bug 1719229 for the target sysroots).
Differential Revision: https://phabricator.services.mozilla.com/D120044
This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
It turns out calling gdk_display_close gets us a rematch of bug 1626536,
so remove the call that was added in bug 1718131, and adjust valgrind
suppressions accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D120037
After changeset 5e4b33fe9218703f0b29e2446159bcf4202d15fa the Attributes.cpp file was
changed so our patched version was not sticking on top of it. This patch does the proper
rebase.
Differential Revision: https://phabricator.services.mozilla.com/D119951
In cross-compilation setups (x86_64 host, i686 or aarch64 target), we're
going to need two sysroots. Obviously, we need the sysroot paths to be
different in that case, so the sysroot path themselves need to contain
some distinctive name, and we'll use the `target.toolchain` name for
that (the target triplet with the vendor/machine stripped out).
Because the path name needs to be reflected in the artifact name as well
as the toolchain name, we also change them.
And because the current prefix in the toolchain name is now redundant
with the suffix, we remove the prefix, and allow the bootstrapping
mechanism to try toolchains without the prefix.
Differential Revision: https://phabricator.services.mozilla.com/D119846
It was enabled in bug 1712633 by mistake.
Because there wasn't a way to distinguish esr yet, we add one, and while
at it, expose it to the build system.
Differential Revision: https://phabricator.services.mozilla.com/D119682
As written in 00c93ac66282, relying on the 2.27-3ubuntu1.2 package being
available is a timebomb. We can however get the older sources from
launchpad, and build them ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D119258
This allows to use the same toolchain docker images as other toolchains,
based on Debian buster.
While here, use the default max-run-time, which is more than enough for
this toolchain.
Differential Revision: https://phabricator.services.mozilla.com/D119137
Because GCC is built in stages, the final stage is built with
intermediate stages's GCC, which handles the sysroot correctly, so we
end up with headers and libraries with the expected compatibility.
This allows to use the same toolchain docker images as other toolchains,
based on Debian buster.
Differential Revision: https://phabricator.services.mozilla.com/D119136
- we needed -gcc-toolchain to pick C/C++ standard headers from the right
version of GCC, but we now have them in the toolchain sysroot (bug
1719207), so we can use that instead.
- we needed LD_LIBRARY_PATH when clang was built on an older version of
Debian, but that was changed in bug 1694775.
Differential Revision: https://phabricator.services.mozilla.com/D119135
We have a separate binutils toolchain already, and the only remaining
use of the binutils part of the the GCC toolchain is for the gold plugin
headers for clang, which we can add to the toolchain sysroot.
Differential Revision: https://phabricator.services.mozilla.com/D119133
When running `mach python-test` on a clobbered tree, we create both the
python-test and common virtualenvs, but the former should be enough. The
latter is only created when running tests that use the BaseConfigureTest
class, when it indirectly includes init.configure, which makes the
configure sandbox run the virtualenv_python3 function, which ends up
initializing the common virtualenv. We only don't end up re-executing
that virtualenv python thanks to 6680ca0acc27 which was a workaround
that would allow any virtualenv in $objdir/_virtualenvs, while still
creating a virtualenv it won't use.
Tests now tell virtualenv_python3 to not use the normal virtualenv
manager, and remove the workaround.
Differential Revision: https://phabricator.services.mozilla.com/D118775
I removed the -Wno-range-loop-analysis warning flag in bug 1718408 because I didn't see any build failures on Try without it, but apparently I missed some.
Differential Revision: https://phabricator.services.mozilla.com/D119039
This requires a backport of valgrind to buster instead of jessie (which
we don't need a backport for anymore). Somehow the buster-based
android-build was using the backport for jessie. It now can use the
backport for buster.
We now also need a few extra packages in the valgrind docker image that
used to be installed as a side effect of installing other packages, but
aren't installed automatically anymore, while necessary.
This allows to remove the debian8-amd64-build docker image, now unused.
We add a patch to workaround an issue with rust that was fixed in older
version of valgrind but that resurfaced in a slightly different manner.
Filed upstream as https://bugs.kde.org/show_bug.cgi?id=433641.
Finally, we update the suppressions to account for system changes.
Differential Revision: https://phabricator.services.mozilla.com/D106402
This requires a backport of valgrind to buster instead of jessie (which
we don't need a backport for anymore). Somehow the buster-based
android-build was using the backport for jessie. It now can use the
backport for buster.
We now also need a few extra packages in the valgrind docker image that
used to be installed as a side effect of installing other packages, but
aren't installed automatically anymore, while necessary.
This allows to remove the debian8-amd64-build docker image, now unused.
We add a patch to workaround an issue with rust that was fixed in older
version of valgrind but that resurfaced in a slightly different manner.
Filed upstream as https://bugs.kde.org/show_bug.cgi?id=433641.
Finally, we update the suppressions to account for system changes.
Differential Revision: https://phabricator.services.mozilla.com/D106402
As there are some things to solve first for the sysroot, we don't enable
the sysroot bootstrap unless --enable-bootstrap is given explicitly. The
default will still bootstrap everything else when building on central.
Differential Revision: https://phabricator.services.mozilla.com/D118450
The `mozbase` modules were being unconditionally added to the
`sys.path` regardless of the Mach command being run, so there isn't
much value keeping them in a separate file. Besides, all other
source module paths are described in `common_virtualenv_packages`,
why is `mozbase` special?
In the future, we're going to want to make improvements here (such as:
there's a difference between informing mach of first-party code
versus defining which third_party vendored packages should be in scope,
and that workflow difference should be represented in-code).
It's useful to peel out the existing, less useful abstraction before
we can build a stronger one.
Differential Revision: https://phabricator.services.mozilla.com/D117711
Having separate `<name>.pth` files in the virtual environments
isn't providing an advantage. We can simplify configuration
by putting all `pth` adjustments into a single file: `mach.pth`.
Differential Revision: https://phabricator.services.mozilla.com/D117710
This has two benefits:
1. `handle_package()` becomes more clear - rather than referring to
`action` and `package` with array index numbers, we now give
them real names. The benefit here is also shown in `up_to_date()`.
2. This makes the top-level parser for `packages()` less opinionated
about sub-formats: if an action has a nested structure, it should
have the flexibility to define what it looks like.
Differential Revision: https://phabricator.services.mozilla.com/D117708
After some testing in `try` and locally, the manual
`PYTHONEXECUTABLE` definitions shouldn't be needed
anymore.
There's been some work on Brew's
Python to improve its `sitecustomize` behaviour.
The most likely improvement is:
https://github.com/Homebrew/homebrew-core/pull/65297
However, I'm not fully confident in this change.
If it fails, it's more likely to affect developers
than CI. I think it's worth attempting a landing,
because if the variable is indeed obsolete, then
deleting it will avoid some spicy "action-at-a-
distance" behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D117452
Vendoring wheels has three benefits:
* There's far less files, so Firefox checkouts will be smaller.
* It works around `zipp` not allowing `pip install`
from extracted source `tar.gz` files. Now, we should
be able to use the pip resolver against vendored
packages, which will be needed for future
mach virtualenv work.
* `./mach vendor python` takes far less time to execute.
Since we need the raw Python to be available to add to the `sys.path`,
we extract the wheels before putting them in tree.
Due to the structure of some wheels being less nested
than of a source `tar.gz`, `common_virtualenv_packages`
needed to be adjusted accordingly.
`install_pip_package()` had to be tweaked as well since you can't
`pip install` an extracted wheel. So, we "re-bundle" the wheel
before installing from a vendored package.
Replace python packages with wheels where possible
This contains the vendoring changes caused by the
last patch.
For reviewing, there's a couple things to note:
* A bunch of files are deleted, since there's generally
less files in a wheel than in a source archive.
* There's a new `.dist-info` directory for each
extracted wheel, so expect roughly 5 or
6 new files for each wheel'd package.
* There should be no source code changes other than
moves from package names changing from having
`-` to having `_`.
Differential Revision: https://phabricator.services.mozilla.com/D116512
Last year, we stopped vendoring Python packages that have native
code. Since we have only had pure-python packages since, the
Windows-specific qualifier (or excluder in the case of `!windows`)
hasn't been needed.
I don't foresee us needing it again, but if anything we can peel it
back from `hg` history if this assumption is incorrect.
Differential Revision: https://phabricator.services.mozilla.com/D117468
The `mach_bootstrap:search_path()` implementation is out of
date compared to `virtualenv.py`.
Since `python2:`, `python3:` and `optional:` packages are no
longer valid virtualenv requirement actions, they can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D117707
For "c" (i.e., gcc, clang, and clang-cl), this configures the
`-f{debug,macro}-path-prefix` flags. We'd prefer to use
`-ffile-path-prefix`, but it seems that `clang-cl` does not recognize
that flag.
For "rust" (i.e., rustc/cargo), this configures `--remap-path-prefix`.
This is one step toward getting `sccache` hits across source and
object directories.
Differential Revision: https://phabricator.services.mozilla.com/D113065
Based on the docs and the code within `pathlib2`, it seems to focus
only on backporting the main features of `pathlib` to be available for
Python 2. It does _not_ provide features in newer Python versions
of `pathlib` (such as `is_mount`, new in Python 3.7). Therefore, it
doesn't provide anything that the standard library of Python 3.6+
doesn't have.
Differential Revision: https://phabricator.services.mozilla.com/D117071
We still need the blocklist to control rollout on Android, but on
desktop, we should be shipping Software WebRender to all users, except
those in safe mode or whom have explicitly disabled WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D117088
This will both:
* Ensure that developers aren't accidentally using Mach with Python 2
in the year 2021.
* Confirm that CI tasks aren't still using Python 2 with Mach.
* Remove support for Python 3.5, which is EOL'd.
Differential Revision: https://phabricator.services.mozilla.com/D116484
This will both:
* Ensure that developers aren't accidentally using Mach with Python 2
in the year 2021.
* Confirm that CI tasks aren't still using Python 2 with Mach.
* Remove support for Python 3.5, which is EOL'd.
Differential Revision: https://phabricator.services.mozilla.com/D116484
With D100581 LLVM added support for -Wunused-but-set-parameter and -Wunused-but-set-variable.
1. we shouldn't treat these warning as errors
2. for harfbuzz we apply a patch that has also been upstreamed, #2995, since pragma directives are somehow borken in clang vs gcc.
Differential Revision: https://phabricator.services.mozilla.com/D116604
There is a valgrind suppression on a generic signature containing the hash of rust types. The hash changes when crate dependencies are updated.
Differential Revision: https://phabricator.services.mozilla.com/D116588
To compile SM to .wasm we need to use clang from wasi-sdk, this patch
allows us to use default clang-12 from mozilla's repo.
We remove usage of rpath-link flag because wasm-ld doesn't support it,
enable single thread model because wasi is single threaded
and finally add <unistd.h> becase it is forbidden to use read/write/lseek
without this header.
Differential Revision: https://phabricator.services.mozilla.com/D116207
This will both:
* Ensure that developers aren't accidentally using Mach with Python 2
in the year 2021.
* Confirm that CI tasks aren't still using Python 2 with Mach.
* Remove support for Python 3.5, which is EOL'd.
Differential Revision: https://phabricator.services.mozilla.com/D116484
`MACH_VIRTUALENV` was never used, and `MOZBUILD_VIRTUALENV` was never
set (the virtualenv was always activated during the build, rather
than before).
Differential Revision: https://phabricator.services.mozilla.com/D115921
This was originally set up so that tests wouldn't "create a new
`virtualenv` for no reason." However, virtual environments now will have
different packages installed, and therefore the separation is necessary.
So, for the virtual environment used for builds (regular or for tests):
* We want it to be able to reuse the build venv, if it already exists.
* We don't want to pollute a `pytest` virtualenv with build-specific
packages.
Differential Revision: https://phabricator.services.mozilla.com/D115641
We had split up `init` from `init_py3` because `mach` had
traditionally been invoked by either Python 2 or Python 3, and
the two couldn't share the same virtualenv.
Now that the same context isn't shared by both Python 2 and 3
3
(developers always use Python 3, and the remaining Python 2
usages are CI jobs that never reuse the objdir with Python 3),
We can centralize on a single default virtualenv.
I've called this "common" instead of "init" to clarify its
existing position as the virtualenv that's used by many different
commands. As we associate virtualenvs with requirement definitions,
it'll also make the file less confusing: it's a "common" requirement
definition as opposed to an "init" one.
Differential Revision: https://phabricator.services.mozilla.com/D115635
At the same time, move the option to python configure, which changes how
to disable it (setting to an empty value rather than 0).
Differential Revision: https://phabricator.services.mozilla.com/D115844
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
As far as I can see, all this does is protect the user from
running some useless code if they manually enable the priority
manager using a pref on an OS that doesn't support it. The
upside of allowing this is that it makes it possible to debug
the priority manager on OSX and Linux with just a pref flip.
Differential Revision: https://phabricator.services.mozilla.com/D114767
Added two fields:
1. Collect if the current shell is opened via vscode.
2. Connect if it's a remote ssh connection n the current shell.
Differential Revision: https://phabricator.services.mozilla.com/D114323
Did you know that our version of requests was from 2015? Phwoar!
This bumps `jinja2`, `py`, `pyyaml`, `requests` and `urllib3`.
There's significant risk for regressions due to breaking changes,
though due to the dynamic nature of Python, they're tricky to track
down.
The potential breaking changes I'm expecting to potentially affect
us are:
* `requests@2.11.0`: No longer accepts non-strings as header values.
* `requests@2.16.0`: `requests.packages` namespace was removed due to
packages no longer being vendored. The namespace has been
incrementally restored over future releases, but it's unclear to
what degree.
* `requests@2.24.0`: Redirect resolution now only happens when
`allow_redirects` is `True`.
* `requests` version of `urllib3` was bumped from `1.13.1` to `1.26`,
unsure what repercussions that will have.
This also added dependencies to `flake8_requirements`. This is because
the vendored `importlib-metadata` update (and the new
`typing-extensions` dependency) is found by `pip`, but the
vendored `typing-extensions` is _not_ discovered (perhaps due to
details around "eggs" and the way we add vendored code to the sys.path).
So, `pip` tries to install it manually and fails when it finds no hash.
By re-compiling `flake8_requirements`, the necessary hashes are made
available.
Differential Revision: https://phabricator.services.mozilla.com/D108526
The maximum version check has caused more unnecessary failed
builds (for freshly up-to-date devs) than helpful guards against
tough-to-diagnose issues.
Differential Revision: https://phabricator.services.mozilla.com/D113675
irrespective of the optimization level. The code was previously using
the optimization level as a proxy for whether --enable-release is
enabled or not, which was invalidated by bug 1689284.
Differential Revision: https://phabricator.services.mozilla.com/D113730
It's a relatively minor one (two keyframes are leaked). I built latest
GTK3 from source and it wasn't reproducible locally. I think our GTK
version on automation might be too old and not have this commit:
10fa786dfa
Or something of that sort.
Differential Revision: https://phabricator.services.mozilla.com/D113948
Not all in-tree Rust libraries were using workspace-hack.
Additionally, some needed winapi features were missing from
workspace-hack's configuration.
Now, winapi is re-compiled less frequently on a full build.
Differential Revision: https://phabricator.services.mozilla.com/D113564
Sometimes there is a deadlock between user-requested ccov counters flush (through a signal) and flush happening when a process is dying.
So in order to avoid it, just remove the latter which is out of our control (user-requested flushes are protected using a cross mutex).
Differential Revision: https://phabricator.services.mozilla.com/D112632
Credit goes to dmajor.
Rust gets LLVM 12 - https://github.com/rust-lang/rust/pull/81451.
The PGO format changed between 11 and 12, and builds will have poor optimization if we mix versions in xLTO.
The above PR has landed on Rust nightly 1.52.
Until we move to 1.52 nightly we should have this landed.
In the meantime, for unblocking try builds, we can disable value-PGO in Rust.
Differential Revision: https://phabricator.services.mozilla.com/D113327
We should probably enable this later on when we do the aproapriate fixes in m-c and they
are also tagged in m-r but for now we should have this changed backed out of llvm locally.
Differential Revision: https://phabricator.services.mozilla.com/D113215
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
This both helps IDE integration and will help avoid build issues which would've
otherwise cropped up when adding new files to the directory for bug 1706374.
Differential Revision: https://phabricator.services.mozilla.com/D112764
Check if a user is a Mozilla employee by checking their
Bugzilla groups, or checking if their VCS email ends
with "@mozilla.com".
When a user is setting up a new build environment, telemetry
will be automatically enabled for them if they are an
employee. If they're not an employee, they'll be asked
if they want to opt in.
Differential Revision: https://phabricator.services.mozilla.com/D106315
Did you know that our version of requests was from 2015? Phwoar!
This bumps `jinja2`, `py`, `pyyaml`, `requests` and `urllib3`.
There's significant risk for regressions due to breaking changes,
though due to the dynamic nature of Python, they're tricky to track
down.
The potential breaking changes I'm expecting to potentially affect
us are:
* `requests@2.11.0`: No longer accepts non-strings as header values.
* `requests@2.16.0`: `requests.packages` namespace was removed due to
packages no longer being vendored. The namespace has been
incrementally restored over future releases, but it's unclear to
what degree.
* `requests@2.24.0`: Redirect resolution now only happens when
`allow_redirects` is `True`.
* `requests` version of `urllib3` was bumped from `1.13.1` to `1.26`,
unsure what repercussions that will have.
This also added dependencies to `flake8_requirements`. This is because
the vendored `importlib-metadata` update (and the new
`typing-extensions` dependency) is found by `pip`, but the
vendored `typing-extensions` is _not_ discovered (perhaps due to
details around "eggs" and the way we add vendored code to the sys.path).
So, `pip` tries to install it manually and fails when it finds no hash.
By re-compiling `flake8_requirements`, the necessary hashes are made
available.
Differential Revision: https://phabricator.services.mozilla.com/D108526
Glean is throwing an error if a string metric is `None`.
Since `get_cpu_brand()` can return `None`, only update telemetry if it's
set.
Depends on D110847
Differential Revision: https://phabricator.services.mozilla.com/D110858
Glean is throwing an error if a string metric is `None`.
Since `get_cpu_brand()` can return `None`, only update telemetry if it's
set.
Depends on D110847
Differential Revision: https://phabricator.services.mozilla.com/D110858
To avoid erroneously importing a package from the system, we remove
system site package.
This is another positive step towards further insulating the Firefox
build from the state of the environment.
This may cause failures if some mach commands have been sneakily
importing system packages instead of properly vendoring them.
Differential Revision: https://phabricator.services.mozilla.com/D110847
This file has been unchanged (other than license changes)
since the 1998 "free the lizard" commit.
It's not referenced from any other file.
It's time to retire, `genrc.sh`.
Differential Revision: https://phabricator.services.mozilla.com/D112374
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
1. Add task to get and build clang from the main branch.
2. Using clang main toolchain we build on a daily basis linux64 firefox, this tasks also automatically triggers the fetch and build of clang from main branch since we don't cache it.
Differential Revision: https://phabricator.services.mozilla.com/D111063
In bug 1174288 and related bugs we created a framework for generating
test certificates (and later, keys) from specifications at build time. This
turned out to take too long to run on each build, so this system was largely
left disabled (see all of the "# Temporarily disabled. See bug 1256495."
comments removed in this patch). This patch introduces a mach command
("generate-test-certs") that can generate test certificates and keys. The
expectation is that when a developer needs to add new such artifacts, they can
use this new command. Similarly, when the artifacts need to be updated (for
example, because they've expired), this command can regenerate them all at
once.
Differential Revision: https://phabricator.services.mozilla.com/D108869
Allow using the MOZ_KnownLive function to get around it.
Use case is the following: I have an std::function member variable, and I want
that member to be able to capture `this`.
Using a strong reference creates a cycle and thus would leak. I know `this` to
always outlive the member, so it is fine to use a weak capture there.
Differential Revision: https://phabricator.services.mozilla.com/D111850
Glean is throwing an error if a string metric is `None`.
Since `get_cpu_brand()` can return `None`, only update telemetry if it's
set.
Depends on D110847
Differential Revision: https://phabricator.services.mozilla.com/D110858
To avoid erroneously importing a package from the system, we remove
system site package.
This is another positive step towards further insulating the Firefox
build from the state of the environment.
This may cause failures if some mach commands have been sneakily
importing system packages instead of properly vendoring them.
Differential Revision: https://phabricator.services.mozilla.com/D110847
This also makes `MOZ_UPDATE_AGENT` depend on `MOZ_BACKGROUNDTASKS`.
There's no need to lint the `tools/update-programs` project, since
it's not a supported configuration. The next consumer can
rehabilitate it or remove it.
Differential Revision: https://phabricator.services.mozilla.com/D111313
If a custom `topsrcdir` is needed, it can be directly passed in.
I don't see how a separate `mozilla_dir` parameter is necessary - it
appears redundant to me.
Differential Revision: https://phabricator.services.mozilla.com/D110841
The build always uses them anyways, but configure tests don't, and some
of them fail as a consequence in some cases (example: when UBsan is
enabled, all AC_LANG_CPLUSPLUS + AC_CHECK_FUNCS tests fail). We also had
similar problems in the past, such as bug 1513605.
By adding the PIC flags to CFLAGS and CXXFLAGS, we ensure old-configure
tests use the flags as well.
While here, we also remove DSO_CFLAGS, which was always empty, and we
stop passing -fPIC to wasm compiles, because it has no effect there.
Differential Revision: https://phabricator.services.mozilla.com/D108560
The build always uses them anyways, but configure tests don't, and some
of them fail as a consequence in some cases (example: when UBsan is
enabled, all AC_LANG_CPLUSPLUS + AC_CHECK_FUNCS tests fail). We also had
similar problems in the past, such as bug 1513605.
By adding the PIC flags to CFLAGS and CXXFLAGS, we ensure old-configure
tests use the flags as well.
While here, we also remove DSO_CFLAGS, which was always empty, and we
stop passing -fPIC to wasm compiles, because it has no effect there.
Differential Revision: https://phabricator.services.mozilla.com/D108560
At the same time, remove the global define, which isn't necessary and
triggers some rebuilds. Nothing is using MOZ_UPDATE_AGENT right now
so it's safe to enable more broadly, and it will be used to gate new
background update work.
Differential Revision: https://phabricator.services.mozilla.com/D102786
Our bot was expecting to have tasks that were succeeding, right now we no longer need that
and in a case of a build failure, or in a case of the presence of a checker that asserts itself
as error and not warning we should mark the task red by failing the job.
Differential Revision: https://phabricator.services.mozilla.com/D107656
At the same time, remove the global define, which isn't necessary and
triggers some rebuilds. Nothing is using MOZ_UPDATE_AGENT right now
so it's safe to enable more broadly, and it will be used to gate new
background update work.
Differential Revision: https://phabricator.services.mozilla.com/D102786
We already know the project name, we should unbundle it
from the project path.
This change is possible due to the work in 1664083,
and puts us back to the state before 1255185.
Differential Revision: https://phabricator.services.mozilla.com/D106293
Just adding the toolchain tasks for now. They are not yet used by anything, but bug 1693288 might be interested eventually.
As with earlier releases, clang-tidy and mingw builds are not included here, they'll be separate patches.
Differential Revision: https://phabricator.services.mozilla.com/D106554
Upstream wptserve just switched to Python 3 only. That's fine for
web-platform-tests, but it turns out that some marionette harness
tests are also using wptserve and are still on Python 2.
Since fixing marionette harness turns out to be non-trivial and this
blocks other wpt work, this patch does the following:
* Temporarily vendors the last wptserve revision that works with
Python 2 in to testing/web-platform/mozilla/tests/tools/wptserve_py2
* Configures the mach virtualenv to use that copy for Python 2 modules
only.
* Configures the test packaging system to also put that copy in the
common tests zip. Requirements files are updated to use either the
Python 2 version or the Pyhton 3 version as required.
Differential Revision: https://phabricator.services.mozilla.com/D106764
Spidermonkey package builds don't have MOZ_AUTOMATION set (for good
reasons), which means they don't automatically get the sysroot through
MOZ_FETCHES_DIR. We need a way for that particular build to set its
sysroot.
Because the setup for sysroot is more elaborated than adding --sysroot
to C{,XX}FLAGS, it's more convenient to have an option for this.
And while at it, we might as well make that a full-fledged option,
although, we only make it available when targetting Linux (although it
could be useful for other OSes, but there's overlap with other options
on Android, and Mac, so for now, Linux-only will do).
This also allows to pass --without-sysroot along with
--enable-bootstrap, where the bootstrapped sysroot is not used.
Differential Revision: https://phabricator.services.mozilla.com/D106352
This means --enable-bootstrap now is the same as what
--enable-bootstrap=install currently does. --enable-bootstrap=install is at the
same time desupported.
We also remove --enable-bootstrap=update, which is not worth supporting.
Differential Revision: https://phabricator.services.mozilla.com/D105719
This changes things such that setting e.g. NASM=/usr/bin/nasm will avoid
bootstrapping nasm even when bootstrapping is enabled.
This is not applied to CC/CXX/HOST_CC/HOST_CXX because things are more
complicated.
This also simplifies how check_prog is called for a bootstrapped tool,
and avoids the repetition of when.
CBINDGEN handling needs the pattern being applied manually because it
currently doesn't use check_prog. Once --enable-bootstrap=install
becomes the default on developer builds, it will be possible to simplify
this.
Differential Revision: https://phabricator.services.mozilla.com/D105718
Because --with-ccache without a value fulfills a @depends_if, we need to
check for the length. And because we check the length, we can just use a
@depends.
Differential Revision: https://phabricator.services.mozilla.com/D106084
Add a reference to MOZ_NO_ADDREF_RELEASE_ON_RETURN in the message.
Use the qualified name of the function returning the object.
Differential Revision: https://phabricator.services.mozilla.com/D106143
- Only bootstrap sccache when building with --with-ccache=sccache or
CCACHE=sccache
- Don't bootstrap dump_syms or nasm on builds that don't compile
Differential Revision: https://phabricator.services.mozilla.com/D105704
Instead of preemptively check for it, and then check if it's good enough to
build AV1, only check for (and bootstrap) nasm when building AV1 requires
it.
At the same time, we future-proof the code to be able to handle multiple
things requiring nasm, which we're going to add shortly.
Differential Revision: https://phabricator.services.mozilla.com/D105425
Mike Hommey
Noemi Erli
Mitchell Hentges
Csoregi Natalia
Mike Kaply
Butkovits Atila
Sandor Molnar
Cosmin Sabou
Gerald Squelart
Brad Werth
Alex Lopez
Bob Owen
Andi-Bogdan Postelnicu
Benjamin Beurdouche
lyavor
Chris Peterson
Alexandru Michis
Kai Engert
Alexis Beingessner
surajeet310
Nick Alexander
Julien Cristau
Deian Stefan
Andrew Osmond
Alexandre Lissy
Dorel Luca
Andi-Bogdan Postelnicu
Nicolas Silva
Dmitry Bezhetskov
Steve Fink
Makoto Kato
Narcis Beleuzu
byron jones
Andrew McCreight
Chris H-C
Adam Gashlin
Kagami Sascha Rosylight
Emilio Cobos Álvarez
Calixte Denizet
Christian Holler
Nika Layzell
imoraru
Ryan VanderMeulen
Gabriele Svelto
Dana Keeler
Mark Banner
Christoph Kerschbaumer
Sebastian Hengst
Chris Fallin
Agi Sferro
Jesse Schwartzentruber
Mike Conley
Simon Giesecke
leli
Tom Ritter
Rob Lemley
David Major
James Graham
Florian Quèze
championshuttler
Edmund Wong