You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

55 lines
2.2 KiB

Build "min" artifacts on CI (#7315) * riscv64: Extend distance trampolines can jump Use a PIC-friendly set of instructions to enable destination of the trampoline to be more than 4k away from the tail call site of the trampoline itself. * Build "min" artifacts on CI This commit updates the binary artifacts produced by CI to include "min" builds where all default features are disabled. Additionally all the stops are pulled in terms of build flags, nightly versions, etc, to get a build that is as small as possible without actual source code changes. This effectively codifies the instructions in #7282 into an easily downloadable artifact. No new tarballs are created for github releases but instead tarballs that previously had a `wasmtime` executable for example now have a `wasmtime-min` executable. Furthermore the C API which previously had `libwasmtime.so` for example now has `libwasmtime-min.so`. The intention is that the minimum-size artifacts are handy for determining a rough size of Wasmtime but they're not so important that it seems worthwhile to dedicate entire release entries for. CI is refactored to support these minimum builds with separate builders. This means that a single tarball produced as a final result is actually two separate tarballs merged together, one for the normal build we do today plus a new "min" tarball produced on the new "min" builders. Various scripts and CI organization has been adjusted accordingly. While here I went ahead and enabled `panic=abort` and debuginfo stripping in our current release artifacts. While this doesn't affect a whole lot it's less to upload to GitHub Actions all the time. * Fix Windows unzip
1 year ago
#!/bin/bash
# A script to build the release artifacts of Wasmtime into the `target`
# directory. For now this is the CLI and the C API. Note that this script only
# produces the artifacts through Cargo and doesn't package things up. That's
# intended for the `build-tarballs.sh` script.
#
# This script takes a Rust target as its first input and optionally a parameter
# afterwards which can be "-min" to indicate that a minimal build should be
# produced with as many features as possible stripped out.
set -ex
build=$1
target=$2
# Default build flags for release artifacts. Leave debugging for
# builds-from-source which have richer information anyway, and additionally the
# CLI won't benefit from catching unwinds and neither will the C API so use
# panic=abort in both situations.
export CARGO_PROFILE_RELEASE_STRIP=debuginfo
export CARGO_PROFILE_RELEASE_PANIC=abort
if [[ "$build" = *-min ]]; then
# Configure a whole bunch of compile-time options which help reduce the size
# of the binary artifact produced.
export CARGO_PROFILE_RELEASE_OPT_LEVEL=s
export RUSTFLAGS="-Zlocation-detail=none $RUSTFLAGS"
Build "min" artifacts on CI (#7315) * riscv64: Extend distance trampolines can jump Use a PIC-friendly set of instructions to enable destination of the trampoline to be more than 4k away from the tail call site of the trampoline itself. * Build "min" artifacts on CI This commit updates the binary artifacts produced by CI to include "min" builds where all default features are disabled. Additionally all the stops are pulled in terms of build flags, nightly versions, etc, to get a build that is as small as possible without actual source code changes. This effectively codifies the instructions in #7282 into an easily downloadable artifact. No new tarballs are created for github releases but instead tarballs that previously had a `wasmtime` executable for example now have a `wasmtime-min` executable. Furthermore the C API which previously had `libwasmtime.so` for example now has `libwasmtime-min.so`. The intention is that the minimum-size artifacts are handy for determining a rough size of Wasmtime but they're not so important that it seems worthwhile to dedicate entire release entries for. CI is refactored to support these minimum builds with separate builders. This means that a single tarball produced as a final result is actually two separate tarballs merged together, one for the normal build we do today plus a new "min" tarball produced on the new "min" builders. Various scripts and CI organization has been adjusted accordingly. While here I went ahead and enabled `panic=abort` and debuginfo stripping in our current release artifacts. While this doesn't affect a whole lot it's less to upload to GitHub Actions all the time. * Fix Windows unzip
1 year ago
export CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1
export CARGO_PROFILE_RELEASE_LTO=true
Refactor installation of C API and features supported (#8642) * Refactor installation of C API and features supported This commit overhauls and refactors the management of the building of the C API. Instead of this being script-based it's now done entirely through CMake and CMake is the primary focus for building the C API. For example building the C API release artifacts is now done through CMake instead of through a shell script's `cargo build` and manually moving artifacts. The benefits that this brings are: * The C API now properly hides symbols in its header files that weren't enabled at build time. This is done through a new build-time generated `conf.h` templated on a `conf.h.in` file in the source tree. * The C API's project now supports enabling/disabling Cargo features to have finer-grained support over what's included (plus auto-management of the header file). * Building the C API and managing it is now exclusively done through CMake. For example invoking `doxygen` now lives in CMake, installation lives there, etc. The `CMakeLists.txt` file for the C API is overhauled in the process of doing this. The build now primarily matches on the Rust target being built rather than the host target. Additionally installation will now install both the static and shared libraries instead of just one. Additionally during this refactoring various bits and pieces of Android-specific code were all removed. Management of the C toolchain feels best left in scope of the caller (e.g. configuring `CC_*` env vars and such) rather than here. prtest:full * Don't use `option` for optional strings * Invert release build check Also adjust some indentation * Fix more indentation * Remove no-longer-used variable * Reduce duplication in feature macro
6 months ago
build_std=-Zbuild-std=std,panic_abort
build_std_features=-Zbuild-std-features=std_detect_dlsym_getauxval
flags="$build_std $build_std_features --no-default-features --features disable-logging"
cmake_flags="-DWASMTIME_DISABLE_ALL_FEATURES=ON"
cmake_flags="$cmake_flags -DWASMTIME_FEATURE_DISABLE_LOGGING=ON"
cmake_flags="$cmake_flags -DWASMTIME_USER_CARGO_BUILD_OPTIONS:LIST=$build_std;$build_std_features"
Build "min" artifacts on CI (#7315) * riscv64: Extend distance trampolines can jump Use a PIC-friendly set of instructions to enable destination of the trampoline to be more than 4k away from the tail call site of the trampoline itself. * Build "min" artifacts on CI This commit updates the binary artifacts produced by CI to include "min" builds where all default features are disabled. Additionally all the stops are pulled in terms of build flags, nightly versions, etc, to get a build that is as small as possible without actual source code changes. This effectively codifies the instructions in #7282 into an easily downloadable artifact. No new tarballs are created for github releases but instead tarballs that previously had a `wasmtime` executable for example now have a `wasmtime-min` executable. Furthermore the C API which previously had `libwasmtime.so` for example now has `libwasmtime-min.so`. The intention is that the minimum-size artifacts are handy for determining a rough size of Wasmtime but they're not so important that it seems worthwhile to dedicate entire release entries for. CI is refactored to support these minimum builds with separate builders. This means that a single tarball produced as a final result is actually two separate tarballs merged together, one for the normal build we do today plus a new "min" tarball produced on the new "min" builders. Various scripts and CI organization has been adjusted accordingly. While here I went ahead and enabled `panic=abort` and debuginfo stripping in our current release artifacts. While this doesn't affect a whole lot it's less to upload to GitHub Actions all the time. * Fix Windows unzip
1 year ago
else
# For release builds the CLI is built a bit more feature-ful than the Cargo
# defaults to provide artifacts that can do as much as possible.
bin_flags="--features all-arch,component-model"
fi
cargo build --release $flags --target $target -p wasmtime-cli $bin_flags --features run
Refactor installation of C API and features supported (#8642) * Refactor installation of C API and features supported This commit overhauls and refactors the management of the building of the C API. Instead of this being script-based it's now done entirely through CMake and CMake is the primary focus for building the C API. For example building the C API release artifacts is now done through CMake instead of through a shell script's `cargo build` and manually moving artifacts. The benefits that this brings are: * The C API now properly hides symbols in its header files that weren't enabled at build time. This is done through a new build-time generated `conf.h` templated on a `conf.h.in` file in the source tree. * The C API's project now supports enabling/disabling Cargo features to have finer-grained support over what's included (plus auto-management of the header file). * Building the C API and managing it is now exclusively done through CMake. For example invoking `doxygen` now lives in CMake, installation lives there, etc. The `CMakeLists.txt` file for the C API is overhauled in the process of doing this. The build now primarily matches on the Rust target being built rather than the host target. Additionally installation will now install both the static and shared libraries instead of just one. Additionally during this refactoring various bits and pieces of Android-specific code were all removed. Management of the C toolchain feels best left in scope of the caller (e.g. configuring `CC_*` env vars and such) rather than here. prtest:full * Don't use `option` for optional strings * Invert release build check Also adjust some indentation * Fix more indentation * Remove no-longer-used variable * Reduce duplication in feature macro
6 months ago
mkdir -p target/c-api-build
cd target/c-api-build
cmake \
../../crates/c-api \
$cmake_flags \
-DCMAKE_BUILD_TYPE=Release \
-DWASMTIME_TARGET=$target \
-DCMAKE_INSTALL_PREFIX=../c-api-install \
-DCMAKE_INSTALL_LIBDIR=../c-api-install/lib
cmake --build . --target install