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
So that isinstance(foo, StaticLibrary) doesn't end up being true for
HostRustLibrary. Instead, it now inherits from HostLibrary.
Differential Revision: https://phabricator.services.mozilla.com/D42248
--HG--
extra : moz-landing-system : lando
The existing check is no thorough enough: it only checks that multiple
Rust libraries are not directly linked to the same binary, but that's
not enough. In fact, until the change prior to this one, this was
happening to xul-gtest, and without that change, this is what configure
would now have to say:
Cannot link the following Rust libraries into the "xul-gtest" library:
- gkrust-gtest
- gkrust
Only one is allowed.
This only ended up not being a problem because the backend somehow works
around the problem, which it shouldn't have to do.
Differential Revision: https://phabricator.services.mozilla.com/D42247
--HG--
extra : moz-landing-system : lando
The Puppeteer test flavour are functional tests for the CDP-based
Puppeteer library from Google, that we want to run against our
implementation of CDP for Firefox.
They are distinct from the Firefox Puppeteer tests based on Marionette.
Differential Revision: https://phabricator.services.mozilla.com/D37012
--HG--
extra : moz-landing-system : lando
The Puppeteer test flavour are functional tests for the CDP-based
Puppeteer library from Google, that we want to run against our
implementation of CDP for Firefox.
They are distinct from the Firefox Puppeteer tests based on Marionette.
Differential Revision: https://phabricator.services.mozilla.com/D37012
--HG--
extra : moz-landing-system : lando
When a directory, like toolkit/library, builds both a static and a
shared library, and another, like toolkit/library/gtest, depends on the
static part, it currently needs to wait for the shared library to be
finished building, preventing both libraries being built in parallel.
By separating shared libraries to a different target, we allow more
parallelism to the build.
Differential Revision: https://phabricator.services.mozilla.com/D41099
--HG--
extra : moz-landing-system : lando
This patch makes BuildEnvironmentNotFoundException a subclass of AttributeError as well, because hasattr in
python3 no longer catches all tracebacks but only AttributeError, and we use both hasattr and
BuildEnvironmentNotFoundException to guard against a handful of buildconfig variables in a few places
where it is OK to not have a buildenvironment.
We also use universal_newlines in real_host in init.configure (since I found
that fix while working on the AttributeError one) so that we get the right string type back from the process call
Lastly this patch also uses BytesIO for calling into a ReducedConfigureSandbox as its stdout and stderr pipes,
This ensures that related code handling the sandbox doesn't complain about getbuffer() missing in StringIO in py3.
Differential Revision: https://phabricator.services.mozilla.com/D36605
--HG--
extra : moz-landing-system : lando
The build docker images need python-dev installed to build psutil, used
by the build resources monitor.
Differential Revision: https://phabricator.services.mozilla.com/D40781
--HG--
rename : python/mozbuild/mozbuild/resources/html-build-viewer/index.html => python/mozbuild/mozbuild/resources/html-build-viewer/build_resources.html
extra : moz-landing-system : lando
The longer version is that this changes how the HTML viewer looks up
files. Instead of looking at a list file that contains a list of
build resources data, it now looks at a build_resources.json file that
either contains data directly, or a list of files containing data.
Differential Revision: https://phabricator.services.mozilla.com/D40780
--HG--
extra : moz-landing-system : lando
It causes confusion because it's the mode used to _read_ the overwritten
file. Make that more obvious by renaming to `readmode`.
Differential Revision: https://phabricator.services.mozilla.com/D39445
--HG--
extra : moz-landing-system : lando
There is less incentive to keep things building with older versions of
clang for OSX builds, and we're going to require an objective-C feature
that was added in clang 5.
Differential Revision: https://phabricator.services.mozilla.com/D38581
--HG--
extra : moz-landing-system : lando
