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

Support activating certain features #19

Open
nicolaslara opened this issue Aug 19, 2022 · 9 comments · May be fixed by #26
Open

Support activating certain features #19

nicolaslara opened this issue Aug 19, 2022 · 9 comments · May be fixed by #26

Comments

@nicolaslara
Copy link
Contributor

nicolaslara commented Aug 19, 2022

Running cargo build --feature x or cargo build --all-features works well, but trying to specify it on cw-optimizoor:

❯ cargo cw-optimizoor -- --all-features

exits with no output and empty artifacts/

@mandrean
Copy link
Owner

mandrean commented Aug 20, 2022

Hi @nicolaslara, thanks for bringing this up.

It's by design. Feature-flags in Rust are additive across all workspace members:
rust-lang/cargo#3620
rust-lang/cargo#8157 (comment)
rust-lang/cargo#4463
rust-lang/cargo#4866
rust-lang/cargo#10266 (comment)

ehuss commented on Jul 6, 2020
Thanks for the report! This is a known issue /.../
The --workspace flag causes all features of all workspace members to be unified.

It's standard practice in CosmWasm contracts to have not(library) feature flags around their entry points:
https://github.com/CosmWasm/cw-plus/blob/main/contracts/cw1-subkeys/src/contract.rs#L48

#[cfg_attr(not(feature = "library"), entry_point)]
pub fn execute(...)

Meaning, if you compile such a CosmWasm workspace with "all features" then those entry points will be missing from every .wasm artifact! It won't work at all in production. See related #3.

Furthermore, cargo build --all-features isn't the right command for outputting .wasm files. It should also include the target, i.e. --target wasm32-unknown-unknown.

But most importantly, cargo build --all-features can't even compile https://github.com/CosmWasm/cw-plus which is a core requirement for this project, and also an e2e test:

❯ git clone https://github.com/CosmWasm/cw-plus && cd cw-plus
❯ rustc -V
rustc 1.63.0 (4b91a6ea7 2022-08-08)
❯ cargo -V
cargo 1.63.0 (fd9c4297c 2022-07-01)

❯ cargo build --all-features
   Compiling cosmwasm-std v1.0.0
error[E0554]: `#![feature]` may not be used on the stable release channel
 --> /Users/mandrean/.cargo/registry/src/github.com-1ecc6299db9ec823/cosmwasm-std-1.0.0/src/lib.rs:1:45
  |
1 | #![cfg_attr(feature = "backtraces", feature(backtrace))]
  |                                             ^^^^^^^^^

For more information about this error, try `rustc --explain E0554`.
error: could not compile `cosmwasm-std` due to previous error

If you have any more questions, I'm happy to discuss it. Otherwise I'll close this as a Won't Fix in a couple of days.

Thanks!

@nicolaslara
Copy link
Contributor Author

Thanks for the quick reply!

I probably was a little sparse on the details when I wrote this. I don't really want to use --all-features (for the reasons you describe above), but thought that was the clearest way to describe the issue without having the go into details of my use case.

The reason I want to use features in cw-optimizoor is because I'm using it in CI to build the contracts for testing (and to verify that the wasm files included in the go integration tests actually come from the latest code). Using features also allows the contracts to include code that is only used when integration testing (but ignored in prod). Right now I'm building the wasm files used for testing manually but, without being able to specify the features, I can't make sure that the included wasm files are produced from the code in the commit being tested.

Now, features being additive across workspaces is clearly a problem here, and it's clearly something that's outside the scope of this repo. However, I still see value in allowing cw-optimizoor to use the same parameters that building a workspace would allow; there are probably other use cases that we haven't thought of which would expect the parity. Off the top of my head, building the same contracts for different chains is something that could benefit from contract-specific features (for example, a contract that does swaps could use gamm on opsmosis, and junoswap on juno)

@mandrean
Copy link
Owner

mandrean commented Aug 22, 2022

Thanks for clarifying!

So I have an idea. The Cargo manifest supports specifying aliases/groups of feature flags as such:
https://doc.rust-lang.org/cargo/reference/features.html#features

Also cargo build has an option for activating feature flags when building:

❯ cargo build -h
...
-F, --features <FEATURES>       Space or comma separated list of features to activate

If cw-optimizoor supported -F, --features <FEATURES> (in combination with feature-flag groups Cargo.toml), would that cover your use-case?

@nicolaslara
Copy link
Contributor Author

yes, that would be enough to solve my use case

I don't think I even need the groups, since I only have one crate in my workspace right now, but it will probably be useful to someone else :)

@mandrean mandrean changed the title Can't build contracts that use features. Support activating certain features Aug 23, 2022
@mandrean
Copy link
Owner

Awesome. Updated the title of the issue, will put something together

@nicolaslara
Copy link
Contributor Author

thanks!

@whalelephant
Copy link

whalelephant commented Oct 20, 2022

hey @mandrean Thank you for addressing this issue, I am also looking to compile with features and wondered if there is anything I can help with for this?

@mandrean mandrean linked a pull request Dec 22, 2022 that will close this issue
@mandrean
Copy link
Owner

mandrean commented Jan 9, 2023

Sorry for the inactivity, had some family issues last autumn.

Anyway, working on this in #26 but its a little bit trickier than I first thought due to weird behavior in cargo itself. Trying some workarounds!

@nicolaslara
Copy link
Contributor Author

no worries! thanks for all the work! and I hope the family issues got sorted out

Repository owner deleted a comment from chasedson Feb 7, 2024
Repository owner deleted a comment from Pappyskull1 Feb 23, 2024
@github-staff github-staff deleted a comment from 0legR Apr 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants