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
Mike Hommey
Mike Kaply
Csoregi Natalia
Butkovits Atila
Sandor Molnar
Mitchell Hentges
Cosmin Sabou
Gerald Squelart
Brad Werth
Alex Lopez
Bob Owen
Andi-Bogdan Postelnicu
Noemi Erli
Benjamin Beurdouche
lyavor
Chris Peterson