When building Gecko/Android/aarch64 on Windows, `--target` parameter may not be incorrect value. Although `check_compiler`'s `info` is target compiler, clang on Windows is always detected as `clang-cl`, not `clang`.
```
c:/Users/mkato/.mozbuild/clang/bin/clang.exe -E -dM - < /dev/null
...
#define _MSC_VER 1916
```
So even if using clang on Windows, not clang-cl, we should detect as 'clang' correctly
Differential Revision: https://phabricator.services.mozilla.com/D36422
--HG--
extra : moz-landing-system : lando
By globally importing PackageFrontend from the globe-analysis module we break the logger for
the PackageFrontend package.
Differential Revision: https://phabricator.services.mozilla.com/D36887
--HG--
extra : moz-landing-system : lando
The SDK headers may not be installed in /usr/include. The usual response
has been to have people run e.g. `open
/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg`
which is not really sustainable.
This makes builds that happen on a macOS host try to detect their SDK
and use that as a default for --with-macos-sdk, which has the side
effect of enabling the SDK version check in that configuration.
Differential Revision: https://phabricator.services.mozilla.com/D36558
--HG--
extra : moz-landing-system : lando
This test is working with minimal effort. Let's get it running to prevent
future regressions.
Differential Revision: https://phabricator.services.mozilla.com/D36098
--HG--
extra : moz-landing-system : lando
Configure should just be able to find the right one. If it doesn't, that
should be fixed in configure rather than with suggestions in bootstrap.
Differential Revision: https://phabricator.services.mozilla.com/D36562
--HG--
extra : moz-landing-system : lando
Configure should just be able to find the right one. If it doesn't, that
should be fixed in configure rather than with suggestions in bootstrap.
Differential Revision: https://phabricator.services.mozilla.com/D36562
--HG--
extra : moz-landing-system : lando
Bug 1554987 made `mach try` use a transient remote, but that causes
problems with existing setups that happen to use the same remote name,
because of a combination of not-quite-as-documented-as-it-should
behavior of git.
- `git -c foo.bar=qux` doesn't override the value of `foo.bar` from the
git configuration when `foo.bar` is an item that can take several
values.
- `remote.$remote.url` and `remote.$remote.pushurl` take several values,
allowing to give several URLs.
The combination of both means that if the git configuration already has
`remote.try.url` set, that value takes precedence (because git push
tries them one after the other, and takes the one from the command line
last)
One way we could increase the chances of things working out fine would
be to use `remote.try.pushurl`, which if already set, is more likely to
be right than an existing `remote.try.url`.
OTOH, it turns out, after more investigation, that bug 1554987 requires
a footgunny setup to happen in the first place. Namely, it requires
having run `git lfs install` from a git-cinnabar clone.
so we just go back to the previous status quo.
Differential Revision: https://phabricator.services.mozilla.com/D36149
--HG--
extra : moz-landing-system : lando
See https://stackoverflow.com/a/24026735.
Adding the `docs` package requirement is not ideal, but it's not worth
the effort to install it only in automation (or in the relevant task),
and it's not *that* large: 1.0G on my macOS installation.
Differential Revision: https://phabricator.services.mozilla.com/D35834
--HG--
extra : moz-landing-system : lando
4.3.3 is the strict minimum required for v-c-t's config wizard, but it
is preferable people use more modern versions. We could go with 5.0, but
it feels like people still using 4.8 and 4.9 don't really need to be
bugged to update to a more recent version, they are kind of modern
enough. OTOH MozillaBuild comes with 4.5.x, and this will force an
upgrade for those.
Differential Revision: https://phabricator.services.mozilla.com/D35756
--HG--
extra : moz-landing-system : lando
This makes the bootstrap behavior wrt. Mercurial consistent on all
platforms, making Windows bootstrap only upgrade Mercurial if the
version is older than MODERN_MERCURIAL_VERSION.
As a side effect, this avoids upgrading to version 5.0.1, which doesn't
come with wheels at the moment.
Differential Revision: https://phabricator.services.mozilla.com/D35754
--HG--
extra : moz-landing-system : lando
The `mach resource-usage` page supports a list of build resource data,
but only ever displays the first one. Nothing actually creates a list
with multiple items automatically, but one might want to do that
manually to explore data from multiple builds more conveniently.
So if such a list exists, we expose a dropdown list of all the data
available, and switch the graph when a different item is chosen from the
list.
Differential Revision: https://phabricator.services.mozilla.com/D35757
--HG--
extra : moz-landing-system : lando
The git version shipped in some versions of OSX is patched by apple in a
way such that doing `git push hg::ssh://...` fails with an error message
like `Invalid remote name "hg::ssh://...`.
So instead, we define a named remote via inline configuration, and use
that remote's name for the push.
Differential Revision: https://phabricator.services.mozilla.com/D35351
--HG--
extra : moz-landing-system : lando
The git version shipped in some versions of OSX is patched by apple in a
way such that doing `git push hg::ssh://...` fails with an error message
like `Invalid remote name "hg::ssh://...`.
So instead, we define a named remote via inline configuration, and use
that remote's name for the push.
Differential Revision: https://phabricator.services.mozilla.com/D35351
--HG--
extra : moz-landing-system : lando
This makes running without mach more consistent. e.g. running
`make -C $objdir/toolkit/library/rust target` makes the cargo log
verbose, and adding `-s` makes it less verbose.
Differential Revision: https://phabricator.services.mozilla.com/D35521
--HG--
extra : moz-landing-system : lando
When the `MOZ_RUST_TIER` environment variable is set, we enable a separate
tier that builds rust code only. This is useful to measure build times for
rust code separately from other compilations.
Differential Revision: https://phabricator.services.mozilla.com/D35501
--HG--
extra : moz-landing-system : lando
NSS_ALLOW_SSLKEYLOGFILE no longer has issues upstream, we can allow it again.
Differential Revision: https://phabricator.services.mozilla.com/D34915
--HG--
extra : moz-landing-system : lando
Bug 1394825 bumped the minimum version of clang we use on automation,
for the base toolchain jobs, and there's a libclang test for bindgen,
but we should reject the compiler in the first place.
The check to do that works in both C and C++, contrary to the original
3.6 test that was checking a C++ feature ; the test was later changed
for 3.9, using a check that would have worked in both C and C++, but
the C exception was left around. We remove it now.
Differential Revision: https://phabricator.services.mozilla.com/D34083
--HG--
extra : moz-landing-system : lando
This works around the following situation: the Ngv/fat AAR task is
deterministic, but it depends on N tasks for multiple architectures,
adn the exact l10n changeset pulled by each N task depends on the tip
of the l10n HG repository at the time the N task executes.
For now, just ignore the obvious localized resources: *.ftl, *.dtd,
*.properties.
Differential Revision: https://phabricator.services.mozilla.com/D33413
--HG--
extra : moz-landing-system : lando
Not sure why this wasn't done before, but it prevented me from running `./mach rust vendor`.
Differential Revision: https://phabricator.services.mozilla.com/D34127
--HG--
extra : moz-landing-system : lando
Skips over the incremental cache when performing a clobber. The incremental compilation cache is located at:
`$(objdir)/$(rust_target)/$(rust_build_kind)/incremental`
When cross compiling there can be two caches, one for the host and one for the target so we handle both.
Differential Revision: https://phabricator.services.mozilla.com/D31310
--HG--
extra : moz-landing-system : lando
Pass in the substs dictionary to `Clobberer` so that we can use it to query `cargo` paths.
Differential Revision: https://phabricator.services.mozilla.com/D31309
--HG--
extra : moz-landing-system : lando
Pull out the logic for filtering subdirectories and deleting them into
reusable functions.
Differential Revision: https://phabricator.services.mozilla.com/D31308
--HG--
extra : moz-landing-system : lando
Use the same logic as for --with-android-sdk to use the NDK downloaded
by mach bootstrap by default.
Differential Revision: https://phabricator.services.mozilla.com/D34251
--HG--
extra : moz-landing-system : lando
After bug 1519954, the build system will pick the compiler in
~/.mozbuild on its own, so there's no need to suggest people to manually
put that in their mozconfig.
Differential Revision: https://phabricator.services.mozilla.com/D33903
--HG--
extra : moz-landing-system : lando
As established previously, generated source files that are not included
don't need to be built during the export tier.
Differential Revision: https://phabricator.services.mozilla.com/D33771
--HG--
extra : moz-landing-system : lando
Pull out the logic for filtering subdirectories and deleting them into
reusable functions.
Differential Revision: https://phabricator.services.mozilla.com/D31308
--HG--
extra : moz-landing-system : lando
In a branch for `isinstance(obj, (HostSources, HostGeneratedSources))`,
`isinstance(obj, GeneratedSources)` is clearly not going to match
anything. `isinstance(obj, HostGeneratedSources)` is what was intended.
Differential Revision: https://phabricator.services.mozilla.com/D33603
--HG--
extra : moz-landing-system : lando
webidlsrcs.mk is treated specially by the build system, and this entire
process should be supported better by moz.build, but in the meantime this
fixes the clobber bug caused by not re-building these targets when defines
are updated.
Differential Revision: https://phabricator.services.mozilla.com/D33415
--HG--
extra : moz-landing-system : lando
Invoking MozbuildObject.substs causes an exception to be raised if there is no
BuildEnvironment. This means that we hit an error on |mach help| if there is no
build, which is not ideal for people trying to learn how to build :).
Differential Revision: https://phabricator.services.mozilla.com/D33217
--HG--
extra : moz-landing-system : lando
This follows the model set down for EME artifacts:
- a new tier is added that uses a new Python build action to fetch and
artifacts
- the action unpacks the fetched artifacts and moves specific inputs
into places expected by the build and packager
- in automation, MOZ_ARTIFACT_TASK* is used to ensure the artifacts
come from the correct tasks
In this case, the artifact fetching is done entirely in a new Python
build action that internally uses `mach artifact install --job ...`.
The action also verifies that the fetched artifacts are compatible and
that we're not assembling a fat AAR that is nonsensical. The specific
inputs are not used in the Fennec APK that is produced; they're only
used in the GeckoView AAR that is produced.
The artifact fetching itself required tweaking to fetch only
`target.maven.zip` artifacts and to not unpack them.
The specific inputs used are the native libraries (libs/$ARCH/*.so)
and the architecture-specific preference files ($ARCH/greprefs.js and
defaults/pref/$ARCH/geckoview-prefs.js). None of these inputs are
impacted by l10n.
Differential Revision: https://phabricator.services.mozilla.com/D31572
--HG--
extra : moz-landing-system : lando
This allows to use the existing artifacts VCS-based crawling to
download the "raw" target.maven.zip from Android jobs and not process
it further. It's just put in a specific directory, ready for use.
This isn't a big deal in automation, where all URLs are known, but
it's very useful when building locally and the VCS and the pushlog
must be consulted to determine task URLs.
Differential Revision: https://phabricator.services.mozilla.com/D31571
--HG--
extra : moz-landing-system : lando
(adds __build_class__ to the builtin sandbox and allow CombinedDependsFunction to be hashed)
Differential Revision: https://phabricator.services.mozilla.com/D28114
--HG--
extra : moz-landing-system : lando
shellutil.py needed special handling since it is invoked earlier than the
vendor directory adding we do, so it does not have six available.
Differential Revision: https://phabricator.services.mozilla.com/D28096
--HG--
extra : moz-landing-system : lando
Lint python/mozbuild/{mozbuild,mozpack}.
This makes sure we use byte strings (type(b'')) in many places.
This also has a few places where we know we want unicode, by enforcing it.
This code also has a few places where we call into windows API's which expect either all args to be unicode,
or all args to be bytestrings (not-unicode) so make sure those calls align.
This is the most risky of the stack, since there are some mach commands and codepaths that are neither excercised in automation
nor excercised in tests.
Differential Revision: https://phabricator.services.mozilla.com/D26645
--HG--
extra : moz-landing-system : lando
Lint python/mozbuild/{mozbuild,mozpack}. r=#build
Add 'from __future__ import absolute_import' to all missing files in python/mozbuild/{mozbuild,mozpack}/**/*.py
Differential Revision: https://phabricator.services.mozilla.com/D26643
--HG--
extra : moz-landing-system : lando
Leaving one fix for an explicit review.
Lint python/mozbuild/{mozbuild,mozpack}. r=#build
Differential Revision: https://phabricator.services.mozilla.com/D26641
--HG--
extra : moz-landing-system : lando
Lint python/mozbuild/{mozbuild,mozpack}.
ran './mach lint -l py2 -l flake8 -l shellcheck -l codespell -l yaml python/mozbuild/{mozbuild,mozpack}/ --fix' in order
to undo some black changes and get closer to making this folder able to be validated on every lint run
Differential Revision: https://phabricator.services.mozilla.com/D26640
--HG--
extra : moz-landing-system : lando
We're moving to IR-level PGO instrumentation for clang-cl. We've also
moved to using static linker ordering files, which was the primary
application of the previous style of PGO instrumentation. We therefore
we no longer need this code.
Differential Revision: https://phabricator.services.mozilla.com/D31134
--HG--
extra : moz-landing-system : lando
We used to support specifying single Rust files for compilation,
emphasis on "used to".
Differential Revision: https://phabricator.services.mozilla.com/D32314
--HG--
extra : moz-landing-system : lando
Bug 1533425 makes Gecko try to load from $ARCH/greprefs.js, etc on
Android. This patch teaches the packager to put certain preferences
into those architecture-specific locations for that code to find.
Differential Revision: https://phabricator.services.mozilla.com/D24984
--HG--
extra : moz-landing-system : lando
This way compilation backends don't all have to figure out the right way
to handle symbol files.
Differential Revision: https://phabricator.services.mozilla.com/D29673
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
The zipfile.is_zipfile() function is overly lenient, in that non-zip
files that contain the four bytes "PK\005\006" near the end of the file
are reported as zip files even if the zip structure is not valid.
Occasionally, our target.tar.bz2 files randomly contain those 4 bytes at
the expected location, which causes the mar repackaging code to try to
process the package as a zip file instead of a tar file.
The tarfile.is_tarfile() logic looks a little more robust in that it
actually tries to open the file, so if we try tar first before falling
back to zip we should be a little more resilient.
Differential Revision: https://phabricator.services.mozilla.com/D31908
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
This just separates out the Android definitions into
mobile/android/mach_commands.py. There was vestigial support for
running on Android with debuggers, but it was for wiring up JimDB,
which is no longer supported and in fact hasn't worked on actual
devices for a very long time. (The new flow for running on Android
under a debugger goes through the Android Studio hybrid debugger.)
Differential Revision: https://phabricator.services.mozilla.com/D18291
--HG--
extra : moz-landing-system : lando
We want `mach run` for Android to be wildly different than `mach run`
for Desktop. But right now, mach really doesn't support two different
implementations of the same underlying named command. The avenues
that might support different implementations, mostly run through
`conditions`.
`conditions` were added to mach commands in Bug 901972, and never
really anticipated this use case: commands are keyed by name condition
evaluation is delayed until dispatch-time. In order to have different
commands with the same name, and have full support for `--help`,
command matching, suggestions, etc, we really need conditions to
evaluate at parse-time. Indeed, since Bug 901972 landed, we've moved
context creation earlier in the dispatch flow and hacked in things
that look like parse-time conditions (see Bug 1291335 and Bug
1305695).
This approach is not the prettiest, but it handles this narrow
use-case -- making `mach run` and `mach install` different on Android
-- without much code churn.
Differential Revision: https://phabricator.services.mozilla.com/D18290
--HG--
extra : moz-landing-system : lando
Having `rustc` be `rustup`'s wrapper for `rustc` means that we may
silently honor `rustup`'s override mechanisms. We noticed this first on
OS X, where we use the "real" `cargo` but `rustup`'s `rustc` wrapper,
and problems ensued when `cargo` thought it was using one version of
`rustc`, but actually wound up using something different.
It seems better to avoid silently interposing `rustup`'s toolchain
override mechanisms everywhere, rather than having to special-case OS
X. So let's factor out a general mechanism for removing the wrappers
`rustup` provides and use that for both `rustc` and `cargo`. The tests
need adjusting because we weren't triggering the unwrapping cases
before; we don't yet test the case where we really do need to unwrap.
That test can be left for a future patch.
Differential Revision: https://phabricator.services.mozilla.com/D29531
--HG--
extra : moz-landing-system : lando
We've not been checking the clang-cl version in use. This lack of
checking is bad, for a couple of reasons:
* Released versions of clang-cl differ drastically in their robustness;
* Only the most recent version of clang-cl supports aarch64.
We should check for a minimum version of clang-cl, just like our other
supported compilers. As a bonus, we can then start depending on
features that we know appear in the particular minimum clang-cl
version. (The current patch is motivated by `/clang:` command-line
support, but one could pick other things.)
Differential Revision: https://phabricator.services.mozilla.com/D30723
--HG--
extra : moz-landing-system : lando
Also for checker `modernize-avoid-bind` export the respective reliability index from config.yaml
Differential Revision: https://phabricator.services.mozilla.com/D30904
--HG--
extra : moz-landing-system : lando
(adds __build_class__ to the builtin sandbox and allow CombinedDependsFunction to be hashed)
Differential Revision: https://phabricator.services.mozilla.com/D28114
--HG--
extra : rebase_source : 967a394d10d41e3da322005c84757c001a3b74cb
extra : intermediate-source : 2be63fc923997e6865ab9abc4fa7fb728e55d532
extra : source : aed41a0c652ae3f8e4b4f76bfaa0c56130515a75
Also adjust 'basestring' usage in some places.
Differential Revision: https://phabricator.services.mozilla.com/D28102
--HG--
extra : rebase_source : f0fecd6b040336b0cf2f055e266fe37eea5a9a48
extra : intermediate-source : 712718250f0ba5c286c1fb6b6c7f370b713c7225
extra : source : 6b24ce2da518d8158e13627adb11c9fcad19c92a
shellutil.py needed special handling since it is invoked earlier than the
vendor directory adding we do, so it does not have six available.
Differential Revision: https://phabricator.services.mozilla.com/D28096
--HG--
extra : rebase_source : c5c611d280dc821747c9db736e4943c2cc421557
extra : intermediate-source : 30fb268b41fdc45937a22ab446a8805fb099c1f0
extra : source : d102292b6b5b812e7df165116410488d18042bd3
0.1.21 mishandles cargo package renames, which are a required
feature for Rust 2018 support. The latest version fixes this.
Differential Revision: https://phabricator.services.mozilla.com/D29946
--HG--
extra : moz-landing-system : lando
Under the hood, browsertime invokes a certain `visualmetrics.py`
script. That script depends on `ffmpeg` and ImageMagick's `convert`,
`compare`, and `mogrify` commands. It also depends on certain Python
packages.
So this installs those dependencies, and then wires up the evaluation
environment such that `./mach browsertime` can find the dependencies.
It also adds a `./mach visualmetrics` command for processing a
captured MP4 file in the same way that browsertime processes such a
file.
In order to avoid downloading dependencies multiple time, the existing
artifact cache is extracted. This is a small first step towards [Bug
1526021](https://bugzilla.mozilla.org/show_bug.cgi?id=1526021), which
might want to use this artifact cache as well.
At this time, hashes and filesizes are not verified. During
development, the upstream files changed multiple times, and it's not
worth being completely locked down while experimenting with this
functionality. If we start running this code in automation or in more
sensitive environments, we can build fetch tasks and TC indexes to
streamline the artifact gathering process.
It is expected that a future mach command will want to invoke
browsertime without suffering the overhead of invoking Python (and
mach, which is itself bulky) so a nod is given to exposing the
relevant environment pieces.
During testing, it was discovered that [MozillaBuild doesn't ship
git](https://bugzilla.mozilla.org/show_bug.cgi?id=1503028), so that
git repositories can't be used out-of-the-box on Windows. So instead
we use a [tarball link from github.com/$USER/$REPO/tarball/$COMMIT-LIKE](https://github.blog/2008-03-03-tarball-downloads/).
Differential Revision: https://phabricator.services.mozilla.com/D29442
--HG--
rename : python/mozbuild/mozbuild/test/test_artifacts.py => python/mozbuild/mozbuild/test/test_artifact_cache.py
extra : moz-landing-system : lando
Some media libraries use gas syntax in their assembly files. Rather than
converting these arm assembly syntax files for aarch64, we can use clang-cl
to build them directly.
Differential Revision: https://phabricator.services.mozilla.com/D27785
--HG--
extra : moz-landing-system : lando
Lint python/mozbuild/{mozbuild,mozpack}.
This makes sure we use byte strings (type(b'')) in many places.
This also has a few places where we know we want unicode, by enforcing it.
This code also has a few places where we call into windows API's which expect either all args to be unicode,
or all args to be bytestrings (not-unicode) so make sure those calls align.
This is the most risky of the stack, since there are some mach commands and codepaths that are neither excercised in automation
nor excercised in tests.
Differential Revision: https://phabricator.services.mozilla.com/D26645
--HG--
extra : rebase_source : 1ee367576bede0318a2db05644693d4f440a250a
extra : intermediate-source : 2516c350cba6f27eb204f0087728721abbb0e085
extra : source : 6351a29c5765c13c39ef6186f9e5e911e00420e7
Leaving one fix for an explicit review.
Lint python/mozbuild/{mozbuild,mozpack}. r=#build
Differential Revision: https://phabricator.services.mozilla.com/D26641
--HG--
extra : rebase_source : e14d7762c7802d98e24ee8f86b0167d96666d288
extra : intermediate-source : 79b0d1678dd2f6aadf60f480d902ddeca4a52c3a
extra : source : faadf440e7d7b0a8c473e2dee3fc90b27023814a
Lint python/mozbuild/{mozbuild,mozpack}.
ran './mach lint -l py2 -l flake8 -l shellcheck -l codespell -l yaml python/mozbuild/{mozbuild,mozpack}/ --fix' in order
to undo some black changes and get closer to making this folder able to be validated on every lint run
Differential Revision: https://phabricator.services.mozilla.com/D26640
--HG--
extra : rebase_source : 6b69b6ebcac73835b752607f7b5b4429de7f95cf
extra : intermediate-source : 114355f83d36188fac592c8c6497242c71b27ad6
extra : source : 51fbdf63bbce8f75fac407de305f826dc775fcb5
With this change tooltool.py also supports taskcluster credentials to be passed
(in json format) to --authentication-file option. RelengAPI tokens are still
working with this patch, just additional authentication is added.
Differential Revision: https://phabricator.services.mozilla.com/D27881
--HG--
extra : moz-landing-system : lando
The noatime option doesn't appear to have a significant impact on no-op
build times, even though the build system does a significant number of
file reads. Since macs have atime enabled by default, we should just
disable this check rather than give developers unhelpful error messages.
Differential Revision: https://phabricator.services.mozilla.com/D28906
--HG--
extra : moz-landing-system : lando
For some reason, using `tar -Jxf` with Windows paths fails, and that makes
`mach artifact toolchain` unable to pull .tar.xz archives on Windows.
However, executing `xz -d -c` works, and we can feed its output to
python's tarfile.
Differential Revision: https://phabricator.services.mozilla.com/D28779
--HG--
extra : moz-landing-system : lando
With this change tooltool.py also supports taskcluster credentials to be passed
(in json format) to --authentication-file option. RelengAPI tokens are still
working with this patch, just additional authentication is added.
Differential Revision: https://phabricator.services.mozilla.com/D27881
--HG--
extra : moz-landing-system : lando
Add basic support for 'mach gtest' on Android.
Handling of Android-only and desktop-only options is awkward; I hope to
re-visit this after bug 1519369.
Differential Revision: https://phabricator.services.mozilla.com/D28129
--HG--
extra : moz-landing-system : lando
`caskroom/versions` was replaced with `homebrew/cask-versions` in 2018.
Tap `caskroom/versions` instead of the old one.
If you have two taps, remove the old one using:
brew untap caskroom/versions
Differential Revision: https://phabricator.services.mozilla.com/D27839
--HG--
extra : moz-landing-system : lando
If the user runs mach clang-format from the builddir, it was finding and using
unified files.
Differential Revision: https://phabricator.services.mozilla.com/D27750
--HG--
extra : moz-landing-system : lando
The TestManifestBackend always has a dependency on config.status, even
if configure hasn't been run yet. If configure is run later, this is
intended to cause the TestManifestBackend to be regenerated so that it
can use the configured values instead of a potentially incomplete setup.
Mozbuild's backend_out_of_date() logic treats a missing file as always
being out of date, which means if configure hasn't run, the
TestManifestBackend will always be regenerated.
Instead we can create a stub config.status file that will fix the
out-of-date check, and can be treated as a
BuildEnvironmentNotFoundException as if the file didn't exist at all.
Differential Revision: https://phabricator.services.mozilla.com/D27195
--HG--
extra : moz-landing-system : lando
Bug 1537574 moved some code that uses errno from building.py to base.py,
but the latter didn't already import errno.
Differential Revision: https://phabricator.services.mozilla.com/D27125
--HG--
extra : moz-landing-system : lando
If mozbuild parsing fails due to a missing file (eg: a file not existing
in UNIFIED_SOURCES), then no Makefiles are written out, but
config.status exists. This would cause mozbuild to think that configure
doesn't need to run, and rely on make to perform the backend-out-of-date
check in rebuild-backend.mk. Unfortunately since no Makefiles were
written, the make command fails immediately and no attempt is made to
re-create the backend. Note that this is only a problem if the first
mozbuild parsing from a clobber build fails, otherwise there is
typically a top-level Makefile from a previous build to call into (at
which point make can determine it is out-of-date, and re-invoke itself).
The fix is to have the RecursiveMake backend re-use the same logic that
was introduced into mozbuild for alternate backends, and remove
rebuild-backend.mk. This way, mozbuild can always determine if the
backend needs to be regenerated, even if the initial parsing failed.
Test code was also relying on rebuild-backend.mk to generate the
TestBackend, but moving backend_out_of_date() into MozbuildObject allows
this code to be shared.
Differential Revision: https://phabricator.services.mozilla.com/D26262
--HG--
rename : build/gen_test_backend.py => python/mozbuild/mozbuild/gen_test_backend.py
extra : moz-landing-system : lando
If there are a large number of untracked files in the working directory, hg
will attempt to print them all out with the default pager. This does not
interact very will with commands that are built atop this functionality. We
set HGPLAIN=1 so that the underlying hg will not attempt to use a pager.
Differential Revision: https://phabricator.services.mozilla.com/D26607
--HG--
extra : moz-landing-system : lando
Before bug 938437, we had a rather large and error-prone
nsStaticXULComponents.cpp used to register all modules. That was
replaced with clever use of the linker, which allowed to avoid the mess
that maintaining that file was.
Fast forward to now, where after bug 1524687 and other work that
preceded it, we have a much smaller number of remaining static xpcom
components, registered via this linker hack, and don't expect to add
any new ones. The list should eventually go down to zero.
Within that context, it seems to be the right time to get rid of the
magic, and with it the problems it causes on its own.
Some of those components could probably be trivially be converted to
static registration via .conf files, but I didn't want to deal with the
possible need to increase the number of dummy modules in XPCOMInit.cpp.
They can still be converted as a followup.
Differential Revision: https://phabricator.services.mozilla.com/D26076
--HG--
extra : moz-landing-system : lando
If mozbuild parsing fails due to a missing file (eg: a file not existing
in UNIFIED_SOURCES), then no Makefiles are written out, but
config.status exists. This would cause mozbuild to think that configure
doesn't need to run, and rely on make to perform the backend-out-of-date
check in rebuild-backend.mk. Unfortunately since no Makefiles were
written, the make command fails immediately and no attempt is made to
re-create the backend. Note that this is only a problem if the first
mozbuild parsing from a clobber build fails, otherwise there is
typically a top-level Makefile from a previous build to call into (at
which point make can determine it is out-of-date, and re-invoke itself).
The fix is to have the RecursiveMake backend re-use the same logic that
was introduced into mozbuild for alternate backends, and remove
rebuild-backend.mk. This way, mozbuild can always determine if the
backend needs to be regenerated, even if the initial parsing failed.
Test code was also relying on rebuild-backend.mk to generate the
TestBackend, but moving backend_out_of_date() into MozbuildObject allows
this code to be shared.
Differential Revision: https://phabricator.services.mozilla.com/D26262
--HG--
rename : build/gen_test_backend.py => python/mozbuild/mozbuild/gen_test_backend.py
extra : moz-landing-system : lando
This is the only <radiogroup> and <radio> consumer in browser.xul.
By making the DOM get constructed on demand, we can avoid connecting
radios at startup, and it also gives us a chance to migrate the
strings to Fluent.
Differential Revision: https://phabricator.services.mozilla.com/D24914
--HG--
extra : moz-landing-system : lando
Makoto Kato
Justin Wood
Victor Porof
Andi-Bogdan Postelnicu
Ed Lee
Mike Hommey
Francesco Lodolo (:flod)
Andrew Halberstadt
Andreea Pavel
Ryan VanderMeulen
Jeane Carlos
Sylvestre Ledru
Samuel Thibault
Kartikaya Gupta
championshuttler
Cosmin Sabou
Rok Garbas
Dorel Luca
prathiksha
L. David Baron
Nick Alexander
Eric Rahm
Chris Manchester
Bob Clary
David Teller
Henri Sivonen
shindli
Jorg K
Jeremy Lempereur
Tom Prince
Nathan Froyd
Myk Melez
Dzmitry Malyshau
Robert Bartlensky
Ian Neal
Coroiu Cristina
Mike Shal
b4hand
Bastien Orivel
Mihai Alexandru Michis
Narcis Beleuzu
Csoregi Natalia
arthur.iakab
Valentin Gosu
Mark Banner
Emilio Cobos Álvarez
Jonathan Watt
Manish Goregaokar
Alexis Beingessner
Geoff Lankow
Geoff Brown
Dan Minor
Bastien Abadie
Panagiotis Astithas
Christian Frey
Ciure Andrei
Rob Wu
Mike Shal
Bobby Holley
Nicholas Cowles
Aaron Klotz
Petr Sumbera
Avery Berninger
Razvan Maries
Brian Grinstead