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
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
Make the target and host targets depend on those, and flatten the
dependencies.
That is, instead of chains like:
browser/app/target: mozglue/build/target
mozglue/build/target: memory/build/target
we now have:
browser/app/target: browser/app/target-objects \
mozglue/build/target-objects \
memory/build/target-objects
Which means Make can feel free to build the object files in browser/app
before building other dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D42252
--HG--
extra : moz-landing-system : lando
With the addition of toolkit/library/build because of the rust
shenanigans, bug 1573314 and bug 1572046 don't do anything useful
anymore. We're going to do something better anyways.
Differential Revision: https://phabricator.services.mozilla.com/D42251
--HG--
extra : moz-landing-system : lando
HostLibrary is always an expand lib. HostRustLibrary is always a
non-expand lib. But we currently rely on type checking to figure that
out, rather than an attribute, like for StaticLibrary. Doing that
simplifies existing and upcoming code.
Differential Revision: https://phabricator.services.mozilla.com/D42250
--HG--
extra : moz-landing-system : lando
Apart from the need to link them last, they don't actually need to be
treated any different from normal static libraries.
Differential Revision: https://phabricator.services.mozilla.com/D42249
--HG--
extra : moz-landing-system : lando