Companion for init the RuntimeLogger automatically

[bkchr]

The pr in Substrate paritytech/substrate#8128 will change how we initialize the RuntimeLogger. It will now be enabled automatically for each runtime api call. However, as always, with great power comes great responsibility, this means that this generates more code and more code means a bigger wasm runtime. To prevent this bigger wasm runtime, the is the on-chain-release-build feature to disable logging for the wasm runtime. This feature should be enabled when we build the runtime for on chain.

@s3krit this is important for you, you need to change the runtime build script to go into the polkadot/kusama runtime folder and call cargo build --release --features on-chain-release-build to build the runtime wasm. Better you speak with @chevdor to adapt his srtool.

[chevdor]

cargo build --release --features on-chain-release-build

Fixing srtool and adding --features on-chain-release-build should not be an issue.
I subscribed to this PR and I will test once it is merged or ready to be.

You mention:

you need to change the runtime build script to go into the polkadot/kusama runtime folder ...

Are you saying calling cargo build... from the root (as we do until now) will no longer work and we need to cd into the runtime folder in addition to enabling the new --features on-chain-release-build feature ?

May I also ask you the reason to build by default with the logging for the wasm runtime enabled ?
Wouldn't it safer to build by default without and let the user actively add the feature to get more tracing at the cost of a bigger runtime ?

[bkchr]

May I also ask you the reason to build by default with the logging for the wasm runtime enabled ?
Wouldn't it safer to build by default without and let the user actively add the feature to get more tracing at the cost of a bigger runtime ?

The build isn't less safe when logging is enabled ;) Just some kilobytes bigger. I see this as some kind of consideration between a on-chain build and some development build. Where the later one will happen much more often, thus I think it is fine to optimize for this use-case, especially as their is not security downside or whatever of the logging.