cranelift

13342 Commits

49 Branches

140 Tags

128 MiB

Tree: 18a6c71ee0

Commit Graph

Author	SHA1	Message	Date
Alex Crichton	566669eed2	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
Alex Crichton	08b7c87793	Refactor binary-compatible-builds for releases (#4171 ) * Refactor binary-compatible-builds for releases I was poking around this yesterday and noticed a few things that could be improved for our release builds: * The centos container for the x86_64 builds contained a bunch of extra tooling we no longer need such as python3 and a C++ compiler. Along with custom toolchain things this could all get removed since the C we include now is quite simple. * The aarch64 and s390x cross-compiled builds had relatively high glibc version requirements compared to the x86_64 build. This was because we don't use a container to build the cross-compiled binaries. I added containers here along the lines of the x86_64 build to use an older glibc to build the release binary to lower our version requirement. This lower the aarch64 version requirement from glibc 2.28 to 2.17. Additionally the s390x requirement dropped from 2.28 to 2.16. * To make the containers a bit easier to read/write I added `Dockerfile`s for them in a new `ci/docker` directory instead of hardcoding install commands in JS. This isn't intended to be a really big change or anything for anyone, but it's intended to keep our Linux-based builds consistent at least as best we can. * Remove temporary change	3 years ago

Author

SHA1

Message

Date

Alex Crichton

566669eed2

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

Alex Crichton

08b7c87793

Refactor binary-compatible-builds for releases (#4171 )

* Refactor binary-compatible-builds for releases

I was poking around this yesterday and noticed a few things that could
be improved for our release builds:

* The centos container for the x86_64 builds contained a bunch of extra
  tooling we no longer need such as python3 and a C++ compiler. Along
  with custom toolchain things this could all get removed since the C we
  include now is quite simple.

* The aarch64 and s390x cross-compiled builds had relatively high glibc
  version requirements compared to the x86_64 build. This was because we
  don't use a container to build the cross-compiled binaries. I added
  containers here along the lines of the x86_64 build to use an older
  glibc to build the release binary to lower our version requirement.
  This lower the aarch64 version requirement from glibc 2.28 to 2.17.
  Additionally the s390x requirement dropped from 2.28 to 2.16.

* To make the containers a bit easier to read/write I added
  `Dockerfile`s for them in a new `ci/docker` directory instead of
  hardcoding install commands in JS.

This isn't intended to be a really big change or anything for anyone,
but it's intended to keep our Linux-based builds consistent at least as
best we can.

* Remove temporary change

3 years ago

2 Commits (18a6c71ee069f42f9d802d87468a6b6c7d2d2c85)