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
This message dates from bug 1177128, the commit where this bootstrapper was added. At the time of writing that was certainly true, but today it doesn't appear to be true in any meaningful way. There's certainly an expectation that installing MozillaBuild and running `mach bootstrap` will get your machine ready to build Firefox; or at least, if it doesn't, it prints out some error messages telling you to do extra stuff, like we see in bug 1644794 for example. Therefore, I don't see how this message is relevant at all any more.
Differential Revision: https://phabricator.services.mozilla.com/D80730
While ideally we'd just move all of them at the top-level, there are
other things that depend on them that wouldn't then get the right
dependencies. One of them is install steps in dist/something, but there
are others, and that's a rather long pole of things requiring many
changes along with chances to break things.
So instead, we go with a simpler and more limited approach, where we
still recurse into directories to run their export tier (to run whatever
else than GeneratedFiles they have), but ensure the GeneratedFiles we
moved at the top-level are built before recursing by making
directory/export depend on them.
Differential Revision: https://phabricator.services.mozilla.com/D80608
Ideally, this kind of manual work wouldn't be required, but the frontend
doesn't provide enough information and while backend could correlate the
information, they currently don't.
Differential Revision: https://phabricator.services.mozilla.com/D80606
While ideally we'd just move all of them at the top-level, there are
other things that depend on them that wouldn't then get the right
dependencies. One of them is install steps in dist/something, but there
are others, and that's a rather long pole of things requiring many
changes along with chances to break things.
So instead, we go with a simpler and more limited approach, where we
still recurse into directories to run their export tier (to run whatever
else than GeneratedFiles they have), but ensure the GeneratedFiles we
moved at the top-level are built before recursing by making
directory/export depend on them.
Differential Revision: https://phabricator.services.mozilla.com/D80608
Ideally, this kind of manual work wouldn't be required, but the frontend
doesn't provide enough information and while backend could correlate the
information, they currently don't.
Differential Revision: https://phabricator.services.mozilla.com/D80606
While ideally we'd just move all of them at the top-level, there are
other things that depend on them that wouldn't then get the right
dependencies. One of them is install steps in dist/something, but there
are others, and that's a rather long pole of things requiring many
changes along with chances to break things.
So instead, we go with a simpler and more limited approach, where we
still recurse into directories to run their export tier (to run whatever
else than GeneratedFiles they have), but ensure the GeneratedFiles we
moved at the top-level are built before recursing by making
directory/export depend on them.
Differential Revision: https://phabricator.services.mozilla.com/D80608
Ideally, this kind of manual work wouldn't be required, but the frontend
doesn't provide enough information and while backend could correlate the
information, they currently don't.
Differential Revision: https://phabricator.services.mozilla.com/D80606
This uses sys.exit() instead of throwing an exception since:
1. It isn't an error, and bug 1646406 isn't finished yet
2. The output is more straightforward for the user
This verification happens separately from the other python-verification logic, but that's
because I wanted the validation to happen as soon as possible - before the user invests too
much time, and before too much of the script ran with the wrong interpreter.
Differential Revision: https://phabricator.services.mozilla.com/D80726
1.38 changed the Cargo.lock format, and the current minimum (1.37) can't
read it, so the minimum version was already wrong.
1.41 has a problem vendoring nom for some reason, that appears to be
fixed in 1.42.
Differential Revision: https://phabricator.services.mozilla.com/D80593
This adds a way to exclude certain file patterns when extracting Python
packages in |mach vendor python|. For now I've excluded likely test and doc
dirs, though we may want to expand on the list in the future.
Differential Revision: https://phabricator.services.mozilla.com/D80209
When linking a weak symbol in an object against a library where the
symbol is provided with a version, the final binary get a weak versioned
symbol reference.
It turns out weak versioned symbols still make the dynamic linker need
the symbol version, even if all symbols needed with that version are
weak.
Practically speaking, that means with bug 1634204, we now end up with
a weak versioned symbol reference to __cxa_thread_atexit_impl with
version GLIBC_2.18, and glibcs without the symbol can't fulfil that
version, even though the weak symbol is the only thing we need from that
version.
This means the check_binary changes in bug 1634204 are too
relaxed, so we revert them (although we keep the easier to read
conditions in check_dep_versions).
We also introduce a hack in stdc++compat.cpp (although it's not
technically entirely about libstdc++ compat) so that we avoid the weak
symbol reference while keeping the intended baseline for libstdc++ and
glibc.
Differential Revision: https://phabricator.services.mozilla.com/D79773
This patch adds a `--test-date` option to mozperftest that lets us specify the date that we are testing on. This lets us trigger multi-commit tests on past dates, and also ensures that retriggers of the multi-commit tests use the same day that they were pushed on (giving us reproducibility).
Differential Revision: https://phabricator.services.mozilla.com/D80173
They were necessary some time ago, but:
- there is no js/xpconnect/src/export target anymore,
- accessibility/xpcom/export had a dependency on xpcom/xpidl/export for
the ply cache files, but they're not used as of bug 1633156.
- the recursive make backend was adding automatic dependencies on
xpcom/xpidl/export for the ply cache files.
Differential Revision: https://phabricator.services.mozilla.com/D80150
When linking a weak symbol in an object against a library where the
symbol is provided with a version, the final binary get a weak versioned
symbol reference.
It turns out weak versioned symbols still make the dynamic linker need
the symbol version, even if all symbols needed with that version are
weak.
Practically speaking, that means with bug 1634204, we now end up with
a weak versioned symbol reference to __cxa_thread_atexit_impl with
version GLIBC_2.18, and glibcs without the symbol can't fulfil that
version, even though the weak symbol is the only thing we need from that
version.
This means the check_binary changes in bug 1634204 are too
relaxed, so we revert them (although we keep the easier to read
conditions in check_dep_versions).
We also introduce a hack in stdc++compat.cpp (although it's not
technically entirely about libstdc++ compat) so that we avoid the weak
symbol reference while keeping the intended baseline for libstdc++ and
glibc.
Differential Revision: https://phabricator.services.mozilla.com/D79773
Sentry needs to be able to send data in a minimal environment, and intelligently determining
the "topobjdir" (without leaning on Mach) is tough.
Instead, since the "topobjdir" usually falls under the "topsrcdir", just leaning on <topsrcdir>
patching should be sufficient.
Differential Revision: https://phabricator.services.mozilla.com/D80122
Karl Dubost
Dorel Luca
Matthew Noorenberghe
Mike Hommey
Cosmin Sabou
Mitchell Hentges
Ricky Stewart
Yue Zhang
Andi-Bogdan Postelnicu
Tarek Ziadé
David Major
Francesco Lodolo (:flod)
Geoff Brown
Jon Bauman
Ben Hearsum
Sylvestre Ledru
James Graham
Narcis Beleuzu
Andrew Halberstadt
John Paul Adrian Glaubitz
Gregory Mierzwinski