This migrates the bazel integration to the new Bazel dependency system
"bzlmod". bzlmod is becoming mandatory this year (see second sentence
here: https://bazel.build/external/migration).
This is a backwards incompatible migration, directly removing the old
WORKSPACE based approach. Users will have to change how they depend on
bzlmod, however I assume pretty much every user will be happy about it,
because they are forced to use bzlmod anyway or add extra flags to
continue to build with newer Bazel versions. Given that users normally
depend on specific git commits in the old system, they won't be hit with
this until they decide to upgrade emsdk.
The basic principle here is simple: I took everything that WORKSPACE did
and searched an alternative in bzlmod. Some interesting bits:
- We have less worries about multiple versions and people depending on
emscripten multiple times in different ways. This is resolved by the new
system: Bazel first iterates through the MODULE.bazel files recursively,
then finds the minimum version needed for each module and then executes
the module extensions that define repos exactly once at that version. So
no more ifs needed to detect multiple inclusions.
- A bunch of nodejs stuff moves to MODULE.bazel, because that is how the
nodejs module works now. As their module extension gets executed only
once you need to declare everything that you could need before that in
the MODULE.bazel file. A side effect of that is that we have to make a
fake repository when emscripten doesn't have an arm64 binary for linux,
because we can't actually figure that out in MODULE.bazel, so we have to
declare that it always exists and then create one in all cases.
There is a bunch of autoformatter changes in here as well, I could try
to revert them if you prefer.
Closes#1509
The current way to derive the binary path relies on a specific name for
the nodejs repository. This blocks migrating to bzlmod, as bzlmod
prefixes repository directories with the module name that created them.
By asking bazel for the path instead we always get the correct path, so
we can work with both bzlmod and WORKSPACE based dependencies at the
same time.
The repository @nodejs, used in the build label, refers to nodejs for
the host platform and is generated by the following macro (wasn't too
obvious to me):
d19d695275/nodejs/repositories.bzl (L452)
This is some work towards solving #1509.
This is a working solution for generating a separate Emscripten cache.
Note that this requires an additional entry in the workspace as follows:
```starlark
load("@emsdk//:emscripten_cache.bzl", emsdk_emscripten_cache = "emscripten_cache")
emsdk_emscripten_cache()
```
When used like this, the default Emscripten cache will be used. However,
if the entry is as follows:
```starlark
load("@emsdk//:emscripten_cache.bzl", emsdk_emscripten_cache = "emscripten_cache")
emsdk_emscripten_cache(flags = ["--lto"])
```
Then embuilder will be called to build all system libraries and ports
(i.e., the `ALL` option to embuilder) with the LTO option enabled. This
can take awhile, so I have also made possible to specify which libraries
you want to build explicitly:
```starlark
load("@emsdk//:emscripten_cache.bzl", emsdk_emscripten_cache = "emscripten_cache")
emsdk_emscripten_cache(
flags = ["--lto"],
libraries = [
"crtbegin",
"libprintf_long_double-debug",
"libstubs-debug",
"libnoexit",
"libc-debug",
"libdlmalloc",
"libcompiler_rt",
"libc++-noexcept",
"libc++abi-debug-noexcept",
"libsockets"
]
)
```
Resolves#807, resolves#971, resolves#1099, resolves#1362, resolves
#1401
* Allows generation of audio worklet bootstrap js file
In order to allow users to generate the file, the allowed extension list in `link_wrapper.py` has been updated accordingly.
* adds audio worklet js to wasm_cc_binary too
---------
Co-authored-by: William Izzo <william.izzo@hey.com>
* Add linux/arm64 support to bazel rules
* Make linux arm64 sha optional and PR feedback
Not all releases have linux shas. Use getattr to default to no sha if none was
present. This way non linux arm64 builds should not fail.
* Update linux arm64 sha for 3.1.33
This is the latest arm64 release according to #1204. There do not seem to be a any releases between .21 and .33.
* Explicit outputs for wasm_cc_binary
* Backwards compatibility
* data_runfiles restore
* restore test_bazel.sh
* Using wrong path on accident
* two separate rules for legacy support
* Added name attribute to wasm_cc_binary rule
* Optimize sandbox performance
Link just the files needed to compile, link, or archive, rather than the entire directory tree. This drastically improves build times on macOS, where the sandbox is known to be slow (https://github.com/bazelbuild/bazel/issues/8230).
* Linux wants clang to link
* all_files not needed?
* Linux wants llc
* And llvm-ar
* Templated build_file_content
This is needed to allow custom rules and/or transitions on top of wasm_cc_binary (e.g. to workaround #972).
It's debatable whether .wasm is the correct executable target for non-standalone Wasm builds, but we don't have a way to differentiate those in wasm_cc_binary, and considering that this attribute isn't exported now, it shouldn't break anything.
* Support Bazel builds on Apple silicon
* Add sha_mac_arm64 hash for 3.1.3
* Configure node_repositories in emscripten_deps.bzl
* Add mac arm64 to bazel workspace update script
Co-authored-by: Matthew Soulanille <matthew@guppy.home>
It breaks @emsdk in workspaces that have this feature enabled.
The following error appears when using the latest commit:
cc_toolchain '@emsdk//emscripten_toolchain:everything' with
identifier 'emscripten-wasm' doesn't define a tool path for 'dwp'
The following error appears after adding `emdwp` tool and scripts:
output '*.dwo' was not created
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
* Always output a tarball from cc_binary to simplify logic. This will change the result of --config=wasm builds that were previously outputting a single file.
* better to use early return here
* Always output a tarball from cc_binary to simplify logic. This will change the result of --config=wasm builds that were previously outputting a single file.
* better to use early return here
Co-authored-by: Mitch Foley <mitchfoley@chromium.org>
When linking with `-o filename` (such as in various CMake build checks), the parameter passed to the linker is a temporary file, and it is passed as a bare filename (i.e. relative path without a `'/'`). In such cases, `outdir` would have been the empty string, and the final `tar` command would fail (actually the call to `subprocess.check_call(…)` is what fails).
* Makes provided bazel rules look up @emsdk workspace instead of local workspace
* Uses system-specific emscripten binaries instead of defaulting to linux
* Provides macros for loading emsdk dependencies (nodejs and emscripten binaries)
* Unhardcodes paths in bazel rules and .sh wrappers
* `update_bazel_workspace.sh` now updates `revisions.bzl`
* `emscripten_deps()` can be fed with specific emscripten version
* Adds external usage test
Addresses #650 and #696
* allow the bazel toolchain to output html files
* allow for cc_binary rule names to end in .js
* fix python name
* continue to call emcc instead of em++ for now
* small cleanup
Co-authored-by: Mitch Foley <mitchfoley@chromium.org>
