All that is really required for this ticket is to invoke |mach android
archive-geckoview| after |mach package| in the right place.
But it's actively unhelpful to have this magic in mozharness --
especially since the documentation in `locales.rst` is subtly
incorrect (the environment variables and Make variables don't quite
work as written). So this commit adds a Mach command to do the actual
work and replaces most of the mozharness magic with that command.
Since the l10n Make targets check out the l10n HG repositories
locally, this basically Just Works without the mozharness checkout
steps when developing locally.
Differential Revision: https://phabricator.services.mozilla.com/D12455
--HG--
extra : moz-landing-system : lando
When running `mach help`, mozconfig is loaded multiple times, and even
with an almost empty mozconfig, this makes mach help take close to 10
seconds on my Windows machine.
With some memoization, the time to run mach help gets down to 2s.
Differential Revision: https://phabricator.services.mozilla.com/D15186
--HG--
extra : moz-landing-system : lando
There are multiple fixes contained in this patch:
- fixes for Android/mobile support
- adding extra strings to the ftl file that were never defined before, and previously the ID was just printed to the page
- update test_l10n.py to not rely on about:support anymore
- changing Troubleshoot.jsm to return and ID and args for the strings that should be displayed, so it is compatible with the Fluent API
- misc. fixes so strings that are not localized don't go through the Fluent codepath
Differential Revision: https://phabricator.services.mozilla.com/D15437
--HG--
extra : moz-landing-system : lando
We remove --disable-libjpeg-turbo because that's only useful when Yasm
is too old, and the required version is now almost 8 years old, so we
can reasonably require people to upgrade rather than workaround with a
--disable option.
The valid_yasm_version function can seem overkill, but that's because
future moves of other things to python configure will pile up.
Differential Revision: https://phabricator.services.mozilla.com/D15184
--HG--
extra : moz-landing-system : lando
Now that we're not even building host static libraries, we don't need
variables for the tools used to build them.
Ironically, we weren't even running HOST_RANLIB.
Depends on D15172
Differential Revision: https://phabricator.services.mozilla.com/D15173
--HG--
extra : moz-landing-system : lando
The build system has skipped creating target static libraries for very
long, except in very specific cases.
We can actually do the same for host static libraries, for which we
don't even need the escape hatch to still allow to create static
libraries.
Depends on D15171
Differential Revision: https://phabricator.services.mozilla.com/D15172
--HG--
extra : moz-landing-system : lando
It turns out all the changes related to --help linting in lint.py make
them unnecessary, and we still can detect missing --help arguments
without them, per test_lint.py. On the flip side, keeping those
need_help_dependency arguments makes some functions executed twice
because some memoized functions end up being called for both cases
need_help_dependency=True and need_help_dependency=False.
Differential Revision: https://phabricator.services.mozilla.com/D15054
--HG--
extra : moz-landing-system : lando
When running `mach help`, mozconfig is loaded multiple times, and even
with an almost empty mozconfig, this makes mach help take close to 10
seconds on my Windows machine.
With some memoization, the time to run mach help gets down to 2s.
Differential Revision: https://phabricator.services.mozilla.com/D15186
--HG--
extra : moz-landing-system : lando
Fixing this unveils an issue in TestRecursiveMake::test_linkage that
was happening locally but not on automation, due to the Binary()
template never being invoked on automation.
Differential Revision: https://phabricator.services.mozilla.com/D15162
--HG--
extra : moz-landing-system : lando
We only need to quote strings that would be treated specially by the
shell, and "foo~bar" doesn't get any sort of expansion, while "~foo"
gets a user expansion, and to avoid that expansion, those latter strings
need to be quoted, but not the former.
Differential Revision: https://phabricator.services.mozilla.com/D15065
--HG--
extra : moz-landing-system : lando
We only need to quote strings that would be treated specially by the
shell, and "foo~bar" doesn't get any sort of expansion, while "~foo"
gets a user expansion, and to avoid that expansion, those latter strings
need to be quoted, but not the former.
Differential Revision: https://phabricator.services.mozilla.com/D15065
--HG--
extra : moz-landing-system : lando
XZ supports rewritting addresses in executable code, which is architechture
specific. The updater is compiled with support for the target architecture
only, so we can't always compress updates passing `--x86` to XZ. This threads
the architecture through to the repackage steps, so we can pass the appropraite
flags to the update packaging scripts.
Differential Revision: https://phabricator.services.mozilla.com/D14601
--HG--
extra : moz-landing-system : lando
This was always an accident of history: we forced export tier without
avoiding it in the libs tier.
Differential Revision: https://phabricator.services.mozilla.com/D14893
--HG--
extra : moz-landing-system : lando
Eventually, workers will provide these variables directly
(https://bugzilla.mozilla.org/show_bug.cgi?id=1460015). But for now, this
ensures that TASKCLUSTER_ROOT_URL is set everywhere, and TASKCLUSTER_PROXY_URL
is set wherever the proxy is active.
The setup for the mach commands defaults to https://taskcluster.net for user
convenience. When the production instance's URL changes, we can simply change
that default.
This changes the docker build process to propagate TASKCLUSTER_ROOT_URL into
the docker images, and for good measure includes some code to use that value to
generate debian repo paths.
Differential Revision: https://phabricator.services.mozilla.com/D14196
--HG--
extra : moz-landing-system : lando
The build system no longer invokes these directly: they're all fetched
and invoked by Gradle and its plugins.
Differential Revision: https://phabricator.services.mozilla.com/D14287
--HG--
extra : moz-landing-system : lando
_imports is cleared of functions at runtime, and that can cause
the `func in self._imports` test to return False in cases where the
function *does* have imports.
Make the lint track which functions has imports on its own.
This fortunately didn't cause mistakes not being caught by the lint in
the current python configure code, but causes problems with upcoming
changes.
Depends on D14124
Differential Revision: https://phabricator.services.mozilla.com/D14125
--HG--
extra : moz-landing-system : lando
Chris Manchester
Ted Mielczarek
Andrew Halberstadt
Nick Alexander
arthur.iakab
Mike Hommey
Bogdan Tara
Jared Wein
Cosmin Sabou
Ciure Andrei
Dorel Luca
Brindusan Cristian
Sebastian Hengst
Razvan Maries
Tom Prince
Margareta Eliza Balazs
Dustin J. Mitchell
Noemi Erli
Andi-Bogdan Postelnicu
Gijs Kruitbosch
Francesco Lodolo (:flod)
Thomas Daede
Geoff Lankow
Coroiu Cristina
Geoff Brown