This adds a subcommand ./mach cargo udeps with the following
sub command arguments:
Sub Command Arguments:
--all-crates Check all of the crates in the tree.
crates The crate name(s) to check.
--jobs [jobs], -j [jobs]
Run the tests in parallel using multiple
processes.
-v, --verbose Verbose output.
--message-format-json
Emit error messages as JSON.
--expect-unused Do not return an error exit code if udeps
detects unused dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D159838
Steps performed:
- Add "microsecond" and "nanosecond" to "intl/icu/data_filter.json".
- Run "icu_sources_data.py" to update the ICU data file.
- Run "update-tzdata.sh" to reapply the tzdata 2022f changes.
- Add "microsecond" and "nanosecond" to "SanctionedSimpleUnitIdentifiers.yaml".
- Run "make_intl_data.py units" to regenerate additional SpiderMonkey files.
Spec PR: https://github.com/tc39/ecma402/pull/708
Differential Revision: https://phabricator.services.mozilla.com/D161676
- The bug that was constantly disabling `VIRTUAL_TERMINAL_PROCESSING` has been fixed upstream in CYGWIN (fdbd153932) and merged into MSYS2 (e4fdb0cb73)
- The upcoming MozillaBuild `4.0.2` release will have the updated MSYS2 that contains this fix, allowing us to enable colored output on Windows.
- We will enable `ENABLE_VIRTUAL_TERMINAL_PROCESSING` once (For each stdout and stderr) on initializing the formatter to ensure that `VIRTUAL_TERMINAL_PROCESSING` is enabled whenever Mach is called..
- These changes will only be active if the MozillaBuild version is greater than or equal to Release `4.0.2`
Differential Revision: https://phabricator.services.mozilla.com/D138256
- The bug that was constantly disabling `VIRTUAL_TERMINAL_PROCESSING` has been fixed upstream in CYGWIN (fdbd153932) and merged into MSYS2 (e4fdb0cb73)
- The upcoming MozillaBuild `4.0.2` release will have the updated MSYS2 that contains this fix, allowing us to enable colored output on Windows.
- We will enable `ENABLE_VIRTUAL_TERMINAL_PROCESSING` once (For each stdout and stderr) on initializing the formatter to ensure that `VIRTUAL_TERMINAL_PROCESSING` is enabled whenever Mach is called..
- These changes will only be active if the MozillaBuild version is greater than or equal to Release `4.0.2`
Differential Revision: https://phabricator.services.mozilla.com/D138256
`HAS_CONNECTX` is not used in `netwerk/protocol/http` as of bug 1689604.
In NSPR, it is used to enable the use of `connectx`, which is available
since macOS 10.11, and we target 10.12, which means it's always
available, so we don't need to check for it based on the target version
(and checking the host version was wrong, too).
Differential Revision: https://phabricator.services.mozilla.com/D156275
Considering builds with clang-cl now enable all the same warnings as those
with clang, and those flags are not given to clang-cl, that means
they're not necessary.
Differential Revision: https://phabricator.services.mozilla.com/D154054
In order to allow rust-analyzer to be able to use the build script in
the mozbuild crate to discover the configuration information, this patch
adds new flags to the vscode config to tell rust-analyzer to invoke
cargo through `./mach cargo check`, and use the correct target directory
within the objdir rather than `$(topsrcdir)/target`.
Due to the virtual filesystem used by rust-analyzer not including files
in the object directory, this is not sufficient to get suggestions for
symbols from the included files, however it will accurately fetch
diagnostics upon save and run things like proc macros.
A new feature will likely need to be added to rust-analyzer to allow us
to specify additional paths to add to the source root for packages to
fix that issue.
Due to this change using `./mach cargo check`, rather than running it
independently, we don't run into issues caused by running `check`
against crates in the workspace which aren't being used, making the
diagnostics more useful.
An additional feature needed to be added to `./mach cargo check` to
allow specifying `--message-format=json`. I am open to suggestions for a
more elegant way to communicate this flag into the makefile.
Depends on D153269
Differential Revision: https://phabricator.services.mozilla.com/D153270
This switches the code to instead use the generated source file, which is
discovered based on `OUT_DIR` so is easier for rust-analyzer to understand.
The configuration for rust-analyzer will be updated in the next part to
make sure that rust-analyzer is able to take advantage of these changes,
and produce better diagnostics.
Differential Revision: https://phabricator.services.mozilla.com/D153269
We are going to compile JS into WebAssembly! This is the first patch
in an upcoming queue. Here we introduce wasm32 architecture so that
SpiderMonkey can be compiled with enabled jit for wasi target.
Differential Revision: https://phabricator.services.mozilla.com/D145790
Change XUL and other dylibs to be built with an @rpath/<dylib> install name (LC_ID_DYLIB) instead of @executable_path/<dylib>.
Change executables to be built with an @rpath dyld search path set to @executable_path by default so that @rpath/<dylib> dylibs in the same directory can be resolved. For executables not in the same directory as @rpath dylibs, such as plugin-container, set a relative @rpath such as @executable_path/../../../.
Previously, dylib install names were set as @executable_path/<dylib> allowing them to be resolved by dyld for the loading executable if the executable resided in the same directory as the dylib. For executables not in the same directory as the dylibs, dyld resolved these dylibs using DYLD_LIBRARY_PATH set before launching the process by Firefox code. With this change, loading does not rely on DYLD environment variables. Instead, dylibs have an install name set as @rpath/<dylib> and each executable loading a dylib has its @rpath set at compile-time to refer to dylib directory.
Differential Revision: https://phabricator.services.mozilla.com/D147360
This addresses the original intent of the bug report which asks for allowing
sndio to be built on more than just OpenBSD. In addition of modifying the
existing --enable-sndio to support this request, the option
--enable-audio-backends was added which takes a list of possible backends to
support per discussion in the bug report.
For example specifying --enable-audio-backends=alsa,jack,pulseaudio,sndio
allows for runtime selection of those four cubeb backends. If all four backends
are available the user can specify `media.cubeb.backend` in `about:config` to
force a specific backend.
Removed superfluous set_define()s as libcubeb's moz.build does the necessary
`DEFINES['...']` assignments for each backend.
In addition logic for finer control of audio backend selection on Android was
added. One can now specify aaudio, opensl or both (which is the default).
Differential Revision: https://phabricator.services.mozilla.com/D141450
This addresses the original intent of the bug report which asks for allowing
sndio to be built on more than just OpenBSD. In addition of modifying the
existing --enable-sndio to support this request, the option
--enable-audio-backends was added which takes a list of possible backends to
support per discussion in the bug report.
For example specifying --enable-audio-backends=alsa,jack,pulseaudio,sndio
allows for runtime selection of those four cubeb backends. If all four backends
are available the user can specify `media.cubeb.backend` in `about:config` to
force a specific backend.
***
Bug 1351378 - Address linter error. r?mhentges,glandium
***
Bug 1351378 - Remove superfluous set_define(). r?mhentges,glandium
libcubeb's moz.build does the necessary `DEFINES['...']` assignments for each
backend. Remove superfluous set_define().
Differential Revision: https://phabricator.services.mozilla.com/D141450
