rename_gcov_flush_clang_11.patch doesn't apply cleanly to clang 12 and will need to be forked. Turning the filename into a parameter will let us have the tasks exist side by side.
Differential Revision: https://phabricator.services.mozilla.com/D101495
Passing all the directories to mach allows to take more advantage of
parallelism (plus not having to start up mach and the whole export once
for every directory, which itself takes a bit of time)
This takes:
GECKO_PATH=. taskcluster/scripts/misc/source-test-clang-non-unified.sh
from about ten mins to under two minutes on my machine.
Differential Revision: https://phabricator.services.mozilla.com/D101320
The new toolchain contains both aarch64 and x86_64 compiler-rts. We
could have a separate for each, but compiler-rt is small enough that
entirely separate toolchains is not warranted.
Differential Revision: https://phabricator.services.mozilla.com/D101079
The llvm build system does support building a universal compiler-rt for
multiple platforms at once, but as far as I know it only supports doing
so with the same SDK, while we want to use separate SDKs for each, so
build the x86_64 compiler-rt separately.
Differential Revision: https://phabricator.services.mozilla.com/D101078
The webrender wrench macos build, which is cross-compiled, needs a
macOS native libLLVM (a .dylib) to link against. The file is currently
part of the macosx-cross toolchain, but that was more incidental than
intentional. As we're going to change the macosx-cross toolchain in a
way that will remove the libLLVM.dylib, pull the file from the macOS
native clang.
Differential Revision: https://phabricator.services.mozilla.com/D101150
Only sanitizer builds require a native llvm-symbolizer executable.
Ideally, we'd build llvm-symbolizer from scratch, which would be faster,
but for now, let's go the easy route and just extract it from the
corresponding native clang builds.
We don't actually do anything with the llvm-symbolizer executable on
android builds, so we don't install it in $FINAL_TARGET, avoilding
the dependency on android builds (plus, we actually don't have an
android-native llvm-symbolizer, so even if it were already shipped, it
would be the wrong file).
Differential Revision: https://phabricator.services.mozilla.com/D101076
The new toolchain contains both aarch64 and x86_64 compiler-rts. We
could have a separate for each, but compiler-rt is small enough that
entirely separate toolchains is not warranted.
Differential Revision: https://phabricator.services.mozilla.com/D101079
The llvm build system does support building a universal compiler-rt for
multiple platforms at once, but as far as I know it only supports doing
so with the same SDK, while we want to use separate SDKs for each, so
build the x86_64 compiler-rt separately.
Differential Revision: https://phabricator.services.mozilla.com/D101078
Only sanitizer builds require a native llvm-symbolizer executable.
Ideally, we'd build llvm-symbolizer from scratch, which would be faster,
but for now, let's go the easy route and just extract it from the
corresponding native clang builds.
We don't actually do anything with the llvm-symbolizer executable on
android builds, so we don't install it in $FINAL_TARGET, avoilding
the dependency on android builds (plus, we actually don't have an
android-native llvm-symbolizer, so even if it were already shipped, it
would be the wrong file).
Differential Revision: https://phabricator.services.mozilla.com/D101076
When building compiler-rt for macOS, its build system assumes the
compiler used is a native macOS clang, drops all the cmake C/C++ flags,
and adds its own.
Because we do need to pass `-target $target` (otherwise we end up with
ELF x86_64 objects) and `-mcpu=apple-a12` for the correct baseline for
arm64 macOS, and because there is unfortunately no cmake variable that
the compiler-rt build system will use, and because CMAKE_C*_COMPILER
need to be a program without arguments, we need to wrap the compiler.
While here, add `-v` to the ninja call to have more useful logs.
Differential Revision: https://phabricator.services.mozilla.com/D99841
This requires tests to specify `python-3: true` in order to be run
with Python 3. When nothing is specified things work just like today,
so it's a more conservative change than the one in bug 1672181.
Obviously in the long term we will remove this and switch to Python 3
only, but this unblocks moving harnesses to py3 today.
Differential Revision: https://phabricator.services.mozilla.com/D98766
This requires tests to specify `python-3: true` in order to be run
with Python 3. When nothing is specified things work just like today,
so it's a more conservative change than the one in bug 1672181.
Obviously in the long term we will remove this and switch to Python 3
only, but this unblocks moving harnesses to py3 today.
Differential Revision: https://phabricator.services.mozilla.com/D98766
Install `psutil` when setting up the `mach` `virtualenv`s and stop importing the in-tree version in the build.
Nothing in-tree currently assumes or mandates the installation of `psutil` (all uses of `psutil` are guarded with imports of the form `try : import psutil; except ImportError: psutil = None`), so there's no back-incompatibility concerns here. There will be an awkward period where telemetry will be lacking CPU/disk data for everyone until they re-run `mach bootstrap` or `mach create-mach-environment`, but that will come back as people gradually update their `virtualenv`s.
An alternative to circumvent that issue is REQUIRING that `psutil` be installed by adding an assertion in `mach` that `psutil` can be found (allowing us to remove all the conditional logic in-tree around whether `psutil` is installed), but I wouldn't claim that we're ready to do that and deal with whatever fallout might occur.
Differential Revision: https://phabricator.services.mozilla.com/D90914
This adds a linux64-rust-dev toolchain and a git fetch of rust-lang/rust
that it can source from (stable tag for 1.47).
There are some issues with cross-compiling, so for now the toolchain only
builds a host build, although a lot of the machinery for cross compiling is
there for anyone brave/desperate enough to get it working.
Also note some changes were made to Rust's config.toml between 1.47 and 1.50,
so some version detection may need to be added in the future.
There is experimental support for providing patches via a new --patch flag.
Additionally, I documented the existence of the "bors-" mode.
Differential Revision: https://phabricator.services.mozilla.com/D97497
Install `psutil` when setting up the `mach` `virtualenv`s and stop importing the in-tree version in the build.
Nothing in-tree currently assumes or mandates the installation of `psutil` (all uses of `psutil` are guarded with imports of the form `try : import psutil; except ImportError: psutil = None`), so there's no back-incompatibility concerns here. There will be an awkward period where telemetry will be lacking CPU/disk data for everyone until they re-run `mach bootstrap` or `mach create-mach-environment`, but that will come back as people gradually update their `virtualenv`s.
An alternative to circumvent that issue is REQUIRING that `psutil` be installed by adding an assertion in `mach` that `psutil` can be found (allowing us to remove all the conditional logic in-tree around whether `psutil` is installed), but I wouldn't claim that we're ready to do that and deal with whatever fallout might occur.
Differential Revision: https://phabricator.services.mozilla.com/D90914
CLOSED TREE
Backed out changeset baa1f7a615e4 (bug 1666345)
Backed out changeset b6646baa866d (bug 1661624)
Backed out changeset e4d550db6037 (bug 1667152)
Install `psutil` when setting up the `mach` `virtualenv`s and stop importing the in-tree version in the build.
Nothing in-tree currently assumes or mandates the installation of `psutil` (all uses of `psutil` are guarded with imports of the form `try : import psutil; except ImportError: psutil = None`), so there's no back-incompatibility concerns here. There will be an awkward period where telemetry will be lacking CPU/disk data for everyone until they re-run `mach bootstrap` or `mach create-mach-environment`, but that will come back as people gradually update their `virtualenv`s.
An alternative to circumvent that issue is REQUIRING that `psutil` be installed by adding an assertion in `mach` that `psutil` can be found (allowing us to remove all the conditional logic in-tree around whether `psutil` is installed), but I wouldn't claim that we're ready to do that and deal with whatever fallout might occur.
Differential Revision: https://phabricator.services.mozilla.com/D90914
David Major
Dan Mosedale
Mike Hommey
Emilio Cobos Álvarez
Razvan Maries
Andi-Bogdan Postelnicu
James Graham
Mihai Alexandru Michis
Steve Fink
Alexis Beingessner
Andrew Halberstadt
stransky
Ricky Stewart
Noemi Erli
smolnar
Tom Ritter