Bug 1786419 added a note about using a specific version of Mercurial on macOS due to a
bug in upstream Mercurial and fsmonitor. Since then the bug has been fixed and users should
update their Mercurial to the latest. We should remove the note about using a specific older
Mercurial version from the docs.
Differential Revision: https://phabricator.services.mozilla.com/D189169
It has been enabled by default on the relevant platforms essentially
forever, so it doesn't need to be explicitly enabled.
As such, since --enable-crashreporter is not really a useful thing to
point at to wrt build options, we remove its mention from the
configuring build options doc.
Differential Revision: https://phabricator.services.mozilla.com/D186513
D150200 broke this when changing the title and missed it, probably because breaking links only emits warnings instead of errors.
Differential Revision: https://phabricator.services.mozilla.com/D184245
As of bug 1838763, Python virtualenvs are now located in a subdirectory
of `$MOZBUILD_STATE_PATH`. This, in turn, defaults to a subdirectory of
the home directory, which on Windows often contains spaces.
The Windows build instructions were updated to add a requirement that
`MOZBUILD_STATE_PATH` not contain spaces, under the assumption that this
was merely a clarification of an existing restriction; but this is
indeed a new requirement and breaks existing setups.
Instead, allow makefiles to safely invoke `$(PYTHON3)` without quoting
it everywhere (as they do) by ensuring that its value contains no
spaces, by using the DOS-style (8.3) short path to the Python
executable.
Additionally, clarify in the documentation exactly which paths are
required not to contain spaces.
Differential Revision: https://phabricator.services.mozilla.com/D183305
This is necessary for activating the site/command virtualenvs earlier,
since we can't determine what the objdir will be very early on in the
mach process intialization. We do know where the state dir is, and how
to get to the state dir for a specific topsrcdir, so we can use that
instead. This is already where the `mach` virtualenv lives anyway.
Differential Revision: https://phabricator.services.mozilla.com/D181029
Both removed sections are about issues with link.exe, which we haven't
been using ever since we switched to building with clang-cl/lld-link.
Differential Revision: https://phabricator.services.mozilla.com/D175956
- On Debian/Ubuntu, the base distribution of Python does not come with `ensurepip` (which is still called during `venv` creation). The benefit of not calling `ensurepip` explicitly in a separate command (like we now do for Windows) is that the error message you get when creating the `venv` is very clear and instructs the user to run `apt install python3.x-venv` to fix the problem. (`python3.x-venv` is what contains `ensurepip`). If we did not do this, it would just tell the user that there is `no ensurepip module` and it would hard to figure out that the solution is to run `apt install python3.x-venv`. This isn't an issue for us in CI, but it can be for end users, since that package may not be installed, and some commands (like talos tests) go through mozharness and invoke this code.
- Also removed some Python dependencies in the Linux build docs that are no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D174525
--enable-application is the historic flag, and --enable-project was
added to handle the non-application things we build, while encompassing
the meaning of --enable-application. --enable-project has been preferred
for a while and we should reflect that more consistently in mozconfigs,
documentation, etc.
Differential Revision: https://phabricator.services.mozilla.com/D162625
The problem only happens with homebrew (python.org's build doesn't have
the problem). Many people are hitting it, and we might as well avoid
them the trouble to have to find the documentation and just fail
directly.
Differential Revision: https://phabricator.services.mozilla.com/D158546
I also added `%USERPROFILE%/.mozbuild` to the exclusion list and updated the windows_build docs to reflect the changes made.
Differential Revision: https://phabricator.services.mozilla.com/D149199
Assuming that the `MOZILLABUILD` environment variable is set, allow
invoking Mach from non-MozillaBuild terminals.
Note that MozillaBuild still needs to be installed, and the
`MOZILLABUILD` environment variable will have to be set.
For future reference: when I tried setting this up with Windows
Store's Python 3.9, I encountered issues when running binaries installed
via `pip`: it would fail with `abort: failed to load Python DLL
python3x.dll`.
Differential Revision: https://phabricator.services.mozilla.com/D133936
* Recommend the Build Tools over the full Community IDE install
* Bump Windows 10 SDK, C++ ATL version
* Remove "Game development with C++" workload, because it doesn't seem
to be required anymore - I'm leaning on review and natural
developer-testing to confirm this assumption.
Differential Revision: https://phabricator.services.mozilla.com/D130773
bootstrap.py may ask the restart of shell to reflect the change to login script.
Given the step 2 lets user to move to c:/mozilla-source instead of home,
the document should explicitly specify the absolute path in step 3.
Differential Revision: https://phabricator.services.mozilla.com/D128024
Both work, but the former is preferred. Also remove MOZ_MAKE_FLAGS
in the mozconfig example for msan, because it's irrelevant.
Differential Revision: https://phabricator.services.mozilla.com/D124726
