Feature: influence default behavior/settings of `compile` strategy

[mqudsi]

Sorry if I'm requesting something already possible, but if it's supported I couldn't tell from reading SUPPORT.md!

For non-trivial crates with dependencies and multiple optional features, releases are often compiled with specific values or settings for the following:

• RUSTFLAGS
• default-features = true/false
• additional features
• environment variables that influence build scripts (in the crate itself or for (transitive) dependencies)
• etc

For example, for an upcoming SecureStore release, I would specifically want to use --no-default-features + --features rustls on Windows for the ssclient cli, because compiling the crate with the default features depends on OpenSSL and OpenSSL is much harder to link against on Windows than on Linux or macOS.

[NobodyXu]

Yeah that's indeed we don't support.

If we add the --features cmdlind flag, then that'd only take effect for compile strategy and I think it'd be confusing.

What we can do, however, is to introduce another flag --cargo-install-flags and let user passed in custom flags for cargo-install

Alternatively user can just disable compile strategy and manually invoke cargo-install

cc @passcod wdyt

[passcod]

There's several things here:

• we do support the upstream binary being compiled whatever way the upstream wants (binstall itself does that)
• we don't support multiple builds per upstream (e.g. upstream builds with-rustls and with-openssl, and wants to make that available to binstall users), but we could
• we don't support passing --features, because that would only apply in the compile from source case

to support that last usecase, you can do something like

cargo binstall -f --disable-strategies=compile foo || cargo install --no-default-features --features=bar foo

[mqudsi]

Thanks for the info, it is basically what I assumed.

Your suggested alternative works well, but not for the case I have in mind: it works when the user knows the project and understands how the bins should be built for their platform. But the goal is for the project to provide the default per-platform/target configuration compiling from source should default to for users so they don’t have to look it up themselves, i.e. to build with the same settings the precompiled binary would have had, build with the options most likely to successfully build for the majority of users on that target (consider external dependencies), or whatever.

(I’m not asking for multiple precompiled binaries with different/conflicting features to be provideable, though I can see how that would be helpful to some.)

[passcod]

Actually, I guess we could support that, but not as a CLI flag, instead as a Cargo.toml field for the crate to set (and maybe a flag to disable that).

[mqudsi]

Awesome, that’s what I had in mind!