New Android-Gradle plugins pin the build-tools version, and we want to
be consistent between Gradle and moz.build.
MozReview-Commit-ID: ApWS4rHzPuH
--HG--
extra : rebase_source : 38a9781c472d858f3300cbbcbdc6d2311c465713
IntelliJ should still work, but we're committed to Android Studio at
this point.
MozReview-Commit-ID: 3BaXB4dh4vA
--HG--
extra : rebase_source : 9c48f5c81613f77b32614b6f50b4e502a11fa4f0
New Android-Gradle plugins pin the build-tools version, and we want to
be consistent between Gradle and moz.build.
MozReview-Commit-ID: ApWS4rHzPuH
--HG--
extra : rebase_source : 5a5730b4b9ce84af40a7c73c4f1abba017103f02
IntelliJ should still work, but we're committed to Android Studio at
this point.
MozReview-Commit-ID: 3BaXB4dh4vA
--HG--
extra : rebase_source : a17d797c8c2c70e792c0556e74b964d4975a315b
Mach test now creates a structured logger and passes it down into all
of the various test harnesses. Except |mach python-test| doesn't use
structured logging yet, so the argument is not expected.
For now, just accept **kwargs and ignore the logger. Eventually we'll
want to get python tests to use structured logging, and we can use it
at that point.
MozReview-Commit-ID: 8LwdbgI0vqR
--HG--
extra : rebase_source : 8949f60f74c7623c6514711db022cbbd393ff7ce
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
Mach itself now depends on 'six', so it needs to be packaged in the test archive.
MozReview-Commit-ID: 8lWc0cxwrss
--HG--
extra : rebase_source : fc25b5dec23d0864905ebb116114b5ef37f0595b
I'm pretty certain nobody relies on this any more. The original
use of this code was to support virtualenv creation in configure.
Now that configure is written in Python and that Python code calls
out to the VirtualenManager API directly, this wrapping code isn't
used.
MozReview-Commit-ID: Cii1GjVOGaA
--HG--
extra : rebase_source : e9d2a4a85ccbdd6c0520392a9b187bfd45afc77b
The Python version validation in virtualenv.py is only called in 2
locations: `python -m mozbuild.virtualenv` and in moz.configure.
I believe that nobody calls `python -m mozbuild.virtualenv` any more.
That means that moz.configure is the only caller of
verify_python_version(). That means we can inline the logic into
moz.configure.
It makes sense for version checking to live in moz.configure because
the role of moz.configure is to evaluate the sanity of the environment.
So this commit does just that.
MozReview-Commit-ID: 7FLL0cGblFS
--HG--
extra : rebase_source : 4c2ecbe06399aad917f58ffb25a571993b736965
This alias is super common. It exists for other mach commands. Seems
useful to have for consistency.
MozReview-Commit-ID: 3gBvIHcMEZs
--HG--
extra : rebase_source : 766402097bbcce0e59d86372a70fb67142deb933
When multiple SCHEDULES are set for the same file (for example in different
files), combine them in a sensible way: the union of inclusive components, and
whichever has set its exclusive components.
Two conflicting assignments to SCHEDULES.exclusive is considered an error. We
might relax this situation later if a sensible answer can be determined. Note
that this error will only be detected when a reader consults the relevant file.
MozReview-Commit-ID: A49L9ISZXOE
--HG--
extra : rebase_source : bfb7709becc3aa0b4f1bc12eb45ec3b1ed21e5ed
When multiple SCHEDULES are set for the same file (for example in different
files), combine them in a sensible way: the union of inclusive components, and
whichever has set its exclusive components.
Two conflicting assignments to SCHEDULES.exclusive is considered an error. We
might relax this situation later if a sensible answer can be determined. Note
that this error will only be detected when a reader consults the relevant file.
MozReview-Commit-ID: A49L9ISZXOE
--HG--
extra : rebase_source : 1c5ea3b0f1fc1a7717843d0fd2d8191e924d724b
..and remove support for when.files-changed in the test kind. It is still used
for other kinds, and that will be addressed in other bugs.
This is re-landing of this bug, now without running test-verify excessively.
MozReview-Commit-ID: GBilXAktICZ
--HG--
extra : rebase_source : 6cc9a3b5a365d74689946bfa0296f51bc08c2113
We currently use a 32-bit Rust toolchain for win32 builds, but this can lead
to OOM situations. This patch makes win32 builds use a 64-bit Rust toolchain,
which requires a little bit of extra configuration because rustc needs to
be able to find a link.exe that produces 64-bit binaries for building
things like build scripts, which are host binaries.
We will now generate a batch file that sets LIB to the paths to 64-bit
libraries and invokes the x64-targeting link.exe, and add a section to the
.cargo/config file to instruct cargo to use that batch file as the linker
when producing 64-bit binaries.
MozReview-Commit-ID: 9vKBbm7Gvra
--HG--
extra : rebase_source : 599b3b661c7a8a5db1f32a2a9732fc202fb55e1e
- Add node as a dependency on Linux and Mac
- Add python3 for Mac only (linux generally has it installed already).
MozReview-Commit-ID: EpNWFTI9UXc
--HG--
extra : rebase_source : 755e8575e6e6c261c1ccaf9e5fe08e66502a4c3c
Sometimes, one just wants to run a one-off script with access to all
(or most) the libraries available like mozbuild, etc. but without
the weight of the whole virtualenv, which implies having an objdir
setup, etc.
One of my use cases is to run our preprocessor before the objdir is even
setup, and I'd rather not have one automatically created.
--HG--
extra : rebase_source : a6ad30a47ea8e497b274845caf7a9504b9f13282
This makes sure the mozterm module is available to the testers. The
setup.py was needed to it could be installed from requirements.txt.
This module does not yet live on pypi.
MozReview-Commit-ID: 9AL0EZ1uVgL
--HG--
extra : rebase_source : 882d4ec5ec9b80f20ca63e5c7303752427b390d2
This makes sure the mozterm module is available to the testers. The
setup.py was needed to it could be installed from requirements.txt.
This module does not yet live on pypi.
MozReview-Commit-ID: 9AL0EZ1uVgL
--HG--
extra : rebase_source : 4052f60e5e793d912045a9bd420d70c59e8a69fb
mesa is not necessary as of bug 938489 (there was even a bootstrap patch
that never landed)
libiw is not necessary as of bug 799391.
libnotify is not necessary as of bug 783765.
--HG--
extra : rebase_source : f6ecc18e50f8f92cb02ed16c87a6192800ea250d
We no longer support Android/armv6 and we requires NEON for Android/arm, so
we can remove armv6 support for Android.
MozReview-Commit-ID: Hh17BTyE0wR
--HG--
extra : rebase_source : 57e043ecb1bb57a026c0b656b82768b899ddae78
At the same time, we make it actually do something on spidermonkey
builds. We also add an environment variable alternative, that we use
in mozconfig.stdcxx, allowing for mozconfig.no-compile to override it
and avoid configure failures on e.g. artifact builds.
--HG--
extra : rebase_source : b68d362025e0c99f9184a03391c652ec2c9357ad
Bug 1325632 added some facility to add target compiler flags. This
change extends it to add allow adding host compiler flags as well.
--HG--
extra : rebase_source : 424b405a1d8f9a4778ff75c3308c9622f050e194
We currently use a 32-bit Rust toolchain for win32 builds, but this can lead
to OOM situations. This patch makes win32 builds use a 64-bit Rust toolchain,
which requires a little bit of extra configuration because rustc needs to
be able to find a link.exe that produces 64-bit binaries for building
things like build scripts, which are host binaries.
We will now generate a batch file that sets LIB to the paths to 64-bit
libraries and invokes the x64-targeting link.exe, and add a section to the
.cargo/config file to instruct cargo to use that batch file as the linker
when producing 64-bit binaries.
MozReview-Commit-ID: 9vKBbm7Gvra
--HG--
extra : rebase_source : 366dd966cafe4f07b8e59fc170d2db2dada32627
Prior to bug 1224450, CompileDB used data from the Makefiles to generate
the compilation command-lines. Now that the data is derived entirely
from moz.build, we don't need to check that the Makefile is present.
This enables a simple "ac_add_options --build-backends=CompileDB"
mozconfig to work without building a make backend first.
MozReview-Commit-ID: 9tYumyUyg5Y
--HG--
extra : rebase_source : 979f729076b3ab4fd719924877b7ef195e34bfd7
For cases like BackendMakefile where we don't have access to
BuildBackend._write_file(), we need to make sure that FileAvoidWrite
uses the dry-run flag in order to avoid writing out files during a
config.status --dry-run.
MozReview-Commit-ID: ApsSQPySImt
--HG--
extra : rebase_source : 70775f48b7bbea82ce94b0cd9467815c2abe8e8c
This commit adds a frontend construct, `GN_DIRS`, to facilitate building
gn projects with moz.build. Directories added to `GN_DIRS` get particular
treatment by two build backends added here as well, `GnConfigGen` and
`GnMozbuildWriter`.
The `GnConfigGen` backend runs `gn gen` for a gn project specified in
`GN_DIRS` and dumps this configuration as json, which is filtered to include
only those elements that will be needed by mozbuild. `gn gen` is run in
the context of a single build's configuration, so when adding or updating
a gn project it will be necessary to run this step with each supported
configuration.
The `GnMozbuildWriter` aggregates the config files generated by the
`GnConfigGen` backend, which it expects to find in the `gn-configs` directory
under the directory specified to `GN_DIRS`. The result is written to a set of
moz.build files suitable for building the project that are intended to be
checked in to the tree.
Once these moz.build files are checked in to the tree the project can be built
as any other directory: when using a general purpose build backend such as
RecursiveMake or FasterMake to build, entries in `GN_DIRS` will be treated as a
normal entries in `DIRS`.
MozReview-Commit-ID: KlHuP4DY2R4
--HG--
extra : rebase_source : b16079b3417bee3e58b0ecc8724b54c1b9d87d98
This has the virtue of not executing python three times during configure
just to read the same value of milestone.txt and munge it. We can also
remove milestone.py as a happy side effect, so all the milestone
computations can be done in init.configure.
Bug 1416891 introduced a line in moz.build that uses
LOCALIZED_FILES['..'], which ended up created a BackendTupfile object
for 'dist/bin/browser/../Tupfile' separate from the BackendTupfile
object for 'dist/bin/Tupfile'. Since both objects write to the same
file, the one with a '..' in the path ended up clobbering the original
one.
This patch makes two small changes, either of which would be sufficient
to fix the problem. First, we only get the backend file in
_process_final_target_files() when we actually use it (the
LOCALIZED_FILES in this case goes through the else case). Second, we now
call normpath in _get_backend_file() to ensure things like '..' are
resolved so that any future cases of 'Tupfile' and 'foo/../Tupfile'
end up pointing to the same object.
MozReview-Commit-ID: KDGBdtQ18lK
--HG--
extra : rebase_source : 8322e6bfccf2db8ee303e1ecf6ae954380b1ebc7
These files fail to build in the tup backend because the --locale
argument is missing and scripts like generate_update_locale.py require a
locale. Since the tup backend currently only supports en-US, we can just
hardcode this argument for now.
MozReview-Commit-ID: 7Js1yd9QB01
--HG--
extra : rebase_source : 387b5cfd0379ae3fd857e8c58722cfbca189e058
Nick Alexander
Dorel Luca
Dustin J. Mitchell
Andrew Halberstadt
Margareta Eliza Balazs
Tim Nguyen
Sylvestre Ledru
Narcis Beleuzu
Gregory Szorc
Ciure Andrei
Sebastian Hengst
Ted Mielczarek
Mark Banner
Mike Hommey
Zibi Braniecki
Pierre Bertran
Makoto Kato
Tom Prince
Ryan VanderMeulen
Andreea Pavel
Csoregi Natalia
Mike Shal
Chris Manchester
Cosmin Sabou
Nathan Froyd