You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using a --cargo-profile which inherits from release does no wasm-optimization.
This is because the release flag has many opinions that shadow a custom profile, primarily around wasm optimization.
Example 1:
let wasm_opt = attrs
.get("data-wasm-opt").map(|val| val.parse()).transpose()?
.unwrap_or_else(|| {if cfg.release{Default::default()}else{WasmOptLevel::Off}});
Example 2:
asyncfn wasm_opt_build(&self,wasm_name:&str) -> Result<()>{// If not in release mode, we skip calling wasm-opt.if !self.cfg.release{returnOk(());}
This shouldn't happen if a custom profile is applied, since I specified my own optimization level (i.e. opt-level = 'z') in a custom wasm-release profile. Currently, if I don't add --release, my custom profile's opt-level is skipped.
Thus, I'd propose the following:
Add a new --opt-level config, which will accept an opt level. Currently it is an attribute in documents, but doesn't have a CLI flag. Opt level should fall back to a sensible default if --release is used, but do nothing if a cargo profile is used.
If --opt-level is absent, and --release is not used, skip wasm-opt.
Hence, using a profiles should behave as such:
trunk build --release
Builds the release cargo profile
Runs wasm-opt with a default optimization level (current behavior)
trunk build --cargo-profile wasm-release
Builds the wasm-release cargo profile
Skips wasm-opt
trunk build --cargo-profile wasm-release --opt-level z
Builds the wasm-release cargo profile
Runs wasm-opt with a aggresize size ('z') optimization level
The text was updated successfully, but these errors were encountered:
An alternative I didn't mention is that we could attempt to read and inherit the optimization level from a given cargo-profile in the cargo manifest for packages (or workspace manifest, if a member).
Benefits:
No additional cli flag
Cons:
More complicated
What if the user wants a different wasm-opt level from a cargo opt level? Are they 1:1?
IIRC a lot of features internally are triggered by the "release" flag. I think we should move away from this and have individual settings. And having --release only change the default values for those individual flags.
As discovered in #605,
Using a
--cargo-profile
which inherits from release does no wasm-optimization.This is because the release flag has many opinions that shadow a custom profile, primarily around wasm optimization.
Example 1:
Example 2:
This shouldn't happen if a custom profile is applied, since I specified my own optimization level (i.e.
opt-level = 'z'
) in a customwasm-release
profile. Currently, if I don't add--release
, my custom profile's opt-level is skipped.Thus, I'd propose the following:
--opt-level
config, which will accept an opt level. Currently it is an attribute in documents, but doesn't have a CLI flag. Opt level should fall back to a sensible default if--release
is used, but do nothing if a cargo profile is used.--opt-level
is absent, and--release
is not used, skipwasm-opt
.Hence, using a profiles should behave as such:
release
cargo profilewasm-opt
with a default optimization level (current behavior)wasm-release
cargo profilewasm-opt
wasm-release
cargo profilewasm-opt
with a aggresize size ('z') optimization levelThe text was updated successfully, but these errors were encountered: