This adds the sha256 for the ICU4X license as a variable to vendor_rust.py,
so it can be used as we add ICU4X crates. Since there are several projects
ongoing that want to use ICU4X, I think it makes sense to get the license
review done once, early, so that whoever is ready to land code that uses
ICU4X first is not blocked waiting on license review.
Differential Revision: https://phabricator.services.mozilla.com/D123776
The affected functions would cause an UnboundLocalError if they are moved
to module-level, because using an assignment inside a function makes a
variable local in Python, making it illegal to have a local variable name
be the same as a function name that is called within the same function.
The adopted solution is to rename those functions in preparation for the
future de-classing.
Differential Revision: https://phabricator.services.mozilla.com/D123867
By hybrid unified system we understand a system that encapsulates modules that are built in the unified mode
but also other modules, like `dom/Animation`, as an example, in the non unified environment.
This approach is desirable since we already have most of the modules transitioned to the non unified system but there are
still some that are not yet compatible, but in the long term this will be done by each module owner and can be also tested
locally using the build system.
If a module can't be built outside the unified method it's `moz.build` config file needs to have `REQUIRES_UNIFIED_BUILD = False`
To also enable this we need to have a flag from `mozconfig`, like:
```
ac_add_options --disable-unified-build
```
Differential Revision: https://phabricator.services.mozilla.com/D122328
By hybrid unified system we understand a system that encapsulates modules that are built in the unified mode
but also other modules, like `dom/Animation`, as an example, in the non unified environment.
This approach is desirable since we already have most of the modules transitioned to the non unified system but there are
still some that are not yet compatible, but in the long term this will be done by each module owner and can be also tested
locally using the build system.
If a module can't be built outside the unified method it's `moz.build` config file needs to have `REQUIRES_UNIFIED_BUILD = False`
To also enable this we need to have a flag from `mozconfig`, like:
```
ac_add_options --disable-unified-build
```
Differential Revision: https://phabricator.services.mozilla.com/D122328
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
The build system assumes the target compiler is of the same type as the
wasm compiler, but that's not true for wasm32-wasi, which we compile
with clang, while targeting windows, which we compile with clang-cl.
We handle the duality for host/target in a compiler-specific way, but
here, the wasm compiler is always going to be clang.
Differential Revision: https://phabricator.services.mozilla.com/D123041
RTL flags are flags that chooses which C/C++ runtime library to use
(multi-threaded, debug, etc.). They're only relevant when targeting
Windows, not when targeting wasi.
Frame pointer flags are not relevant to wasm (as a matter of fact,
the same wasm code is generated whether using -fomit-frame-pointer
or -fno-omit-frame-pointer)
Differential Revision: https://phabricator.services.mozilla.com/D123040
The purpose of this is to remove as many docstrings from CommandProvider
classes to make the step of moving commands out of classes simpler.
Where possible, the docstring has been moved to or merged with the function.
Differential Revision: https://phabricator.services.mozilla.com/D123288
For whatever reason, ./mach doc is sourcing rewrite_mozbuild.py
causing the ast.get_source_segment function to get redefined.
(We do this redefinition because it is very easy to accidently
use get_source_segment in this code and forget it doesn't
work on Taskcluster.)
So add an exemption for sphinx to pass through to the original
function, but also fix an inifnite loop where we weren't calling
the original function.
Differential Revision: https://phabricator.services.mozilla.com/D123487
The build system assumes the target compiler is of the same type as the
wasm compiler, but that's not true for wasm32-wasi, which we compile
with clang, while targeting windows, which we compile with clang-cl.
We handle the duality for host/target in a compiler-specific way, but
here, the wasm compiler is always going to be clang.
Differential Revision: https://phabricator.services.mozilla.com/D123041
RTL flags are flags that chooses which C/C++ runtime library to use
(multi-threaded, debug, etc.). They're only relevant when targeting
Windows, not when targeting wasi.
Frame pointer flags are not relevant to wasm (as a matter of fact,
the same wasm code is generated whether using -fomit-frame-pointer
or -fno-omit-frame-pointer)
Differential Revision: https://phabricator.services.mozilla.com/D123040
The build system assumes the target compiler is of the same type as the
wasm compiler, but that's not true for wasm32-wasi, which we compile
with clang, while targeting windows, which we compile with clang-cl.
We handle the duality for host/target in a compiler-specific way, but
here, the wasm compiler is always going to be clang.
Differential Revision: https://phabricator.services.mozilla.com/D123041
RTL flags are flags that chooses which C/C++ runtime library to use
(multi-threaded, debug, etc.). They're only relevant when targeting
Windows, not when targeting wasi.
Frame pointer flags are not relevant to wasm (as a matter of fact,
the same wasm code is generated whether using -fomit-frame-pointer
or -fno-omit-frame-pointer)
Differential Revision: https://phabricator.services.mozilla.com/D123040
Creates a migration for browser.tfl to unify strings in browser.dtd and broser.properties
that are used in main-popupset.inc.xhtml
Differential Revision: https://phabricator.services.mozilla.com/D122538
The sysroot setup on macOS is different from Linux, and pkg-config
files, if there are, would be coming from e.g. homebrew rather than
the macOS SDK.
Differential Revision: https://phabricator.services.mozilla.com/D122793
libdav1d only has relative paths. Like ../../third_party/foo/bar.c
libjpeg-xl has absolute paths like /third_party/bar/foo.c
This handles the second case by not doing our relative path
correction logic if we don't need to.
It will find all of the types of ways a file is included in a
moz.build file* and iterate over them, trying the slightly
different logic. This is okay, because the failure scenario
for trying an incorrect mode is just that we don't get a match.
By trying all the modes we can increase our chances of finding a
match.
* For SOURCES/UNIFIED_SOURCES there aren't actually any situations
where we have mixed-modes in a moz.build file. But a future patch
will add support for editing EXPORTS and they do have mixed-modes.
Depends on D120477
Differential Revision: https://phabricator.services.mozilla.com/D120478
When relanding Bug 1709697, all of the icons ended up as 0-byte files.
I can't explain this; it's hard to achieve this with a rebase. We
regenerate `Resources.pri` following the instructions in the
documentation.
This commit also moves to represent the package as "Mozilla Firefox",
which is consistent with how unpackaged versions appear in the Windows
UI. In the start menu, the application continues to be represented as
"Firefox" (no "Mozilla" vendor).
Finally, this commit also differentiates "Firefox Beta" from "Firefox"
in a few select places (while not changing branding and iconography).
Differential Revision: https://phabricator.services.mozilla.com/D122411
While some custom builds of GCC work successfully, system GCC builds
usually don't, because of several factors:
- they don't use the C++ headers or libstdc++.so from the sysroot
- they don't necessarily know to use the multiarch directories in the
sysroot
Differential Revision: https://phabricator.services.mozilla.com/D121946
We're currently using -isysroot as a preprocessor flag and
-Wl,--syslibroot/-Wl,--sysroot as a linker flag, but --sysroot is
generalization of both, so we can use that instead.
Differential Revision: https://phabricator.services.mozilla.com/D121943
They are equivalent, except for the fact that MACOSX_DEPLOYMENT_TARGET
may apply to more processes in a normal build. In practice, all the
processes that matter are covered through compiler flags.
On the opposite end, MACOSX_DEPLOYMENT_TARGET isn't necessary passed in
all cases (like clangd, mach static-analysis, etc.), while compiler
flags are.
Differential Revision: https://phabricator.services.mozilla.com/D122145
This patch has a few minor improvements to `./mach ide vscode` to make
it nicer to use in various situations. Specifically:
* Tries to locate the `code` using `shutil.which` in addition to the
existing methods so that the binary is found when being run from
within a vscode remote shell.
* If locating the code binary fails, only prompts to ask whether or not
to continue, rather than requiring entering the complete path. The
only use of the vscode command is to start an instance connected to the
correct path, so if no binary was found, a message is logged instead.
(bug 1699943)
* When changes need to be made to the settings.json file, a full diff is
shown between the old and new files, rather than just showing the
computed state before and after.
* If parsing the existing settings.json file fails (e.g. because there
were c-style comments in it - see bug 1670997), the diff is shown and
an additional warning is emitted to ask if the change should be made.
Differential Revision: https://phabricator.services.mozilla.com/D121157