We need to set up the notebook deps.
The train of patch re-activated some
tests that required the dependencies used
by the notebook, which were not added in the
path.
Differential Revision: https://phabricator.services.mozilla.com/D73936
It's not maintained and doesn't work as-is. If we want to revive it we can grab it from source control later, but in the meantime it's just confusing and it comes up in search results even though we never look for it.
Also delete `mach analyze` which depends on the existence of a Tup backend.
Differential Revision: https://phabricator.services.mozilla.com/D73911
It's not maintained and doesn't work as-is. If we want to revive it we can grab it from source control later, but in the meantime it's just confusing and it comes up in search results even though we never look for it.
Also delete `mach analyze` which depends on the existence of a Tup backend.
Differential Revision: https://phabricator.services.mozilla.com/D73911
This patch implements the new intermediate results standard and adds the mechanisms required to handle it. Results validation is done with jsonschema and some manual validation (because of some unfortunate issues with jsonschema) and some tests were implemented to ensure that we fail/pass where expected. The metrics modules were modified to handle multiple suites.
One thing that is disabled in this patch is the subtest/single-metric specifications through the "results" field. We'll do one thing at a time here and we also have no use for subtests yet (although we definitely will).
Differential Revision: https://phabricator.services.mozilla.com/D72067
`./mach bootstrap` prepares your environment for a build and installs missing "brew" packages".
However, if a package is installed but out-of-date, it was being ignored by the bootstrapping logic.
This change ensures that `brew update` is run, and updates any out-of-date packages that are requested.
Differential Revision: https://phabricator.services.mozilla.com/D72956
There are `conditions` in tree that are callables but which don't have a `__name__` attribute; for example, `functools.partial` instances don't have a `__name__` since they're effectively anonymous functions. If you get to this branch and one of your `conditions` are that kind of object then you'll get a confusing error message instead of the understandable one we're trying to produce here, so account for that possibility.
Differential Revision: https://phabricator.services.mozilla.com/D72957
This warning dates from bug 910487, which was 7 years ago. Since joining Mozilla I have *always* gotten this warning, and as far as I can tell since I never had a pre-2019 version of Visual Studio on my dev machine, the VS90COMNTOOLS variable was *never* set. Moreover, the "hack" is written in such a way that it does nothing *unless* you have `VS{100,110,120}COMNTOOLS` set, which I never have on my machine either, as you might expect since I only have the one version of Visual Studio installed.
The [latest public build documentation](https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Windows_Prerequisites) recommends that you install the Community edition of Visual Studio 2019, and as of 2019 the variable that's being used is `VS160COMNTOOLS`, so the only way someone would get value out of this hack is if they're using a substantially older version of Visual Studio than we recommend anyway.
Since 1) I *suspect* the hack is not doing anything for the large majority, if not all, of the people currently running builds on Windows on a day-to-day basis and 2) even if the hack continues to do something useful under some hypothetical scenarios, the content of the hack as well as the corresponding warning is so outdated that it should be updated anyway, I propose deleting it entirely.
Differential Revision: https://phabricator.services.mozilla.com/D72925
This patch adds support for tests metadata. A test script parser is added as
well as a new "doc" flavor that can be used to display the script info in the
command line. This parser will be the basis for building automated docs and
scripts verifications if we want to do this.
Differential Revision: https://phabricator.services.mozilla.com/D72800
The current way to get outgoing files in Git passes every branch to merge-base, which generates a way too long command that fails on Windows. This patch tries using `git log --not --remotes` instead of passing merge-base value.
Differential Revision: https://phabricator.services.mozilla.com/D71802
pip-compile can annotate each requirement with a reason why it is included (e.g.: transitive dependency, or depended-on directly).
When annotating direct dependencies, it notes it as "via -r <direct path to requirements.in file>".
Since we were using a temporary directory, the path of the directory was being included, making the output non-deterministic.
This change ensures that we run pip-compile in the same working directory as the temporary requirements file, enabling
the annotations to be deterministic: "via -r requirements-mach-vendor-python.in".
Differential Revision: https://phabricator.services.mozilla.com/D72181
`os.path.realpath` in Python 3.8 now always uppercases Windows drive letter, while it was just an alias of `os.path.abspath` in Windows. This patch uses `.realpath()` consistently to get `topobjdir` to fix the incompatibility from the behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D72188
Split out jsreftest and jittest files into their own packages, removing them
from the common package.
This speeds up extracting files from the common test archive for
non-jsreftest/jittest suites.
Also, remove some files from the web-platform test archive that are already
present in the common archive.
Differential Revision: https://phabricator.services.mozilla.com/D72192
As we migrate from makefiles to moz.build, we want to warn developers if
variables only used by moz.build are accidentally defined in a makefile.
This was the purpose of `MOZBUILD_VARIABLES` in recursivemake.py, though it became out-of-date.
This patch defines `MOZBUILD_VARIABLES` off the official list from `mozbuild.frontend.context.VARIABLES`, and
removes unused (?) code from makefiles accordingly
Note that the following variables use to be in `MOZBUILD_VARIABLES`, but aren't there any more because
they aren't in `mozbuild.frontend.context.VARIABLES`:
* CMSRCS
* CMMSRCS
* EXTRA_JS_MODULES
* EXTRA_PP_COMPONENTS
* EXTRA_PP_JS_MODULES
* HOST_CSRCS
* HOST_CMMSRCS
* HOST_EXTRA_LIBS
* JAVA_JAR_TARGETS
* LIBS
* MAKE_FRAMEWORK
* MODULE
* NO_DIST_INSTALL
* NO_INTERFACES_MANIFEST
* PARALLEL_DIRS
* PREF_JS_EXPORTS
* RESOURCE_FILES
* SHARED_LIBRARY_LIBS
* TEST_DIRS
* TOOL_DIRS
* XPCSHELL_TESTS
Differential Revision: https://phabricator.services.mozilla.com/D72076
As we migrate from makefiles to moz.build, we want to warn developers if
variables only used by moz.build are accidentally defined in a makefile.
This was the purpose of `MOZBUILD_VARIABLES` in recursivemake.py, though it became out-of-date.
This patch defines `MOZBUILD_VARIABLES` off the official list from `mozbuild.frontend.context.VARIABLES`, and
removes unused (?) code from makefiles accordingly
Note that the following variables use to be in `MOZBUILD_VARIABLES`, but aren't there any more because
they aren't in `mozbuild.frontend.context.VARIABLES`:
* CMSRCS
* CMMSRCS
* EXTRA_JS_MODULES
* EXTRA_PP_COMPONENTS
* EXTRA_PP_JS_MODULES
* HOST_CSRCS
* HOST_CMMSRCS
* HOST_EXTRA_LIBS
* JAVA_JAR_TARGETS
* LIBS
* MAKE_FRAMEWORK
* MODULE
* NO_DIST_INSTALL
* NO_INTERFACES_MANIFEST
* PARALLEL_DIRS
* PREF_JS_EXPORTS
* RESOURCE_FILES
* SHARED_LIBRARY_LIBS
* TEST_DIRS
* TOOL_DIRS
* XPCSHELL_TESTS
Differential Revision: https://phabricator.services.mozilla.com/D72076
When running e.g. check_symbols with extra flags like when checking
for vpx_codec_dec_init_ver when building against system libvpx, in some
configurations, the test can fail when the library flags (-l) appear
before the source file path.
The reason is that in some configurations, the compiler passes
--as-needed to the linker before both the flags and the object file
path, and the object file path is in the same position as the source
file path was. With --as-needed, -l flags are dropped if the library
wasn't needed for any of the linked code that appears *before* the flag.
So linking with `--as-needed -lfoo foo.o`, is equivalent to linking with
`foo.o` only in practice, while `--as-needed foo.o -lfoo` is equivalent
to `foo.o -lfoo`.
Differential Revision: https://phabricator.services.mozilla.com/D71456
Tarek Ziadé
Ricky Stewart
Nazım Can Altınova
Razvan Maries
Gregory Mierzwinski
Andi-Bogdan Postelnicu
Bogdan Tara
sjustus
Mitchell Hentges
Francesco Lodolo (:flod)
Artem
Kagami Sascha Rosylight
Jeff Muizelaar
Mike Hommey
Noemi Erli
Chris AtLee
Joel Maher
Coroiu Cristina
Tom Prince
Cosmin Sabou