wasmtime / PR #8642 Generate a `conf.h` in the C API, add... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #8642 Generate a `conf.h` in the C API, add...

Wasmtime GitHub notifications bot (May 17 2024 at 00:21):

alexcrichton opened PR #8642 from alexcrichton:c-api-features-in-cmake to bytecodealliance:main:

Work in progress to leverage our concurrency on PRs to test this more. I'll fill in more details when this is ready.

Wasmtime GitHub notifications bot (May 17 2024 at 00:32):

alexcrichton updated PR #8642.

Wasmtime GitHub notifications bot (May 17 2024 at 00:39):

alexcrichton updated PR #8642.

Wasmtime GitHub notifications bot (May 17 2024 at 00:43):

alexcrichton edited PR #8642:

Work in progress to leverage our concurrency on PRs to test this more. I'll fill in more details when this is ready.

Unorganized bullets of motivation:

C-API can be configured right now and some symbols disappear, but this is not reflected in the C headers

Cannot easily configure features via CMake

Current CMake does not easily support cross-compilation

Unorganized bullets of changes:

Add CMake options for all Cargo features

Add conf.h.in header file and generate conf.h as part of CMake build

Move documenting the C API to CMake (as it needs generated header)

Move installation of the C API into CMake (including things like install_name_tool on macOS)

Wasmtime GitHub notifications bot (May 17 2024 at 00:45):

alexcrichton updated PR #8642.

Wasmtime GitHub notifications bot (May 17 2024 at 01:00):

alexcrichton updated PR #8642.

Wasmtime GitHub notifications bot (May 17 2024 at 01:01):

alexcrichton edited PR #8642:

Work in progress to leverage our concurrency on PRs to test this more. I'll fill in more details when this is ready.

Unorganized bullets of motivation:

C-API can be configured right now and some symbols disappear, but this is not reflected in the C headers

Cannot easily configure features via CMake

Current CMake does not easily support cross-compilation

Unorganized bullets of changes:

Add CMake options for all Cargo features

Add conf.h.in header file and generate conf.h as part of CMake build

Move documenting the C API to CMake (as it needs generated header)

Move installation of the C API into CMake (including things like install_name_tool on macOS)

Various Android bits removed from CMake

The c-api artifacts now have a separate set of headers for the "min" build instead of having the "min" libraries be next to the typical libraries

Wasmtime GitHub notifications bot (May 17 2024 at 01:01):

alexcrichton updated PR #8642.

Wasmtime GitHub notifications bot (May 17 2024 at 02:10):

alexcrichton updated PR #8642.

Wasmtime GitHub notifications bot (May 17 2024 at 02:17):

alexcrichton updated PR #8642.

Wasmtime GitHub notifications bot (May 17 2024 at 03:08):

alexcrichton updated PR #8642.

Wasmtime GitHub notifications bot (May 17 2024 at 03:55):

alexcrichton updated PR #8642.

Wasmtime GitHub notifications bot (May 17 2024 at 03:55):

alexcrichton edited PR #8642:

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.

Last updated: Oct 23 2024 at 20:03 UTC