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
Bug 1256642 introduced magic at the emitter level to determine whether a
binary contains C++ sources and should be linked with the C compiler or
the C++ compiler.
Unfortunately, the Binary() moz.build template always adds C++ OS
libraries on Android (through STLPORT_LIBS), and C++ libraries on Linux
(stdc++compat).
The latter only ends up forcing every Binary() to be linked with the C++
linker, which is unfortunate, but doesn't cause much problems. The
former, however, involving OS libraries, the magic from bug 1256642
doesn't kick in, so we end up trying to link C++ OS libraries with the C
linker. Which ends up failing, because the libraries in STLPORT_LIBS
require -lm, which, while it's added by the C++ compiler when linking,
is not when the linkage is driven by the C compiler.
Because the fallible library, linked to all GeckoBinary()s is a C++
library, we still ended up linking with the C++ compiler on Android, so
this wasn't actually causing any problem... until I tried to remove that
fallible library in bug 1423803.
Anyways, the core problem is that moz.build evaluation is happening too
early to know whether any C++ sources are being linked together, so
there is no way the Binary() template can do the right thing. So this
change moves the logic to the emitter.
This also changes the type of STLPORT_LIBS to a list.
--HG--
extra : rebase_source : a70ddf7a132f94dc10e7e1db94ae80fb8d7a269f
Since bug 1421097, rust 1.22.0 is required to build, but
mozboot was still considering 1.21.0 sufficiently new.
bumpt the version there as well so `./mach bootstap`
will update to the required version.
MozReview-Commit-ID: moYo0KSsU
--HG--
extra : rebase_source : 900a962f5742b24ccd6ce3decc0242ff4fe36456
The process_define_files action uses the PartialConfigEnvironment to
query buildconfig values, but it should only be doing it for 'define'
and 'undef' statements. It was incorrectly also querying the
PartialConfigEnvironment with other preprocessor statements like 'if'
and 'include', which caused bogus entries to appear in the generated
dependency file.
MozReview-Commit-ID: IJptyXGluC7
--HG--
extra : rebase_source : a30aed7a37ec8d9c993cad22dc7f4bef1064edef
The name 'relativedir' is ambiguous - it is unclear whether it is a
relative srcdir or objdir. Rename it to 'relsrcdir' in the
ContextDerived() object to match the naming used in Context() so it is
obvious that it is a relative srcdir.
Most of these are a straight text replacement from relativedir to
relsrcdir, except for tup.py:_get_backend_file(), which was supposed to
be using an objdir in the first place.
MozReview-Commit-ID: 9eFHOCMofq5
--HG--
extra : rebase_source : bcd981953fcd72a8c049de02eca9cf31c04dff3c