The `clobber` targets are superseded by `mach clobber`, so we don't need them for any reason. The `clean` target is meant to get you to a post-`configure` state, but it doesn't really work, and if it's necessary for you to be in that state for some reason you can just clobber and re-`configure`, so it doesn't seem worth it to get it working again. Instead, delete all of them. Also delete `everything` which is not useful when `clobber` doesn't exist.
Differential Revision: https://phabricator.services.mozilla.com/D93514
I try to increase the probability of this error message getting read and heeded by enumerating the list of changed files from the latest `central`, and printing them out.
Also, bug 1636797 I think renders unnecessary the advice to run `mach clobber python`, so I delete that suggestion.
Differential Revision: https://phabricator.services.mozilla.com/D93422
Some recent change apparently made the multiprocessing code reenter
python with the arguments `-s -c "..."` instead of `-c "..."`, which
broke the assumption of the hack.
Differential Revision: https://phabricator.services.mozilla.com/D93060
People keep using `gecko-dev` and trying to run artifact builds, although this very unsupported, and the existing error message is useless if you're not knowledgeable about how these systems work. Since this is the most common case where people come in with questions about artifact builds not working, try to detect this case and print a helpful error message.
Differential Revision: https://phabricator.services.mozilla.com/D92492
Bug 1666244 added this. `sccache-dist` is not the recommended build configuration for arbitrary build scenarios, is not actively supported, and is only relevant for a subset of those building Firefox. Instead, point to more relevant general documentation.
Differential Revision: https://phabricator.services.mozilla.com/D92973
`imp` is deprecated since Python 3.4 and later Python versions are very noisy about printing `DeprecationWarning`s; instead, use its replacement, `importlib`.
Differential Revision: https://phabricator.services.mozilla.com/D92632
The existing implementation of `@imports()` in the `configure` sandbox doesn't translate an import of the form `@imports('distutils.sysconfig')` into an `import distutils.sysconfig` statement; instead, it transforms the input `@imports()` request a few times in such a way that we eventually just do `import distutils`, and expect that `distutils.sysconfig` will be populated that way. This would be fine, except that this isn't the way that Python's `import` system works:
```
>>> import distutils
>>> distutils.sysconfig
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: module 'distutils' has no attribute 'sysconfig'
>>> import distutils.sysconfig
>>> distutils.sysconfig
<module 'distutils.sysconfig' from '/usr/lib/python3.8/distutils/sysconfig.py'>
```
i.e., we can't just import a parent module and expect that we can indirectly access all child packages of that module without importing them specifically.
So instead, we simplify the current model somewhat by not transforming the `@imports()` request at all and instead just performing the exact `import` that the user requested. This resolves the `distutils.sysconfig` issue as well as hopefully preventing any other similar issues popping up in the future.
While I'm here, I also refactored some stuff so that the way that we're patching in wrapped modules for the sandbox is more structured.
Differential Revision: https://phabricator.services.mozilla.com/D90627
Before, this would be written to `sitecustomize.py` irrespective of the value of `populate_local_paths`. This doesn't make sense -- since the local paths aren't included in the `virtualenv`'s `PYTHONPATH` when Python starts up, it doesn't know how to `import mach_bootstrap`. Since on `mach` startup the import hook will be loaded anyway, and the `virtualenv`s in `~/.mozbuild` (i.e. the only `virtualenv`s for which we don't `populate_local_paths`) are just used to run `mach`, this is fine and won't regress anything.
Also, since the `import` hook is only necessary for Python 2, add a couple conditional checks to get rid of the added overhead when we're running with Python 3.
This was never noticed because importing `sitecustomize` is allowed to throw an `ImportError`, which failure is ignored silently. This may be fixed in the latest version of `virtualenv`.
Differential Revision: https://phabricator.services.mozilla.com/D92290
Also this patch adds tests for `ClangdBackend` and `StaticAnalysisBackend` since
both of them are derived from `CompileDB`.
Differential Revision: https://phabricator.services.mozilla.com/D91768
1. Provide a new backend dedicated for C++ static-code_analysis
2. Build a list with directories, from non-unified-compat that have been fixed and
permit compiling of C++ files outside of the unified environment. With this list
we eliminate the unified sources and instead use the original source for command
attribute from compile_commands.json.
In this way if a regression appears clang-tidy will report it since it no longer uses
the unified environment for files that are compatible to be compiled standalone.
3. Remove the coverity functionality that was reading and using non-unified build files
since in practive it proved to be sub-optimal.
Differential Revision: https://phabricator.services.mozilla.com/D91011
In order to support building with relative paths to third-party code we need
to normalize the non-unified source paths prior to comparing them to incoming
source paths during moz.build file generation.
Depends on D91319
Differential Revision: https://phabricator.services.mozilla.com/D91320
I randomly noticed in a log file that we don't apply the flags to wasm compilations. I don't have a super strong motivation for this, but eh, we might as well.
Differential Revision: https://phabricator.services.mozilla.com/D90741
The manifest file hasn't actually done anything since XPT definitions were
moved to the libxul binary, and now just generates warnings in local builes.
Differential Revision: https://phabricator.services.mozilla.com/D89197
The manifest file hasn't actually done anything since XPT definitions were
moved to the libxul binary, and now just generates warnings in local builes.
Differential Revision: https://phabricator.services.mozilla.com/D89197
I think they're remnants from the past that we don't really need anymore.
And they're making things more complicated for some pending work of mine.
Differential Revision: https://phabricator.services.mozilla.com/D89687
Allows mach commands to define their own glean metrics with the `metrics_path` @CommandProvider parameter.
When `metrics_path` is defined:
* A `metrics` kwarg is provided to the decorated class. This `metrics` handle is a Glean instance, so Glean documentation should be consulted for usage information.
* When `mach doc telemetry` is run, metrics docs will be generated from all the registered metrics files.
Note: there was some consideration between making `metrics_path` a @CommandProvider or @Command parameter.
In the end, @CommandProvider seemed like a better fit because:
* Metrics seem to be more associated with the entire class than a specific command/method. This is because a class represents a "domain", and that domain may have different commands that have overlapping metrics. Accordingly, all the metrics should be defined once as available to the entire class.
* Currently, @Command methods only take parameters that map one-to-one with CLI arguments. It could seem inconsistent to have one exception: the metrics handle
Differential Revision: https://phabricator.services.mozilla.com/D85953
This was originally meant to allow `virtualenv`s to use packages from a parent Python environment without having to re-install them. This turned out to not pan out as we would have liked, so we're going another way to solve the same problem. Bug 1660351 walked back a bunch of this logic; this patch deletes the rest of it.
Differential Revision: https://phabricator.services.mozilla.com/D89492
I think they're remnants from the past that we don't really need anymore.
And they're making things more complicated for some pending work of mine.
Differential Revision: https://phabricator.services.mozilla.com/D89687
VSCode doesn't install by default it's command line integration toolset on MacOS
so w don't have a link to `/usr/local/bin/code` instead we must use the binary from the
`Applications` folder.
Also extens this to other platforms even though it's improbable that we are going to use it
there.
Differential Revision: https://phabricator.services.mozilla.com/D90088
In addition to the existing build telemetry, also gather the stats and
report with Glean. This new telemetry is reported in tandem with the existing
telemetry to allow testing and confidence before a full roll-out.
Additionally, Glean isn't compatible with Python 2, so the new telemetry only runs
on Python 3 mach commands.
Differential Revision: https://phabricator.services.mozilla.com/D83572
This was originally meant to allow `virtualenv`s to use packages from a parent Python environment without having to re-install them. This turned out to not pan out as we would have liked, so we're going another way to solve the same problem. Bug 1660351 walked back a bunch of this logic; this patch deletes the rest of it.
Differential Revision: https://phabricator.services.mozilla.com/D89492
