The mozjs_sys crate is actually responsible for all the problems
encountered with the js crate we just removed, but the sm-mozjs-crate
task that builds and runs tests for it doesn't fail because... there is
actually no test to build and run, so all it builds is a static library,
which doesn't expose all the problems that exist.
The content of this crate in mozilla-central is also outdated compared
to servo upstream.
Differential Revision: https://phabricator.services.mozilla.com/D106390
The sm-rust-bindings task that builds and runs tests for it actually only
doesn't fail by three(!) distinct happenstances of chance:
- It somehow doesn't hit a race condition that can happen, but that
attempting to change the build process for jsglue.cpp did,
- The second call to `cargo test` without `--feature debugmozjs` only
works because nothing was cleaned up from the first and the second
build uses artifacts from the first that are otherwise not there if
only running the second.
- The addition of rust code to spidermonkey (the jsrust crate in
js/src/rust) somehow didsn't cause problems in the current
configuration, but in other configurations (which fixing the second
thing above unveils) the build fails because of the multiple
definition of rust_eh_personality between the jsrust staticlib and the
rust stdlib that rustc links to test programs.
On top of all the above, the content of the crate in mozilla-central
has not received updates from upstream servo in years, and doesn't
reflect what servo actually uses.
Differential Revision: https://phabricator.services.mozilla.com/D106389
Install `psutil` when setting up the `mach` `virtualenv`s and stop importing the in-tree version in the build.
Nothing in-tree currently assumes or mandates the installation of `psutil` (all uses of `psutil` are guarded with imports of the form `try : import psutil; except ImportError: psutil = None`), so there's no back-incompatibility concerns here. There will be an awkward period where telemetry will be lacking CPU/disk data for everyone until they re-run `mach bootstrap` or `mach create-mach-environment`, but that will come back as people gradually update their `virtualenv`s.
An alternative to circumvent that issue is REQUIRING that `psutil` be installed by adding an assertion in `mach` that `psutil` can be found (allowing us to remove all the conditional logic in-tree around whether `psutil` is installed), but I wouldn't claim that we're ready to do that and deal with whatever fallout might occur.
Differential Revision: https://phabricator.services.mozilla.com/D90914
Install `psutil` when setting up the `mach` `virtualenv`s and stop importing the in-tree version in the build.
Nothing in-tree currently assumes or mandates the installation of `psutil` (all uses of `psutil` are guarded with imports of the form `try : import psutil; except ImportError: psutil = None`), so there's no back-incompatibility concerns here. There will be an awkward period where telemetry will be lacking CPU/disk data for everyone until they re-run `mach bootstrap` or `mach create-mach-environment`, but that will come back as people gradually update their `virtualenv`s.
An alternative to circumvent that issue is REQUIRING that `psutil` be installed by adding an assertion in `mach` that `psutil` can be found (allowing us to remove all the conditional logic in-tree around whether `psutil` is installed), but I wouldn't claim that we're ready to do that and deal with whatever fallout might occur.
Differential Revision: https://phabricator.services.mozilla.com/D90914
CLOSED TREE
Backed out changeset baa1f7a615e4 (bug 1666345)
Backed out changeset b6646baa866d (bug 1661624)
Backed out changeset e4d550db6037 (bug 1667152)
Install `psutil` when setting up the `mach` `virtualenv`s and stop importing the in-tree version in the build.
Nothing in-tree currently assumes or mandates the installation of `psutil` (all uses of `psutil` are guarded with imports of the form `try : import psutil; except ImportError: psutil = None`), so there's no back-incompatibility concerns here. There will be an awkward period where telemetry will be lacking CPU/disk data for everyone until they re-run `mach bootstrap` or `mach create-mach-environment`, but that will come back as people gradually update their `virtualenv`s.
An alternative to circumvent that issue is REQUIRING that `psutil` be installed by adding an assertion in `mach` that `psutil` can be found (allowing us to remove all the conditional logic in-tree around whether `psutil` is installed), but I wouldn't claim that we're ready to do that and deal with whatever fallout might occur.
Differential Revision: https://phabricator.services.mozilla.com/D90914
Install `psutil` when setting up the `mach` `virtualenv`s and stop importing the in-tree version in the build.
Nothing in-tree currently assumes or mandates the installation of `psutil` (all uses of `psutil` are guarded with imports of the form `try : import psutil; except ImportError: psutil = None`), so there's no back-incompatibility concerns here. There will be an awkward period where telemetry will be lacking CPU/disk data for everyone until they re-run `mach bootstrap` or `mach create-mach-environment`, but that will come back as people gradually update their `virtualenv`s.
An alternative to circumvent that issue is REQUIRING that `psutil` be installed by adding an assertion in `mach` that `psutil` can be found (allowing us to remove all the conditional logic in-tree around whether `psutil` is installed), but I wouldn't claim that we're ready to do that and deal with whatever fallout might occur.
Differential Revision: https://phabricator.services.mozilla.com/D90914
Without setting this variable, the call to `mach python` in `taskcluster/scripts/builder/build-linux.sh` will create a `virtualenv` in the default location -- on Linux in CI, that's `obj-x86_64-pc-linux-gnu`. Everything else about the build is going to end up in `obj-build`, so just set `MOZ_OBJDIR` appropriately to point to that directory.
Doing so enables us to land bug 1663755, as it causes the logic added to `symbols_archive.py` as part of bug 1654994 to behave as expected.
Differential Revision: https://phabricator.services.mozilla.com/D89975
The script uses the `cd $FOO && pwd` trick to fix the path style on Windows, but currently this happens before the `mkdir`, so we get an incorrect result:
```
[task 2020-09-11T03:38:59.656Z] ++ cd Z:/task_1599794667/public/build
[task 2020-09-11T03:38:59.656Z] ./src/taskcluster/scripts/builder/build-sm.sh: line 10: cd: Z:/task_1599794667/public/build: No such file or directory
[task 2020-09-11T03:38:59.656Z] ++ pwd
[task 2020-09-11T03:38:59.657Z] + export MOZ_UPLOAD_DIR=/z/task_1599794667
```
Differential Revision: https://phabricator.services.mozilla.com/D89925
This adds a new job variant `arm64-cranelift-sim` to the SpiderMonkey
build configurations, and adds a Taskherder CI configuration to run it.
The job uses the aarch64 simulator support built-in to SpiderMonkey, so
it does not need to run on native aarch64 hardware.
A few tests needed to be added to the "slow tests" list as they time out
under the simulator otherwise.
This also fixes an issue with an error message in `build-sm.sh` in which
the overloading of the backtick's meaning (code-quotes in
Markdown-world, and command interpolation in shell scripts) led to an
amusing attempt to execute parts of the error message.
Finally, this fixes an error that seems unrelated to Cranelift or
WebAssembly in a GC jit-test, wherein its way of measuring maximum stack
recursion depth was failing.
Differential Revision: https://phabricator.services.mozilla.com/D86131
This moves the object directory and source directories around in all mozharness
jobs, to allow enabling caching on windows builders.
This makes a number of changes that all need to land at once:
- Move the source checkout for the workspace cache mount, to the checkouts
cache mount.
- Makes the object directoy from underneath the source directory, to directly
in the work directory (which is still under `workspace`).
- Sets the object directory to `obj-build` instead of `obj-firefox`.
- Stops caching the workspace directory (it is still a volume in docker workers,
so writes perform well; a followup revision add some checks around this).
- Removes one level of directory in the mozharness workdir (things were under
`workspace/build`, but are now just under `workspace/`.
- Adjust paths in environment variables and artifact specifications to match
the above changes.
Differential Revision: https://phabricator.services.mozilla.com/D62482
--HG--
extra : moz-landing-system : lando
The browser build generates this file during the packaging step, which does not exist for JS shell builds. I made a brief attempt to call informulate.py as it does, but that seemed to require some things that are not available during the shell build. So I went with the cheap and easy approach to provide just the fields :jkratzer uses.
Differential Revision: https://phabricator.services.mozilla.com/D57028
--HG--
extra : moz-landing-system : lando
We build bindgen without the `which` feeature, which means it won't try to
look for `rustfmt` in $PATH. So point at it explicitly so that the bindings are
properly formatted.
We do the same for regular Gecko builds in `build/mozconfig.rust`.
Differential Revision: https://phabricator.services.mozilla.com/D56957
--HG--
extra : moz-landing-system : lando
