When I had to test a change in another macOS version, I naively copied the `Nightly.app` to another computer, just to find out it silently fails (because of symlinked libraries) and it took a while (and external help) to figure that out.
This change instructs developers to package and use the `.dmg` instead when they want to do that, sparing the frustration and incentivizing testing in different systems.
Differential Revision: https://phabricator.services.mozilla.com/D195319
This patch updates the quick reference doc as well as the detailed
build docs for each operating system. These updates should help new
contributors understand what is happening when initially setting up
their Firefox development environment.
There is also a new "Build errors" section in each detailed build doc
to enable new contributors to get the help they need in debugging build
issues. The quick reference doc points out these new sections in the
"To build & run" heading.
Additionally this patch adds some more context to the OS specific build
doc links in the quick start reference doc.
Differential Revision: https://phabricator.services.mozilla.com/D192007
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