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
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
When bootstraping the development environment on a machine without
rustup installed, download and install rustup version 1.9.0,
released 2018 January 4, instead of the older 1.5.0.
This saves a self-upgrade step in the short term and reduces the
chance of lost support failures in the long term.
MozReview-Commit-ID: H8ouRszLMsP
By ignoring existing .hgrc we make sure we don't try to load extensions
and have a consistent output. Especially we won't have error messages
that could confuse us into extracting a wrong version number.
MozReview-Commit-ID: FwrfcbY8QpN
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
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
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
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
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
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
..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
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
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.
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
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
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.
