Summary:
In order to adapt bc-rust crates to support no_std builds using cargo features, we require simpler ways to validate that the workspace, as well as individual crates, are able to build and pass tests across all of the different build flavours (dev and release profiles, for both std (alloc enabled) and no_std (alloc disabled) feature options).
Validation for this has so far required manual effort, and it does not appear that there are any straightforward ways to accomplish this using vanilla cargo features.
This sub-issue should find a low-maintenance and low-complexity solution to allow contributors (as well as github actions) to perform a validation of all needed combinations of profiles and enabled features with a single command or action.
Scope:
An ideal solution would require as few changes to the existing repo configuration as possible. Options like make, shell scripts, or other build systems could make sense, but the less complexity required the better. Ideally one solution would also work for all supported build platforms (i.e., Windows, MacOS, and Linux?).
Acceptance Criteria:
Summary:
In order to adapt bc-rust crates to support no_std builds using cargo features, we require simpler ways to validate that the workspace, as well as individual crates, are able to build and pass tests across all of the different build flavours (dev and release profiles, for both std (
allocenabled) and no_std (allocdisabled) feature options).Validation for this has so far required manual effort, and it does not appear that there are any straightforward ways to accomplish this using vanilla cargo features.
This sub-issue should find a low-maintenance and low-complexity solution to allow contributors (as well as github actions) to perform a validation of all needed combinations of profiles and enabled features with a single command or action.
Scope:
An ideal solution would require as few changes to the existing repo configuration as possible. Options like make, shell scripts, or other build systems could make sense, but the less complexity required the better. Ideally one solution would also work for all supported build platforms (i.e., Windows, MacOS, and Linux?).
Acceptance Criteria:
allocfeature enabled and disabled