admin/ci-emsdk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
4.0.23
ci-emsdk/test/test_bazel.sh

37 lines
1.2 KiB
Bash
Raw Permalink Normal View History

add a wasm bazel toolchain (#603)
2020-09-10 21:42:46 -04:00
#!/usr/bin/env bash
echo "test bazel"
set -x
set -e
Use `.json` extension for emscripten-releases-tags.json. NFC (#870)
2021-08-25 17:21:40 -07:00
# Get the latest version number from emscripten-releases-tag.json.
Remove Intel mac CircleCI configuration (#1409) Also switch bazel-mac to the arm64 config. The CircleCI Intel mac config will be turned down soon.
2024-06-20 16:16:05 -07:00
VER=$(scripts/get_release_info.py emscripten-releases-tags.json latest)
update bazel workspace for emscripten 2.0.3 (#613) * update bazel workspace for emscripten 2.0.3 * test to make sure WORKSPACE is up to date * make it clear what happened when WORKSPACE is out of date * intentionally add error to make sure circleci fails properly * revert intentionally bad commit * increase visibility of failure message Co-authored-by: Mitch Foley <mitchfoley@google.com>
2020-09-11 20:15:19 -04:00
# Based on the latest version number, get the commit hash for that version.
Remove Intel mac CircleCI configuration (#1409) Also switch bazel-mac to the arm64 config. The CircleCI Intel mac config will be turned down soon.
2024-06-20 16:16:05 -07:00
HASH=$(scripts/get_release_info.py emscripten-releases-tags.json hash ${VER})
Release 2.0.13 and update bazel toolchain (#694) This change comes with fairly major change to the bazel toolchain. - Use pre-built cache that comes with emsdk - Mark cache as readonly using FROZEN_CACHE - Pass `--sysroot` to match upstream emscripten change
2021-01-29 18:25:41 -08:00
Replace update_bazel_workspace.sh with a python script (#1271) This script is (IMO) more readable, but the real reason for this change is that it raises an error message when the binary package fails to download. (The shell script silently generated a bogus hash instead, because the shell's `set -e` builtin does not affect commands executing inside a $() context. It seemed just as easy to rewrite the script in Python as to fix that. This change also updates some outdated filename references.
2023-08-24 10:10:29 -07:00
FAILMSG="!!! scripts/update_bazel_workspace.py needs to be run !!!"
update bazel workspace for emscripten 2.0.3 (#613) * update bazel workspace for emscripten 2.0.3 * test to make sure WORKSPACE is up to date * make it clear what happened when WORKSPACE is out of date * intentionally add error to make sure circleci fails properly * revert intentionally bad commit * increase visibility of failure message Co-authored-by: Mitch Foley <mitchfoley@google.com>
2020-09-11 20:15:19 -04:00
# Ensure the WORKSPACE file is up to date with the latest version.
Use emsdk as external bazel dependency (#766) * 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
2021-03-25 00:50:44 +01:00
grep ${VER} bazel/revisions.bzl || (echo ${FAILMSG} && false)
grep ${HASH} bazel/revisions.bzl || (echo ${FAILMSG} && false)
Bazel: Migrate to bzlmod (#1530) 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
2025-04-09 23:38:12 +02:00
grep ${VER} bazel/MODULE.bazel || (echo ${FAILMSG} && false)
Fix bazel ci (#1504) This is a temporary fix until I can do https://bazel.build/external/migration
2024-12-13 21:39:55 -05:00
add a wasm bazel toolchain (#603)
2020-09-10 21:42:46 -04:00
cd bazel
Bazel: Migrate to bzlmod (#1530) 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
2025-04-09 23:38:12 +02:00
bazel build //hello-world:hello-world-wasm
bazel build //hello-world:hello-world-wasm-simd
Use emsdk as external bazel dependency (#766) * 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
2021-03-25 00:50:44 +01:00
cd test_external
Bazel: Migrate to bzlmod (#1530) 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
2025-04-09 23:38:12 +02:00
bazel build //:hello-world-wasm
bazel build //long_command_line:long_command_line_wasm
bazel build //:hello-embind-wasm --compilation_mode dbg # debug
Add closure example for wasm_cc_binary (#941) * Stub out addition of closure_externs_file option in wasm_cc_binary * WIP * args are passed, externs cannot be found * try location * update tests
2022-02-17 13:16:18 -05:00
Update build_bazel_rules_nodejs to fix closure compiles (#912) * Update build_bazel_rules_nodejs to fix closure compiles * Fix spacing in update_bazel_workspace.sh script * space
2021-10-19 17:44:48 -04:00
# Test use of the closure compiler
Bazel: Migrate to bzlmod (#1530) 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
2025-04-09 23:38:12 +02:00
bazel build //:hello-embind-wasm --compilation_mode opt # release
Add closure example for wasm_cc_binary (#941) * Stub out addition of closure_externs_file option in wasm_cc_binary * WIP * args are passed, externs cannot be found * try location * update tests
2022-02-17 13:16:18 -05:00
# This function should not be minified if the externs file is loaded correctly.
fix(bazel): use param file for compile (#1373) * fixes issues on windows when dealing with many dependencies causing a 'command line too long' error
2024-04-22 11:19:11 -07:00
grep "customJSFunctionToTestClosure" bazel-bin/hello-embind-wasm/hello-embind.js
[Bazel] Support generating a secondary cache (#1405) 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
2024-07-01 18:23:07 +02:00
cd ../test_secondary_lto_cache
Bazel: Migrate to bzlmod (#1530) 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
2025-04-09 23:38:12 +02:00
bazel build //:hello-world-wasm
Reference in New Issue Copy Permalink