The reason the error mentioned in build-mingw32-nsis.sh happens is that
the default mode NSIS builds in is a fully-installed mode, where it
hardcodes the locations of its data files. This is why nsis needs to
be used from the same place it's built for. But there's another mode,
enabled with NSIS_CONFIG_CONST_DATA_PATH=no, that makes it relocatable,
and makes it find its data files relatively to the nsis binary.
However, there's a bug in the nsis build scripts, which makes the nsis
binary installed in the destination directory instead of a bin/
subdirectory, while the source code itself looks for data files relative
to the parent directory of the directory that contains the executable.
So we need to set PREFIX_BIN to force the executable to be installed in
a bin/ subdirectory.
There is also an issue in nsis itself when it's executed by anything
other than a shell, which we patch out.
Differential Revision: https://phabricator.services.mozilla.com/D125638
Using the sysroot with GCC requires some unnecessary complication, and
we don't really care if the first stages are not using the sysroot.
Differential Revision: https://phabricator.services.mozilla.com/D125161
Building sanitizers in older versions of clang emit errors when built with
newer GCC because of some narrowing conversions. We only really need the
sanitizers in the final stage anyways, so we force-disable them (and
everything else that might enable "sanitizer-common") in early stages.
Building the lli tool (also used in tests) fails as well, and we don't
need it until the final stage (where we need it to ship it).
Differential Revision: https://phabricator.services.mozilla.com/D125159
There are complications with building a 1-stage clang with gcc, so just
use clang. Eventually, the clang-tidy toolchains will be removed in
favor of providing clang-tidy from the clang toolchain itself anyways.
Differential Revision: https://phabricator.services.mozilla.com/D125158
Tweak the `VirtualenvManager` API to accept a single base "python"
executable during initialization, then to consistently use it for
up-to-date checking, construction, etc.
This constraint allows future simplification for behaviour involving
the "base" python.
Differential Revision: https://phabricator.services.mozilla.com/D124516
Maps virtualenvs one-to-one with their associated requirements
definition.
For example:
```
Name: "docs"
Virtualenv location: <snip>/_virtualenvs/docs
Requirements location: $topsrcdir/build/docs_virtualenv_packages.txt
```
An issue to be resolved in the future is that it's tricky to know that,
when you define a new virtualenv, you have to *know* that a requirements
definition needs to exist in `build/`.
As part of this change, the default virtualenv ("common") was
split from the build virtualenv ("build").
This required changes to the python-test virtualenv since
python-tests depend on `glean_parser`, but were getting it
implicitly from the "build" virtualenv's requirements.
This addition to the `python-test` virtualenv is temporary and
will be removed when bug 1724273 is resolved.
Differential Revision: https://phabricator.services.mozilla.com/D122891
Thunderbird can't currently define its own Mach commands, which means
that it doesn't define its own virtualenvs.
However, it does add some tweaks to the `common` virtualenv requirements
(for build scripts, I believe).
So, we should allow it to continue making those tweaks, but we should
remove the capability of specifying PyPI packages. This is needed for
lockfile-generation, since lockfiles are created and placed in the
Mozilla repo, and we don't want "conditional lockfiles" based on the
existence of a "comm" repo.
This will not regress existing Thunderbird expectations.
Differential Revision: https://phabricator.services.mozilla.com/D124515
Note that, as part of adding this packages to the automated vendoring
system, some dependencies were automatically added - most notably,
dependencies of `taskcluster` that become visible with Python 3.6+.
Also, adds `**/.git` to the exclusions because:
* `.git` is part of our `.hgignore`, but
* `.git` is part of the `aiohttp` `tar.gz` file.
Since the file isn't needed for `pip install`-ing `aiohttp`,
and since we want `./mach vendor python` to be a no-op when there's
no requirement changes, we exclude it.
Differential Revision: https://phabricator.services.mozilla.com/D123122
The existing version of `pyasn1-modules` (`0.1.5`) is incompatible with
our version of `pyasn1` (`0.4.8`).
By bumping `pyasn1-modules` to `0.2.8`, we now meet its compatibility
requirements.
Differential Revision: https://phabricator.services.mozilla.com/D122897
It made sense when we did have problems with the one shipped with clang
and needed an explicitly newer version, but that hasn't been true in a
while. On the contrary, we're now using a version older than clang for
no reason other than having forgotten to update it.
Differential Revision: https://phabricator.services.mozilla.com/D124886
The change happened 2 years ago in bug 1571562, which means the script
hasn't hit a llvm-dsymutil crash since then (we would have noticed that
it doesn't produce reproducers if we had recurring llvm-dsymutil crashes).
So before removing the script, fix it, so that if we do need to dig it
up from history, we don't pull a broken version.
Differential Revision: https://phabricator.services.mozilla.com/D124884
We leave the following ones unchanged:
- geckodriver because the results are used to releases on github.
- sixgill because the script that creates it is not in-tree.
- *-dist-toolchain because sccache is not expecting a .tar.zst.
We use native tar support in most cases, except for toolchain scripts also
used on Windows, for which we use our zstdpy script.
Differential Revision: https://phabricator.services.mozilla.com/D124733
We leave the following ones unchanged:
- geckodriver because the results are used to releases on github.
- sixgill because the script that creates it is not in-tree.
- *-dist-toolchain because sccache is not expecting a .tar.zst.
We use native tar support in most cases, except for toolchain scripts also
used on Windows, for which we use our zstdpy script.
Differential Revision: https://phabricator.services.mozilla.com/D124733
We leave the following ones unchanged:
- geckodriver because the results are used to releases on github.
- sixgill because the script that creates it is not in-tree.
- *-dist-toolchain because sccache is not expecting a .tar.zst.
We use native tar support in most cases, except for toolchain scripts also
used on Windows, for which we use our zstdpy script.
Differential Revision: https://phabricator.services.mozilla.com/D124733
We leave the following ones unchanged:
- geckodriver because the results are used to releases on github.
- sixgill because the script that creates it is not in-tree.
- *-dist-toolchain because sccache is not expecting a .tar.zst.
We use native tar support in most cases, except for toolchain scripts also
used on Windows, for which we use our zstdpy script.
Differential Revision: https://phabricator.services.mozilla.com/D124733
Valgrind detects a condition depending on uninitialized value in update_texture_cache. I first ran into this in bug 1716579, and as patch had a large impact on allocation/deallocation workloads with the texture cache, I couldn't decide with confidence that the patch wasn't faulty. In bug 1728618 which causes this error again, however, the patch is much simpler, doesn't interact with unsafe code and does not affect texture cache workloads so it gives me much better confidence that this valgrind error is either a false positive or a miscompilation.
Differential Revision: https://phabricator.services.mozilla.com/D124444
We had logic in both `mach_bootstrap` and the Mach Bootstrapper to
create the state_dir.
This joins them and has the added benefit of creating the state dir
earlier in the Mach lifecycle (as will be needed for early instantiation
of the Mach virtualenv).
Differential Revision: https://phabricator.services.mozilla.com/D120400
We've overloaded "bootstrap" to mean three different things:
* The "standalone bootstrap script": `python/mozboot/bin/bootstrap.py`.
This is to freshly clone a new repo, then run `./mach bootstrap`.
* `./mach bootstrap`: Install necessary dependencies and set up the
system for development.
* "Mach bootstrap": do the in-process initialization work Mach needs
before it can run commands.
By using the term "initialize" instead, perhaps we can remove
ambiguity when discussing Mach.
I'm not attached to the name (or this change at all), but I'm interested
in reviewer thoughts :)
Differential Revision: https://phabricator.services.mozilla.com/D120410
In practice we already only use SourceSurfaceSharedData as our
rasterized image backing. This means we no longer need to lock the data
to keep it in memory (when we used volatile memory), nor to try to
optimize the surface for the DrawTarget.
Differential Revision: https://phabricator.services.mozilla.com/D124476
Note that, as part of adding this packages to the automated vendoring
system, some dependencies were automatically added - most notably,
dependencies of `taskcluster` that become visible with Python 3.6+.
Also, adds `**/.git` to the exclusions because:
* `.git` is part of our `.hgignore`, but
* `.git` is part of the `aiohttp` `tar.gz` file.
Since the file isn't needed for `pip install`-ing `aiohttp`,
and since we want `./mach vendor python` to be a no-op when there's
no requirement changes, we exclude it.
Differential Revision: https://phabricator.services.mozilla.com/D123122
The existing version of `pyasn1-modules` (`0.1.5`) is incompatible with
our version of `pyasn1` (`0.4.8`).
By bumping `pyasn1-modules` to `0.2.8`, we now meet its compatibility
requirements.
Differential Revision: https://phabricator.services.mozilla.com/D122897
We've been installing `piptools` so that we can use the `pip-compile`
binary. However, we can just as easily do
`python -m piptools compile ...` instead, which also allows us to
skip a redundant install.
Differential Revision: https://phabricator.services.mozilla.com/D123240
This update makes wgpu a vendored dependency instead of having it in gfx/wgpu.
## Notes
It relies on https://phabricator.services.mozilla.com/D123157
It has a quirk related to OpenGL ES backend. Previousy, we manually had to disable GL backend
in order to avoid vendoring WASM dependencies in. This time, manual editing is more complicated,
so instead this change adds a few cargo patch lines to point WASM dependencies to dummy projects.
The update also totally removes SPIRV-Cross, since the latest `wgpu` doesn't depend on it any more.
The compiled binary size for Gecko should improve with this.
Differential Revision: https://phabricator.services.mozilla.com/D123153
We vendor `glean_parser==3.6.0`, and that was incompatible with
`glean-sdk==36.0.0`'s requirement of `glean_parser==2.5.0`.
`glean-sdk==40.0.0` expects `glean_parser==3.6.0`, which is perfect.
Differential Revision: https://phabricator.services.mozilla.com/D122899
