This is a well-known limitation that we don't necessarily treat as a bug or always fix, and yet people generally expect that it should always work and end up filing bugs or chiming in in chat.mozilla.org. Here we caution people about the limitation.
Differential Revision: https://phabricator.services.mozilla.com/D82986
Since bug 1647865, we're no longer allowing `bootstrap` to be run with Python 2. Therefore we have leeway to make a bunch of simplifications.
Differential Revision: https://phabricator.services.mozilla.com/D82737
Here "update programs" refers to the various standalone binaries we
produce in order to update Firefox. There's not strong conceptual
coherence between them; rather, it's the pieces that the
Install/Update team generally work on.
To use this build project, prepare a minimal mozconfig with
`--enable-project=tools/update-programs`. Depending on the mozconfig
options and host and target OS, some of the following will be built:
1. the maintenance service;
2. the updater binary;
3. the Windows Default Browser Agent;
4. the Background Update Agent.
Differential Revision: https://phabricator.services.mozilla.com/D82644
The current setup sets /some/ flags via CLANGCL_ASFLAGS (handling of x86
is notably missing, for instance), and uses "clang-cl" as the assembler,
assuming it's in $PATH.
This can be simplified by just using `CC`, which will contain the full
path to "clang-cl" and the right flags for the targets, which makes
CLANGCL_ASFLAGS unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D82660
Prior to this patch JAVA_HOME was appended to path and then the first instance
of java on those paths was used and checked for version compatibility. This
meant that if an incompatible version on java is on the path JAVA_HOME could not
be used to point to a different, compatible version.
Following this patch, JAVA_HOME can be used as a more fine grained selector of
java. Only if JAVA_HOME is not set will we check the path. To be clear, even if
JAVA_HOME is set incorrectly, we will not fall back to path -- only if JAVA_HOME
is not set will we try and use the path.
Differential Revision: https://phabricator.services.mozilla.com/D82418
This is a rebase of a 7-year-old patch that was r=ted. The main part of
the patch was actually already removed in bug 1389598.
Differential Revision: https://phabricator.services.mozilla.com/D81027
D79393 introduced a new parameter to `configure_git()` but there is a remaining call that does not pass it. This patch fixes it.
Differential Revision: https://phabricator.services.mozilla.com/D82129
When moving from mozreview to Phabricator, the old mozreview git hook
had to be removed. Logic to automate the removal of this hook was added
to vcs-setup.
This commit removes this automated removal since it has been 2 years
since it landed.
Differential Revision: https://phabricator.services.mozilla.com/D82125
Depending on how MozillaBuild is invoked, python may think that the drive letter is a different case.
Since some paths are saved between builds in "config.status", this inconsistency can cause issues.
Though this patch doesn't solve the underlying inconsistency, it resolves the crash that was occurring.
Differential Revision: https://phabricator.services.mozilla.com/D81738
Because jar_maker is not in the libs tier, we also rename the libs-%
targets for l10n repacks to l10n-%, which make it clearer what they are
for.
And because multilocale.txt is both a GeneratedFile and a file that is
generated (and installed) via manual build rules, keeping it in the misc
target actually breaks building in toolkit/locales during l10n repacks,
so move it to libs for now.
Differential Revision: https://phabricator.services.mozilla.com/D81766
Depending on how MozillaBuild is invoked, python may think that the drive letter is a different case.
Since some paths are saved between builds in "config.status", this inconsistency can cause issues.
Though this patch doesn't solve the underlying inconsistency, it resolves the crash that was occurring.
Differential Revision: https://phabricator.services.mozilla.com/D81738
Sentry is initialized globally, but it's not clear to consumers when this actually happens.
For example, an unwary developer may call report_exception() within check_and_get_mach(),
not knowing that Sentry hasn't been initialized yet.
Using a class should make the dependency on register_sentry() more verbose.
Depends on D80913
Differential Revision: https://phabricator.services.mozilla.com/D80918
We get a lot of bugs about building Firefox for Android not working, and there's been ongoing confusion about whether this is something that does work or who has ever worked. The warning should hopefully clarify the current situation for people.
Differential Revision: https://phabricator.services.mozilla.com/D81585
Right now setup_perftest_test_date adds --test-date yesterday to all perftest
runs. we want that only for the ones doing batches
Differential Revision: https://phabricator.services.mozilla.com/D81562
Sebastian Hengst
Petr Sumbera
Narcis Beleuzu
Jim Porter
Ricky Stewart
Tom Prince
Nick Alexander
Mihai Alexandru Michis
Mike Hommey
Hamzah
Mitchell Hentges
Tarek Ziadé
Bryce
xuanqi xu
Kagami Sascha Rosylight
Coroiu Cristina
Matthew Noorenberghe
Andi-Bogdan Postelnicu
Bob Owen
Noemi Erli
Razvan Maries
Karl Dubost
Dorel Luca
Cosmin Sabou
Yue Zhang
David Major