Update scripts to support both lzma and bzip2
Update unused python script to support lzma. This also adds python 3.0 support to the script while still supporting pythin 2.7
Update test scripts to support lzma
f497b6194e9f bumped the minimum Java version requirement in configure
from 1.7 to 1.8. It forgot to update tests that were pinning the
Java version at 1.7. The tests then failed.
We bump the versions in tests to restore order.
CLOSED TREE
MozReview-Commit-ID: 1zm5L1QQy7a
There's a natural follow-on that I haven't time to explore right now:
I want the faster make backend to also write a "unified chrome
manifest" that maps outputs
(browser/chrome/browser/content/browser/ext-utils.js) to chrome:// or
resource:// URLs (chrome://content/browser/ext-utils.js or similar).
MozReview-Commit-ID: LDQmm8KD57I
Capture the list of generated source files derived from moz.build data
and save it in a generated-sources.json in the objdir so that we can upload
generated source files for use in crash reports and when debugging release
builds.
MozReview-Commit-ID: FrHcyFo0rBF
This is necessary because the existing manifests don't expose full
dependency information. I needed to avoid the existing dependency
files because those code paths need to know the output destination of
the manifest in order to parse the Make dependency files; trying to
adapt this system is more complicated than just preprocessing each
file to extract dependency information directly.
MozReview-Commit-ID: 5m0SEqmhJMM
Also removes InstallManifestNoSymlinks which can be more simply expressed by
passing link_policy='copy' to InstallManifest.populate_registry.
MozReview-Commit-ID: Bkjc2hIub4A
In bug 1181040, we added ${var}_IS_SET variables for
mk_add_options-defined variables. In the two years since, that has never
been used for anything else than MOZ_PGO_IS_SET, and the only use for
that has now been removed, so remove those ${var}_IS_SET variables.
Chain of trust validation will require to know what the inputs for a
given build are, and mach artifact toolchain fetches such inputs.
So we make it output a manifest that the chain of trust validation
process will be able to use and correlate with other information, such
as the one from bug 1383993.
At the same time, we make the produced manifest contain information
about tooltool-downloaded packages, which will allow to track the
progress in the migration from tooltool to TC artifacts.
Hacky, but it works -- until Google updates its license hashes. This
looks ahead to using |mach bootstrap| to build docker images.
MozReview-Commit-ID: DF23v8tr8SW
This was a regression introduced in Bug 1344244. Google changed the
layout of their packages. It used to be that the Android SDK archive
had a top-level 'android-sdk-$OS_NAME' directory; that's no longer the
case. It would be cleaner to unpack to 'android-sdk' without the OS
name, but that complicates the logic that detects existing installs.
MozReview-Commit-ID: 4B2Rt1AM2ky
Consider Rust toolchains prior to 1.19.0 old enough to update
by the `mach bootstrap` command, in preparation for requiring
that release during Firefox 57 nightly development.
MozReview-Commit-ID: JaaM3sPDmzn
Bug 1374940 adds a MOZ_TOOLCHAINS environment variable with a list of
path@task-id strings, where task-id is corresponding to the (possibly
optimized) toolchain job, and path corresponding to the
toolchain-artifact defined for that toolchain job.
We want to use that to pull artifacts instead of tooltool packages.
For reasons I can't explain, Windows builds are failing intermittently
because they are unable to locate the `hg` binary when running
some SpiderMonkey test processes. These processes use
mozversioncontrol.get_repository_from_env() to locate the
current repository.
We now store VCS info in configure. This makes it available to anything
running in a build system context.
This commit teaches mozversioncontrol.get_repository_from_env()
to import the "buildconfig" module to locate VCS info. If the module
can be imported, it is the sole source of VCS info. Otherwise, we
fall back to the existing detection mechanisms.
This should get rid of the intermittent failure. If it doesn't,
it is still a step in the right direction because it will allow
build system processes to consistently use a well-defined VCS
binary.
MozReview-Commit-ID: DMxXheJLRqH
We now have a variable in config.status for recording the checkout
type. These helper functions for determining if we're Mercurial or Git
can now be one-liners.
As a bonus, we no longer do I/O as part of this function.
MozReview-Commit-ID: HT9sbOhDEkf
For reasons I can't explain, Windows builds are failing intermittently
because they are unable to locate the `hg` binary when running
some SpiderMonkey test processes. These processes use
mozversioncontrol.get_repository_from_env() to locate the
current repository.
We now store VCS info in configure. This makes it available to anything
running in a build system context.
This commit teaches mozversioncontrol.get_repository_from_env()
to import the "buildconfig" module to locate VCS info. If the module
can be imported, it is the sole source of VCS info. Otherwise, we
fall back to the existing detection mechanisms.
This should get rid of the intermittent failure. If it doesn't,
it is still a step in the right direction because it will allow
build system processes to consistently use a well-defined VCS
binary.
MozReview-Commit-ID: DMxXheJLRqH
We now have a variable in config.status for recording the checkout
type. These helper functions for determining if we're Mercurial or Git
can now be one-liners.
As a bonus, we no longer do I/O as part of this function.
MozReview-Commit-ID: HT9sbOhDEkf
After this patch, the following will all display the subcommand help where they previously displayed
the command help:
$ mach help <command> <subcommand>
$ mach <command> --help <subcommand>
$ mach <command> <subcommand> --help
The command help will still be shown for:
$ mach help <command>
$ mach <command> --help
MozReview-Commit-ID: 7EsVblnCaFM
There's no need to install the caskroom bits for Homebrew now,
allowing to fix Java installation on Mac OS X and simplify the code at
the same time.
MozReview-Commit-ID: 1Ssjm4YRrPQ
This is the real fix. Google has replaced the |android --no-ui ...|
tool with a simpler |sdkmanager| tool, which makes it easier to
install packages with particular major versions. (Minor versions
still can't be controlled; for example, the m2repository extras are
constantly rolling forward.)
|sdkmanager| fails if the required packages aren't installed and can't
be installed, so there's no need to search for missing packages, etc,
simplifying the code considerably.
I don't see an easy way to upgrade outdated Android SDK installations
-- it's not clear that unpacking over top of an existing SDK
installation succeeds -- so I've included a message about moving or
removing outdated installations. This will punish folks who have
added additional Android platforms, or download emulator images using
the Android toolchain (but not those downloaded using |mach
emulator|). C'est la vie.
MozReview-Commit-ID: GLhKyuq701k
