People who use alternative build systems like Bazel often do not use the build.rs build script. In 0.17.x we've simplified and refactoed build.rs to make it easier to "port" its logic to 3rd-party build systems. We should document a checklist of steps that a ring user who is not using build.rs, when updating to a new version of ring, as they'll often have to adjust their build logic according to nay changes we've made in build.rs.
For example, in the 0.17.0 release, we added a dependency on the CARGO_MANIFEST_LINKS environment variable to build.rs. This broke peoples' Bazel builds because Bazel's rules_rust didn't define CARGO_MANIFEST_LINKS. If we had the appropriate checklist for upgrading to a new version of ring with an alternative build system, users would have discovered this.
Similarly, in the next upcoming release, we're adding a dependency on CARGO_CFG_TARGET_VENDOR and also adding new cfg logic that needs to be replicated in an alternative build system (ring_x25519_neon; see #1919). https://github.com/briansmith/ring/issues/1832 plans to expand this pattern to all targets.
We should note:
The document MSRV in Cargo.toml indicates the minimum version of Cargo we support. We assume that all the environment variables that that version of Cargo supports are available to build.rs. As long as build.rs works correctly on the MSRV of Cargo, we will consider the change to be SemVer-compatible. In other words, we expect alternative build systems to be compatible with Cargo w.r.t. the environment variables supported.
We do not test alternative build systems and support for them is limited accordingly. For example, we have no CI coverage.
We encourage people to submit improvements to build.rs that make it easier to mirror in other build systems.
People who use alternative build systems like Bazel often do not use the build.rs build script. In 0.17.x we've simplified and refactoed build.rs to make it easier to "port" its logic to 3rd-party build systems. We should document a checklist of steps that a ring user who is not using build.rs, when updating to a new version of ring, as they'll often have to adjust their build logic according to nay changes we've made in build.rs.
For example, in the 0.17.0 release, we added a dependency on the
CARGO_MANIFEST_LINKS
environment variable to build.rs. This broke peoples' Bazel builds because Bazel's rules_rust didn't defineCARGO_MANIFEST_LINKS
. If we had the appropriate checklist for upgrading to a new version of ring with an alternative build system, users would have discovered this.Similarly, in the next upcoming release, we're adding a dependency on
CARGO_CFG_TARGET_VENDOR
and also adding newcfg
logic that needs to be replicated in an alternative build system (ring_x25519_neon
; see #1919). https://github.com/briansmith/ring/issues/1832 plans to expand this pattern to all targets.We should note: