Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Support features setting for reproducible builds #312

Open
frol opened this issue Feb 26, 2025 · 4 comments
Open

feat: Support features setting for reproducible builds #312

frol opened this issue Feb 26, 2025 · 4 comments
Labels
enhancement New feature or request

Comments

@frol
Copy link
Contributor

frol commented Feb 26, 2025

There are use-cases where users want to specify feature flags to compile contracts for different environments, e.g. testnet vs mainnet

@frol frol added the enhancement New feature or request label Feb 26, 2025
@dj8yfo
Copy link
Collaborator

dj8yfo commented Mar 3, 2025

This could be done. Alternatively, one could use https://doc.rust-lang.org/cargo/reference/build-scripts.html#rustc-cfg in build script depending on a value from passed_env in manifest, but this says it only offers limited support of features (not enabling optional dependencies and sub-features, as far as i've understood), so just appending value from --features would be a simpler/more complete way to do this.

@dj8yfo
Copy link
Collaborator

dj8yfo commented Mar 3, 2025

The --features flag of non-reproducible command may be made repeatable with vec_multiple_opt interactive clap option to better mirror behaviour of plain cargo command

@frol
Copy link
Contributor Author

frol commented Mar 6, 2025

I don't understand how to use build-scripts when I just want to build a simple contract.

@dj8yfo
Copy link
Collaborator

dj8yfo commented Mar 8, 2025

I don't understand

Well, that was me exploring a variant of containing all build parameters, not defined in source code, to passed_env. But that would be more complex and not support features completely, so just re-adding previously removed --features flag will be simple.
Doing this once per flag when needed makes more sense than just bulk adding a lot of options with no specific purpose in mind

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants