The FileAvoidWrite class does a bunch of stuff with bytes and strings
that doesn't work in Python 3. Make sure the object is handling only
bytes or only strings under the hood so Python 3 is happy.
The FileAvoidWrite unit tests written with MockedOpen don't work in
Python 3 either. Swap them out for vanilla pytest tests without
the MockedOpen dependency.
Differential Revision: https://phabricator.services.mozilla.com/D51341
--HG--
extra : moz-landing-system : lando
This will install ipython into the default virtualenv if it doesn't exist. Unless --no-virtualenv
is specified in which case an error will be printed.
Differential Revision: https://phabricator.services.mozilla.com/D53030
--HG--
extra : moz-landing-system : lando
`os.path.abspath` on Windows doesn't return a consistent value -- the capitalization can vary based on environmental factors that I don't fully understand. Regardless, normalize case where this function is called in config_status.
Differential Revision: https://phabricator.services.mozilla.com/D53889
--HG--
extra : moz-landing-system : lando
If configure is invoked manually, clobber.py is bypassed and the CLOBBER
file doesn't get touched. The clobber check in Makefile.in gets
triggered causing the build to stop.
Moving the objdir/CLOBBER file creation into configure.py should cause
it to be created regardless of how configure is invoked.
Depends on D53290
Differential Revision: https://phabricator.services.mozilla.com/D53291
--HG--
extra : moz-landing-system : lando
Bug 1596868 was triggered by forgetting a comma, turning an intended
tuple into a string, which Python dutifully iterated over as a sequence
of single characters. Let's add some basic typechecking so these sort
of mistakes don't happen again.
Differential Revision: https://phabricator.services.mozilla.com/D53815
--HG--
extra : moz-landing-system : lando
Now since we use unicode_literals by bug 1210157, mercurial version check will be error due to `TypeError: environment can only contain strings`.
So we don't use unicode for os.environment['PATH'] when appending Java path.
Differential Revision: https://phabricator.services.mozilla.com/D53139
--HG--
extra : moz-landing-system : lando
There's a lot of formatting that is irrelevant for Fluent,
and it's hard to diff usefully on the text file.
Instead, normalize the Fluent files by parsing them, and serialzing
them with Junk included.
Differential Revision: https://phabricator.services.mozilla.com/D53202
--HG--
extra : moz-landing-system : lando
The minidump-analyzer tool was originally conceived to be used from the crash
report client and as such was installed in the crash reporter client
application bundle on macOS. It was later adapted to work from Firefox itself
but this caused linking problems when invoked from the Firefox app bundle.
This patch moves the minidump-analyzer into the Firefox app bundle and adapts
the relevant code to find it there.
The minidump-analyzer was also not signed like the rest of our executables and
this patch addresses that issue too.
Differential Revision: https://phabricator.services.mozilla.com/D52910
--HG--
extra : moz-landing-system : lando
We need this for "full" C++17 support (everything is supported, but some
C++17 features still have bugs) and this change also brings Linux into
parity with our Mac requirements.
MANUAL PUSH: build toolchains on inbound to avoid clogging autoland
Differential Revision: https://phabricator.services.mozilla.com/D51450
This loader uses 'reader.find_variables_from_ast' to parse all *_MANIFESTS variables from
moz.build files using the abstract syntax tree. This means it will find all such variables
regardless of the current buildconfig.
Differential Revision: https://phabricator.services.mozilla.com/D51834
--HG--
extra : moz-landing-system : lando
Despite what the comment says, the finder *does* pick up the root moz.build. So
we end up processing it twice. This was never caught before because we only ever
used this function to read Sphinx related variables, of which the root moz.build
contains none.
Differential Revision: https://phabricator.services.mozilla.com/D51832
--HG--
extra : moz-landing-system : lando
This also moves the 'mach' docs from /python/mach to /mach. The reason being
that 'mach' doesn't really have anything to do with Python other than its
implemented in it.
Differential Revision: https://phabricator.services.mozilla.com/D52253
--HG--
extra : moz-landing-system : lando
Changes:
- use regular strings instead of byte strings when matching
- encode files in UTF-8 prior to hashing
Depends on D51414
Differential Revision: https://phabricator.services.mozilla.com/D51728
--HG--
extra : moz-landing-system : lando
Changes:
- change `urlparse` import to `urllib.parse` to make switch over to python3
Depends on D51414
Differential Revision: https://phabricator.services.mozilla.com/D51648
--HG--
extra : moz-landing-system : lando
Changes:
- update sections of `generate_sources_mozbuild.py` and `cmakeparser.py` to be python3 compatible
- change import of `urlparse` to be python3 compatible
Depends on D51414
Differential Revision: https://phabricator.services.mozilla.com/D51692
--HG--
extra : moz-landing-system : lando
The help view copies strings from the main menubar. When we moved the original DTD string
to ftl, there were performance implications for using it in browser.xhtml, so it was
only added once needed. The help view copies attributes from the items in the main menubar's
help menu, and so didn't copy the label for this item, resulting in the broken
behaviour.
To fix this, it's enough to have the string in the markup. As we've moved the other strings
into menubar.ftl, I'm taking the opportunity to move this string there, too, next to its
sibling string to report deceptive sites.
Differential Revision: https://phabricator.services.mozilla.com/D51850
--HG--
extra : moz-landing-system : lando
Add test annotations to the ReftestManifest and TestResolver. For example, a
test description from the TestResolver might now contain 'skip-if': 'skiaContent';
similar to the content provided for manifestparser tests; this will allow
'mach test-info report' to filter tests based on reftest manifest test
annotations.
Also add the referenced-test field which identifies the test file associated
with test entries for reference files; this will allow test-verify to
run the correct reftest when only the reference file has been modified.
Differential Revision: https://phabricator.services.mozilla.com/D51113
--HG--
extra : moz-landing-system : lando
This allows subclasses of MozbuildObject to define additional instance
arguments and still use 'from_environment'.
Differential Revision: https://phabricator.services.mozilla.com/D51174
--HG--
extra : moz-landing-system : lando
On Windows, './mach bootstrap' downloads 8 artifacts taking up 1GiB+ of
space. Given the current limits of 6 artifacts and 1GiB, this means a
full run of './mach bootstrap' doesn't actually use anything from the
cache. Each new artifact is over the limits, so the oldest artifact gets
removed from the cache before downloading the next one. Doubling the
limits here should give us some space to work with.
Depends on D50676
Differential Revision: https://phabricator.services.mozilla.com/D50677
--HG--
extra : moz-landing-system : lando
Artifacts are fetched to a local cache, and if the artifact in the cache
exists it won't be re-downloaded. However, the messaging suggested that
artifacts were always being downloaded when they were just re-used from
the cache, leading to confusion.
Differential Revision: https://phabricator.services.mozilla.com/D50676
--HG--
extra : moz-landing-system : lando
Separating these changes out into a separate patch/bug makes them a
little easier to verify. Turning on C++17 support should then be just a
matter of updating expected results.
Differential Revision: https://phabricator.services.mozilla.com/D47324
--HG--
extra : moz-landing-system : lando
Changes:
- remove the `unicode_literals` import from `test_archive.py` as it was causing failures when dealing with file paths
- mark failing tests with `xfail` annotations, to be investigated at a later date
Differential Revision: https://phabricator.services.mozilla.com/D49498
--HG--
extra : moz-landing-system : lando
Since bootstrap now pulls mozilla-unified it makes sense to reference the
unified repo as well as central.
Differential Revision: https://phabricator.services.mozilla.com/D49478
--HG--
extra : moz-landing-system : lando
This is needed to release a new mozlog with the PRECONDITION_FAILED
test and subtest status for use in web-platform-tests.
Update all in-tree dependencies on mozlog to >=5.0. These were found
with `hg grep 'mozlog.*[0-9]'`.
Only testing/web-platform/tests/tools/wptrunner/requirements.txt
remains on 4.2.0, and it will be updated in upstream wpt after mozlog
5.0 has been released.
Differential Revision: https://phabricator.services.mozilla.com/D50456
--HG--
extra : moz-landing-system : lando
Add code to clean up Git and Hg repositories, and invoke that where `./mach vendor rust` would throw an error. Unfortunately, `cargo vendor` also updates the repo's root `Cargo.lock` file in-place and while we could `git checkout`/`hg revert` that file for the user, `Cargo.lock` may have had pre-existing changes that would be overwritten by such a change. Instead of a potentially destructive update in the error case, I've opted to add an extra error message to tell you how to deal with that one file.
Differential Revision: https://phabricator.services.mozilla.com/D49494
--HG--
extra : moz-landing-system : lando
Changes:
- remove `uuid` from the python3 blacklist in `mach`
- enable `test_telemetry.py` for python3
- adjust test outcome expectation for Windows + python3, suspect `mozpack.path` is not filtering Windows path correctly in python3 environment
- switch file read mode between `r` and `rb` depending on version of python
Differential Revision: https://phabricator.services.mozilla.com/D45903
--HG--
extra : moz-landing-system : lando
The BuildReader's 'find_sphinx_variables' function is hardcoded to look for the
SPHINX_TREES and SPHINX_PYTHON_PACKAGE_DIRS variables. But it's otherwise
implemented to find any arbitrary variable (as long as they are a simple list
or dict).
This change simply moves the variable name(s) to the function call. The comment
about possibly wanted to use a higher level AST library to parse other kinds of
variables still applies, but for now this change is good enough to suit my
needs.
Differential Revision: https://phabricator.services.mozilla.com/D48424
--HG--
extra : moz-landing-system : lando
Fennec is removed, but mach install still tries to install Fennec. It should
install GVE instead.
Differential Revision: https://phabricator.services.mozilla.com/D48811
--HG--
extra : moz-landing-system : lando
Some generated files are missing in generated-sources.json so just add them.
Differential Revision: https://phabricator.services.mozilla.com/D48085
--HG--
extra : moz-landing-system : lando
This leaves the testharness files, because they are used in various mochitests.
Differential Revision: https://phabricator.services.mozilla.com/D49132
--HG--
extra : moz-landing-system : lando
This leaves the testharness files, because they are used in mochitest-chrome
tests in dom/animation/test.
Differential Revision: https://phabricator.services.mozilla.com/D49132
--HG--
extra : moz-landing-system : lando
This leaves the testharness files, because they are used in mochitest-chrome
tests in dom/animation/test.
Differential Revision: https://phabricator.services.mozilla.com/D49132
--HG--
extra : moz-landing-system : lando
Some fields of /etc/os-release are optional, so do not throw KeyError's when they're missing.
Differential Revision: https://phabricator.services.mozilla.com/D48984
--HG--
extra : moz-landing-system : lando
Adds a way for mochitest, reftest, and crashtests to skip XBL related
tests when XBL is disabled. Also, add an app constant so JS can
check whether XBL is enabled.
Depends on D45614
Differential Revision: https://phabricator.services.mozilla.com/D45615
--HG--
extra : moz-landing-system : lando
This does many things:
1) stops producing (and consuming) `FennecJNI*` JNI wrappers
2) removes the :app and :thirdparty Gradle projects
3) removes relevant pieces of the Gradle target configuration
4) updates lints
5) purges old configurations
After this commit, the `mobile/android` project/application builds
only GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D46536
--HG--
extra : moz-landing-system : lando
Environment should be bytes on Python 2 (to avoid Windows errors) and text on
Python 3. The 'ensure_subprocess' env utility function handles this.
Differential Revision: https://phabricator.services.mozilla.com/D48115
--HG--
extra : moz-landing-system : lando
This logic is very 'mozill-central' specific and should live outside of mach
core if possible. Luckily we already have a concept of a 'pre_dispatch_handler'
that is meant for exactly this type of use case.
Differential Revision: https://phabricator.services.mozilla.com/D47668
--HG--
extra : moz-landing-system : lando
Bug 1580996 cleaned up handling of `{application,platform}.ini` but
inadvertently populated `.ini` files from test archives into the
object directory. That causes issues, especially on try. Test INI
files should come from the local artifact build and not from the
upstream test archives.
Rather than re-instate the test at the time when processed test
archives are _unpacked_, the test is done as test archives are
packed/processed.
Differential Revision: https://phabricator.services.mozilla.com/D46862
--HG--
extra : moz-landing-system : lando
The `freestanding` library is built with specific compiler flags to signify
that it is indeed freestanding code. That is, it does not depend on a
standard library.
One of the requirements of freestanding code is that the toolchain still
expects implementations of `memcpy`, `memmove`, `memcmp`, and `memset`.
I did briefly implement my own naive versions of these functions, but that
solution is less than ideal since the implementations must be `extern` and are
thus picked up by the entire `firefox.exe` binary. This denies the rest of
`firefox.exe` the benefit of optimized implementations. On Windows, the
sandbox is linked into `firefox.exe`, so we cannot just shrug and
assume that naive implementations will not have any effect on anything.
There are, however, optimized implementations of these functions that are
exported by `ntdll.dll`. They are not included in the `ntdll.lib` that is
included in the Windows SDK. Using `llvm-dlltool`, we can build an import
library containing the missing entries and then add that library to `OS_LIBS`.
Depends on D43156
Differential Revision: https://phabricator.services.mozilla.com/D43157
--HG--
extra : moz-landing-system : lando
The `freestanding` library is built with specific compiler flags to signify
that it is indeed freestanding code. That is, it does not depend on a
standard library.
One of the requirements of freestanding code is that the toolchain still
expects implementations of `memcpy`, `memmove`, `memcmp`, and `memset`.
I did briefly implement my own naive versions of these functions, but that
solution is less than ideal since the implementations must be `extern` and are
thus picked up by the entire `firefox.exe` binary. This denies the rest of
`firefox.exe` the benefit of optimized implementations. On Windows, the
sandbox is linked into `firefox.exe`, so we cannot just shrug and
assume that naive implementations will not have any effect on anything.
There are, however, optimized implementations of these functions that are
exported by `ntdll.dll`. They are not included in the `ntdll.lib` that is
included in the Windows SDK. Using `llvm-dlltool`, we can build an import
library containing the missing entries and then add that library to `OS_LIBS`.
Differential Revision: https://phabricator.services.mozilla.com/D43157
--HG--
extra : moz-landing-system : lando
The `freestanding` library is built with specific compiler flags to signify
that it is indeed freestanding code. That is, it does not depend on a
standard library.
One of the requirements of freestanding code is that the toolchain still
expects implementations of `memcpy`, `memmove`, `memcmp`, and `memset`.
I did briefly implement my own naive versions of these functions, but that
solution is less than ideal since the implementations must be `extern` and are
thus picked up by the entire `firefox.exe` binary. This denies the rest of
`firefox.exe` the benefit of optimized implementations. On Windows, the
sandbox is linked into `firefox.exe`, so we cannot just shrug and
assume that naive implementations will not have any effect on anything.
There are, however, optimized implementations of these functions that are
exported by `ntdll.dll`. They are not included in the `ntdll.lib` that is
included in the Windows SDK. Using `llvm-dlltool`, we can build an import
library containing the missing entries and then add that library to `OS_LIBS`.
Differential Revision: https://phabricator.services.mozilla.com/D43157
--HG--
extra : moz-landing-system : lando
The `freestanding` library is built with specific compiler flags to signify
that it is indeed freestanding code. That is, it does not depend on a
standard library.
One of the requirements of freestanding code is that the toolchain still
expects implementations of `memcpy`, `memmove`, `memcmp`, and `memset`.
I did briefly implement my own naive versions of these functions, but that
solution is less than ideal since the implementations must be `extern` and are
thus picked up by the entire `firefox.exe` binary. This denies the rest of
`firefox.exe` the benefit of optimized implementations. On Windows, the
sandbox is linked into `firefox.exe`, so we cannot just shrug and
assume that naive implementations will not have any effect on anything.
There are, however, optimized implementations of these functions that are
exported by `ntdll.dll`. They are not included in the `ntdll.lib` that is
included in the Windows SDK. Using `llvm-dlltool`, we can build an import
library containing the missing entries and then add that library to `OS_LIBS`.
Differential Revision: https://phabricator.services.mozilla.com/D43157
--HG--
extra : moz-landing-system : lando
It was added in bug 1575760 and turns out to be causing a lot more
problems than anticipated.
However, the previous status quo is also not ideal, so we do
auto-generate .cargo/config.in instead, with a little trick that allows
to just copy it to .cargo/config instead of how individual scripts would
previously manually preprocess it.
Differential Revision: https://phabricator.services.mozilla.com/D46138
--HG--
extra : moz-landing-system : lando
New releases of the `adler32-rs` crate have this license, and we already
incorporate zlib into Firefox, so crates using this license should be allowed.
..and since `adler32-rs` now has an obviously acceptable license, we can
remove it from the list of build-time exceptions.
Differential Revision: https://phabricator.services.mozilla.com/D46283
--HG--
extra : moz-landing-system : lando
The underlying native libraries are identical between Fennec and
GeckoView example. This paves the way for removing Fennec entirely.
At the same, remove the `.ini` extraction, which is no longer required.
Differential Revision: https://phabricator.services.mozilla.com/D45769
--HG--
extra : moz-landing-system : lando
These were originally in exports because having it in the same tier as
the install rule interacted poorly with VPATH. Now that we no longer
have a generic VPATH rule, make can handle the rules properly with
everything in misc.
Differential Revision: https://phabricator.services.mozilla.com/D42969
--HG--
extra : moz-landing-system : lando
The build system has no clue that there is something to build in
dom/bindings/test. It's currently all handled via make rules generated
by the backend, but ideally, this would all be handled by the frontend
emitting appropriate GeneratedFiles and Sources objects.
In the meanwhile, we just force the make backend to recurse through
dom/bindings/test.
Differential Revision: https://phabricator.services.mozilla.com/D45124
--HG--
extra : moz-landing-system : lando
The build system has no clue that there is something to build in
dom/bindings/test. It's currently all handled via make rules generated
by the backend, but ideally, this would all be handled by the frontend
emitting appropriate GeneratedFiles and Sources objects.
In the meanwhile, we just force the make backend to recurse through
dom/bindings/test.
Differential Revision: https://phabricator.services.mozilla.com/D45124
--HG--
extra : moz-landing-system : lando
Having a full VPATH for the srcdir sometimes causes make to grab the
wrong prerequisite for a rule, in particular if we have a file in the
srcdir and also generate a file of the same name in the objdir. We don't
really need VPATH anymore though, since most of the information comes
from mozbuild, where we can explicitly list the path to the srcdir or
objdir as necessary.
Differential Revision: https://phabricator.services.mozilla.com/D42968
--HG--
extra : moz-landing-system : lando
The mach driver will now run all misspelled commands with Python 3. That means
we can't automatically execute the suggested command anymore, as it may need to
run against Python 2.
Ideally we could figure out a way to check the command against the 'mach'
whitelist, but until then, let's just disable automatic execution. Worst case
scenario we can turn it back on after the migration has finished.
Differential Revision: https://phabricator.services.mozilla.com/D44282
--HG--
extra : moz-landing-system : lando
Some commands use external argument parsers, so invoking |mach help <command>| will import
external modules (which may only be Python 2 compatible).
This makes sure that we detect the actual subcommand we're generating help for
and use the proper Python.
A much simpler solution would have been to run |mach help| with Python 2 all
the time. However, as we convert things to Python 3 this would have meant that
Python 3 only code would blow up. This would have forced us to continue
supporting Python 2, even for Python 3-only commands.
Differential Revision: https://phabricator.services.mozilla.com/D43989
--HG--
extra : moz-landing-system : lando
This fixes an edge case where a task needs to invoke the TestManifest backend from a source dir that doesn't have an objdir created yet.
Depends on D43513
Differential Revision: https://phabricator.services.mozilla.com/D43514
--HG--
extra : moz-landing-system : lando
Changes:
- remove binary encoding when the subdirectories are being collected
- do not open file in binary mode when reading from `telemetry_client_id.json`
Differential Revision: https://phabricator.services.mozilla.com/D44057
--HG--
extra : moz-landing-system : lando
MOZ_FULL_PRODUCT_VERSION is only used here, while tools/update-packaging/make_full_update.sh expects MOZ_PRODUCT_VERSION.
Depends on D44089
Differential Revision: https://phabricator.services.mozilla.com/D44090
--HG--
extra : moz-landing-system : lando
This removes these functions: bind, getaddrinfo, recvfrom, sendto, setsockopt,
socket from the check_networking test to allow for their use by the Rust mDNS
responder.
Differential Revision: https://phabricator.services.mozilla.com/D38488
--HG--
extra : moz-landing-system : lando
This removes these functions: bind, getaddrinfo, recvfrom, sendto, setsockopt,
socket from the check_networking test to allow for their use by the Rust mDNS
responder.
Differential Revision: https://phabricator.services.mozilla.com/D38488
--HG--
extra : moz-landing-system : lando
Fix some library calls and syntax that are required to support Python 3.
Depends on D39364
Differential Revision: https://phabricator.services.mozilla.com/D39365
--HG--
extra : moz-landing-system : lando
Make bootstrap.py compatible with both Python 3.5+ and Python 2.7. Remove
Python 2.6 support as Python 2.6 is no longer supported in the Firefox source
tree.
Differential Revision: https://phabricator.services.mozilla.com/D39364
--HG--
extra : moz-landing-system : lando
Add an option to run bootstrap.py with '--debug'. This will print full
tracebacks if the bootstrap process encounters an uncaught exception. It should
be useful for developers who are working on the bootstrap code as well as users
when writing bug reports.
Depends on D39362
Differential Revision: https://phabricator.services.mozilla.com/D39363
--HG--
extra : moz-landing-system : lando
Support installing the android development toolchain with Python 3 as well as
Python 2.7.
Depends on D39361
Differential Revision: https://phabricator.services.mozilla.com/D39362
--HG--
extra : moz-landing-system : lando
Add support for Python 3 and Python 2.7 to the Debian-based linux distro
bootstrap routines.
Differential Revision: https://phabricator.services.mozilla.com/D39361
--HG--
extra : moz-landing-system : lando
Add support for both Python 3 and Python 2.7 to the mozboot.base and
mozboot.bootstrap modules. Remove legacy Python 2.6 code or mark it for later
removal.
Depends on D39359
Differential Revision: https://phabricator.services.mozilla.com/D39360
--HG--
extra : moz-landing-system : lando
Add unicode_literals to all mozboot module __future__ statements to support
running the modules under Python 3. Remove comments about unicode_literals and
Python 2.6 support as Python 2.6 is no longer supported in tree.
Differential Revision: https://phabricator.services.mozilla.com/D39359
--HG--
extra : moz-landing-system : lando
Credit: mars for making the shell POSIX compliant
This embeds a blacklist of every mach command that needs to run with Python 2
directly in the mach driver itself. Initially this is every mach command. We
then use a bit of shell to determine whether the command being run needs Python
2 or 3.
While this approach may seem a bit hacky, it has several benefits:
1. No need to add complex machinery in mach's registration code.
2. No need to spawn two separate Python interpreters in the event a different
Python from the original interpreter is needed.
3. Perf impact is negligible.
4. New commands are Python 3 by default.
It is also only a temporary hack. Once all commands are running with Python 3,
we can revert back to the original mach driver.
Differential Revision: https://phabricator.services.mozilla.com/D36103
--HG--
extra : moz-landing-system : lando
Use of 'BaseException.message` was deprecated in Python 2.6 (and removed in
Python 3). We should rely on the exception's '__str__' instead.
We also need to ensure the mozconfig subprocess' output is text when formatting
it into the message with Py3.
Differential Revision: https://phabricator.services.mozilla.com/D42843
--HG--
extra : moz-landing-system : lando
Maybe back when .cargo/config.in was added, the directory indicated for
vendored crates needed to be absolute. That is at least not the case
with the current supported versions of rust.
The current setup has a few caveats:
- .cargo/config.in has shown to become stale (it currently contains
multiple unused entries)
- non-gecko build tasks have to generate a .cargo/config on their own if
they want to use vendored crates
- in turn, non-gecko build tasks that don't, may unknowingly get their
dependencies from crates.io (see the recent attempt at moving
geckodriver builds to a separate task).
By checking in a .cargo/config file, we can alleviate the last two, but
that comes at the price of `cargo update` not wanting to act when
.cargo/config exists, because of the source replacement configuration.
But rust vendor gently generates a suitable configuration on its own, so
we can use that to generate a .cargo/config automatically. Which
addresses the first caveat of the current setup. That leaves us with
`cargo update` not working out of the box, but that just requires people
running it to manually remove .cargo/config first. Which is arguably
what rust wants you to do in the first place. It's kind of incidental
that we started with a .cargo/config.in rather than .cargo/config.
Now, while a simple .cargo/config works, that's not enough for the case
where the objdir doesn't live inside the source directory. In that case
cargo looks for the configuration from the objdir, and fails to find it.
So we still need a .cargo/config.in, which we generate with a little
trick.
Differential Revision: https://phabricator.services.mozilla.com/D43012
--HG--
rename : .cargo/config.in => .cargo/config
extra : moz-landing-system : lando
We'll require preprocessing that configure subst files don't allow in
the next change, so prepare for that.
Differential Revision: https://phabricator.services.mozilla.com/D43011
--HG--
extra : moz-landing-system : lando
Straight-forward addition of the --no-install option for reftest, just like
the existing option for mochitest. For gtest, I alos noticed the mach command
help needed some cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D43299
--HG--
extra : moz-landing-system : lando
This time, existing config.status trying to import it will throw an exception
that will trigger a re-configure.
Differential Revision: https://phabricator.services.mozilla.com/D43215
--HG--
extra : moz-landing-system : lando
As seen in bug 1575774/1575959, things can go badly when config.status
doesn't match expectations, especially when most mach commands try to
read it, starting with mach clobber, which is supposed to be the one
commant to get away from most problems.
The idea here is to throw a recognizable exception so that callers can
react accordingly. While not obvious from the patch, the result is that
running e.g. mach build with a broken config.status will automatically
run configure (because the relevant caller actually handles the rethrown
exception that way).
There are other calls to from_config_status in the mozbuild reader, but
that can't be reached before MozbuildObject.config_environment.
Differential Revision: https://phabricator.services.mozilla.com/D43214
--HG--
extra : moz-landing-system : lando
Older config.status laying around in old trees are read by mach whenever
it runs, including when running mach clobber. Those files still try to
include mozbuild.util.encode, which is not here anymore. So we restore
the function for now to unbreak those.
Differential Revision: https://phabricator.services.mozilla.com//D43132
--HG--
extra : histedit_source : 3eb10cc8e18cc9094887061b00705afb6e705b54
Note that cargo vendor always uses the native version even when
cargo-vendor was already installed, so there is no concern wrt that.
Differential Revision: https://phabricator.services.mozilla.com/D43007
--HG--
extra : moz-landing-system : lando
Bug 1522788 changed how MozbuildObject gets a value for @CONFIG_GUESS@
in mozconfigs, and it's not entirely reliable to manually call
config.guess in test_base. As a matter of fact, in some cases,
config.guess is not even invoked by MozbuildObject (like, on Windows).
Plus, the config.guess invocation in the test currently doesn't work on
Windows on automation, for some reason.
Differential Revision: https://phabricator.services.mozilla.com/D42755
--HG--
extra : moz-landing-system : lando
Python 3.7 changed what it escapes with re.escape. Adapt mozpath.match
to account for this.
Differential Revision: https://phabricator.services.mozilla.com/D42750
--HG--
extra : moz-landing-system : lando
Now that the configuration comes in without bytes strings, there is no
need to convert it anymore.
Differential Revision: https://phabricator.services.mozilla.com/D42631
--HG--
extra : moz-landing-system : lando
With bug 1575135, we ensure nothing gets out of the configure sandbox
as a bytes string. We can thus now avoid the encode() pass in
configure.py. We still need, however, to normalize the configuration
so that it doesn't contain unexpected types, and conformning to what
indented_repr does to the configuration in config.status.
While here, convert some obj.iteritems() to six.iteritems(obj).
And remove the now unused encode function.
Differential Revision: https://phabricator.services.mozilla.com/D42630
--HG--
extra : moz-landing-system : lando
The configure sandbox has wrapped subprocess methods to add its own
encoded environment if none is provided, since bug 1520394. It only
makes sense that it normalizes the environment that comes in too,
avoiding caller in the configure sandbox to have to do it themselves.
OTOH, and while we're here, none of get_cmd_output, old_configure or the
sandbox were actually using the right encoding for this conversion, so
fix the configure sandbox to use the right one, and make it stop using
encode(), which does deep recursion that is not necessary here, and that
I'm trying to remove entirely.
Also while here, remove an unused import of encode().
Differential Revision: https://phabricator.services.mozilla.com/D42608
--HG--
extra : moz-landing-system : lando
There are a few problems with the strategy currently used to find the
rust target. For example, we don't find a target for arm freebsd, and we
pick the wrong target for armel linux. Both are related to how things
currently work when multiple targets have the same (cpu, endianness,
os).
So, to derive the rust target, we now use a more fine-grained approach.
Differential Revision: https://phabricator.services.mozilla.com/D41481
--HG--
extra : moz-landing-system : lando
The order that PerSourceFlags are emitted can vary if the srcdir is
changed. By sorting them we can make sure that the backend.mk files are
consistent regardless of srcdir.
Differential Revision: https://phabricator.services.mozilla.com/D42965
--HG--
extra : moz-landing-system : lando
Make it a hard error when the sandbox returns non-unicode strings.
This should help quickly catch any remaining non-unicode string that
are not caught by automation.
Differential Revision: https://phabricator.services.mozilla.com/D42607
--HG--
extra : moz-landing-system : lando
As a consequence, we can replace the encoded_open function that did the
same in an opt-in manner.
Differential Revision: https://phabricator.services.mozilla.com/D42605
--HG--
extra : moz-landing-system : lando
It only happens when things go badly, which is why it doesn't cause
problems, but when moving things around, triggering the error, we
currently get a formatting error rather than the actual error.
Differential Revision: https://phabricator.services.mozilla.com/D42602
--HG--
extra : moz-landing-system : lando
