1. add the MOZ_X11 config flag in build/gn.mozbuild and set the gn_vars
accordingly.
2. create the new gn-config/mozconfig files and delete previous ones
dom/media/webrtc/third_party_build/gn-configs/**.mozconfig with
--enable-default-toolkit=cairo-gtk3-wayland-only for the non X11 version.
New toolkit nmae is required to force disable X11 detection as
cairo-gtk3-wayland will auto-detect X11 and make generate-gn-build-files.sh
fail.
3. Add the MOZ_X11 config flag in python/mozbuild/mozbuild/gn_processor.py
Then run
dom/media/webrtc/third_party_build/gn-configs/generate-gn-build-files.sh
Differential Revision: https://phabricator.services.mozilla.com/D142904
1. add the MOZ_X11 config flag in build/gn.mozbuild and set the gn_vars
accordingly.
2. create the new gn-config/mozconfig files and delete previous ones
dom/media/webrtc/third_party_build/gn-configs/**.mozconfig with
--enable-default-toolkit=cairo-gtk3-wayland-only for the non X11 version.
New toolkit nmae is required to force disable X11 detection as
cairo-gtk3-wayland will auto-detect X11 and make generate-gn-build-files.sh
fail.
3. Add the MOZ_X11 config flag in python/mozbuild/mozbuild/gn_processor.py
Then run
dom/media/webrtc/third_party_build/gn-configs/generate-gn-build-files.sh
Differential Revision: https://phabricator.services.mozilla.com/D142904
The `upload_geneated_sources.py` script needs `boto3`, but was:
* Running in CI with Mach having a site-packages-source of `None`
* Using the `common` site (which inherits Mach's site-packages-source)
* Installing `boto3` outside of the knowledge of the centralized
dependency system.
Make a `upload-generated-sources` site, and move `boto3` to it.
Differential Revision: https://phabricator.services.mozilla.com/D143715
On CI, 8.3 filenames are not generated, so the canonicalization of
program paths in `windows kits` doesn't work. But the build system can
actually deal with spaces in the specific case of MIDL and FXC.
Differential Revision: https://phabricator.services.mozilla.com/D143258
Its layout differs from the one in the tooltool archive for forward
compatibility with the upcoming (clang 15) -winsysroot flag.
There is probably more filtering we can do to somehow match what
windows_toolchain.py used to do, but we'll keep that for later.
Differential Revision: https://phabricator.services.mozilla.com/D143126
While the llvm/cmake/platforms/WinMsvc.cmake file only supports
cross-compiles, it contains the right -fms-compatibility-version
to use to build clang/llvm (modulo when upstream forgets to update it).
It's better to rely on that, than to keep a version in build-clang.py
that would possibly need to cover multiple versions of clang.
Differential Revision: https://phabricator.services.mozilla.com/D143133
On CI, 8.3 filenames are not generated, so the canonicalization of
program paths in `windows kits` doesn't work. But the build system can
actually deal with spaces in the specific case of MIDL and FXC.
Differential Revision: https://phabricator.services.mozilla.com/D143258
Its layout differs from the one in the tooltool archive for forward
compatibility with the upcoming (clang 15) -winsysroot flag.
There is probably more filtering we can do to somehow match what
windows_toolchain.py used to do, but we'll keep that for later.
Differential Revision: https://phabricator.services.mozilla.com/D143126
Cleans up the interface to AudioSession and brings in line with COM best practices. Uses background threads that are implicitly MTA and asserts proper thread behavior. This also removes AudioSession's Co[Un]Initialize static analysis violations.
Differential Revision: https://phabricator.services.mozilla.com/D140741
This is needed for a few reasons:
* All mach commands can use virtualenvs, not just `build`-related
commands, so the files don't make sense to be in `build/`.
* When locking is added, more files associated with virtualenvs will be
added, and this will change will ease the related directory structure
setup.
* This removes the need for a redundant "_virtualenv_packages" keyword
as part of the manifest filenames.
Differential Revision: https://phabricator.services.mozilla.com/D140382
When using Mach outside of MozillaBuild, rather than avoiding adding
paths entirely if any part of MozillaBuild is already in the `PATH`,
instead conditionally add each one if it doesn't exist already.
This ensures no duplication of paths, while also correctly handling the
not-uncommon case of developers manually adding MozillaBuild's Python to
their Windows `PATH`.
Differential Revision: https://phabricator.services.mozilla.com/D141377
Creates/updates virtualenvs for some mach commands, replacing
their ad-hoc usage of `install_pip_package()`, `pip install`,
and `sys.path` modifications.
Note: The `docs` virtualenv has `Sphinx==1.1.3` installed, even
though a more modern version of `Sphinx` is used when
`./mach doc` is run. This is ok for now, since `./mach doc` will
just install the newer `Sphinx` over top of the old one. Secondarily,
when we port `./mach doc` to use the centralized system, we'll
be incentivized to make the different `doc` commands use synchonized
versions of the same packages. Success!
Also, note that manual installation of `html5lib` and `requests`
isn't ported to the `wpt` site: this is because they're already
provided by the inherited Mach site.
Differential Revision: https://phabricator.services.mozilla.com/D122902
Pointer to AudioSession object is made std::atomic to resolve crashes (bug 1755700) by atomically modifying/reading the pointer as an effort to make sure any update to the pointer is seen across other threads immediately while not using locks to maintain such concurrency and avoiding dataraces.
This patch is built upon the work done in D136377.
Differential Revision: https://phabricator.services.mozilla.com/D140741
Windows uses `;` as the path separator, Unix-based systems use `:`.
`os.pathsep` conveniently represents the current system's separator.
All OS-specific path separators have been replaced with `os.pathsep`
except for some explicitly Windows-specific mozharness configs.
Differential Revision: https://phabricator.services.mozilla.com/D140981
Updates all build-related jobs (`artifact-build`, `build` and
`instrumented-build`) tasks to explicitly set
`MACH_BUILD_PYTHON_NATIVE_PACKAGE_SOURCE=system`. This allows them
to consume `psutil` (if installed on the system) without needing
to hit PyPI.org.
Modifies `build-l10n.sh` and `build-linux.sh` to no longer
explicitly fetch `psutil` from PyPI
(`./mach python --virtualenv psutil`), since that is replaced
by Mach's "native package source" behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D140257
The llvm-symbolizer tasks currently extract a llvm-symbolizer from clang
tasks. Changes in clang 14 make the hack that we have in place to keep
llvm-symbolizer statically linked to libllvm while clang uses a dynamic
libllvm not work anymore, so it's time to bite the bullet and build
llvm-symbolizer separately.
We share most of the build setup with the compiler-rt build.
Differential Revision: https://phabricator.services.mozilla.com/D140711
Only enable them when building on macOS or cross-compiling for macOS on Linux.
# catch redeclaration of ObjC method parameter name
-Wduplicate-method-arg
# catch multiple declarations of ObjC method found
-Wduplicate-method-match
# catch ObjC method with no return type specified
-Wmissing-method-return-type
# catch implicit conversions between ObjC BOOL and int
-Wobjc-signed-char-bool
# catch semicolon before ObjC method body
-Wsemicolon-before-method-body
# catch ObjC method parameter type not matching super class method
-Wsuper-class-method-mismatch
https://clang.llvm.org/docs/DiagnosticsReference.html
Differential Revision: https://phabricator.services.mozilla.com/D140598
The expected behavior during a PGO run is that a browser is started and
exited once, and then it is started again on a page that runs various
workloads and once finished, exits.
When workload happens to crash the content process, the browser is left
running indefinitely, until the taskcluster task itself times out. This
leaves us with no possibility of knowing what actually went wrong during
the run, which is about the worst thing that can happen.
With the browser shutting down on its own in case of crash, the harness
can find the minidumps and report the crash, which is more useful.
Differential Revision: https://phabricator.services.mozilla.com/D140678
Inconsistency confuses some of our tools. As part of this, I:
* Updated some docs to point to rust-minidump
* Added a fallback to mozcrash.py to try both versions
* Make mozcrash.py use --brief output when the local mdsw is used
* Remove the renaming hack from build-minidump-stackwalk.sh
This isn't as simple as a sed because we still have breakpad in tree
for minidump-analyzer. I did my best to replace the right strings.
Differential Revision: https://phabricator.services.mozilla.com/D138971
MozillaBuild 3.4's kernel name was `MINGW32_NT-6.2`, but the new
MozillaBuild's kernel name looks like `MSYS_NT-10.0-19044`.
Update existing first-party detection code to properly handle the modern
MSYS "kernel name" format.
Differential Revision: https://phabricator.services.mozilla.com/D140096
This patch introduces a new system for building IPDL unit tests, which is
roughly inspired by the old cxx unit test design, however designed to work with
gtest. It re-uses the existing IPDLUnitTest process type, using static
constructors only present in xul-gtest to register child actor constructors and
ProcessChild implementations to avoid bloating xul.
The IPDLUnitTest actor is used as a backchannel to communicate test failures
from the child process back to the parent process, and manage the test's async
lifecycle more reliably.
The IPDLUnitTest process also needed to have various properties about how it was
initialized adjusted:
* The IPDLUnitTest process should now always load xul-gtest when running
gtests, by using the "Self" process type and adding a DYLD_LIBRARY_PATH override
on macOS where the "Self" process type cannot be used.
* The IPDLUnitTest process now initializes minimal XPCOM, and runs a
frankeneventloop to allow it to use XPCOM event loop structures such as
SpinEventLoopUntil in tests.
* Support for creating IPDLUnitTest processes on Android was added, as these
tests had never run on android before.
Differential Revision: https://phabricator.services.mozilla.com/D137170