Configuration to compile Rust with any profile

[kleinesfilmroellchen]

As with wasm-pack, there are only two possible profiles for trunk's Rust compilation: debug and release. While trunk offers direct control over the optimization level, I need to adjust other parameters (debug options, LTO, ...) which are usually set via profiles and detectable in the code itself. Additionally, I do not want to use the release profile. The Wasm web app is just one part of a larger workspace (where all crates share build profiles), and the main executable build in the workspace requires vastly different options in its release build. My current workaround, which I have already been using for wasm-pack, is to reserve the release profile for Wasm and use a custom profile for the main release build. I would prefer the ability to do this the other way around, where the much less important web app gets some custom release profile while the main application gets the default release profile.

(Reopened from #545 since this is still not solved)

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[kleinesfilmroellchen]

Not stale.

[nuzzles]

Maybe solution is to not use wasm-pack and instead opt for using cargo, so that the PROFILE and other environment variables can be set outside of trunk.

Hence, the onus would be on developers to create profiles or release settings, e.g.

[profile.release]
panic = "abort"
lto = true
codegen-units = 1
strip = true

[profile.web-release]
inherits = "release"
opt-level = 's'
strip = "debuginfo"

And then, under the hood, trunk would be invoked via: trunk build --profile web-release (where --release would be a shortcut to --profile=release)

And internally, trunk would build using:

cargo build -p <package> --target wasm32-unknown-unknown --profile web-release
wasm-bindgen --target web --out-dir bindings ${STAGING_DIR}/out.wasm --no-typescript
...

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 5 days with no activity.

[Paul1365972]

This issue shouldn't have been closed, as this problem still affects multiple other projects that are using trunk.

[ctron]

Cleaning up issues, I ran into this one.

Currently trunk itself knows two modes (release and non-release). Trunk's --release basically translates into cargo's --release, but also triggers a bunch of other logic intended for release builds.

Ideally, all of those options end up in some profile, and we have two default profiles. One of those fields being the cargo profile.

That's a bigger task though.

Another alternative would be to add some --cargo-profile flag, which can override the cargo profile ad-hoc. That would do the trick, would be quick, but not the best/ideal way.

[nuzzles]

Another alternative would be to add some --cargo-profile flag, which can override the cargo profile ad-hoc. That would do the trick, would be quick, but not the best/ideal way.

I'd prefer the thoughtful approach, where --profile works as expected and --release is just sugar for --profile release, the same way it works in cargo.

[ctron]

Another alternative would be to add some --cargo-profile flag, which can override the cargo profile ad-hoc. That would do the trick, would be quick, but not the best/ideal way.

I'd prefer the thoughtful approach, where --profile works as expected and --release is just sugar for --profile release, the same way it works in cargo.

I think it makes sense tracking this in a separate issue. It looks to me as if that will have a bigger impact on the whole arguments/env-vars/config area.

[janhohenheim]

Is there any workaround available to tell trunk to use things like opt-level = "z" when it's not already configured in [release]?

[ctron]

Trunk will "only" spawn cargo. With or without the --release flag. That's the only think that is available right now.

[janhohenheim]

@ctron is there a chance to get the profile feature in without waiting for a full config overhaul? I'm asking because we are working on a template for users of the Bevy game engine. The default release profile there should be geared towards native releases, but we also need a different release profile to optimize for size in Wasm builds when automatically deploying on itch.ion in a CI step. Our workaround for now is to reverse it: we have the default profile optimized for Wasm, with a special profile for native builds. This is not an issue for CI, but it means that a user wishing to locally test their game on release needs to run cargo run --profile release-native, which is not ergonomic. If we could pass a profile over the CLI, a user would not need to specify any profile at all: cargo run --release would optimize for performance, trunk serve --release would do the same and not optimize for size, but that does not matter for local development, and the CI deployment could run trunk build --profile release-wasm