Release logging is capped at info

[barsoosayque]

Building a bevy app in release mode sets the static max level of tracing to info. Here is the warning I get:

warning: some trace filter directives would enable traces that are disabled statically
 | `debug` would enable the DEBUG level for all targets
 = note: the static max level is `info`
 = help: to enable DEBUG logging, remove the `max_level_info` feature

I've tried:

• Setting LogSettings::level to DEBUG (Obviously, wouldn't help, since the problem is at compile time)
• Declaring [dependencies.tracing] with features = ["release_max_level_debug"], but it seems that out of two levels, tracing still picks info.

As far as I understand, currently it is not possible to remove a feature from a transitive dependency, and because "release_max_level_info" is not a default feature of tracing, it's also impossible to disable it using default-features = false. Am I missing something ?

If there is no solution, I propose removing bevy_utils/tracing/release_max_level_info, and simply move the responsibility to users.

[cart]

I think thats a fair take. I'm just a bit worried that most people won't think to do this and a significant percentage of bevy games will be released with measurably slower builds.

Before changing this default, I'd like to see a frame time comparison of the feature enabled/disabled for something that renders a lot of entities (maybe bevymark).

[Ratysz]

It should possible to re-export that feature in Bevy, and make the re-export enabled by default. That way it retains current behavior while also allowing users to disable it.

[wendivoid]

This has been a mildly annoying issue for me lately. I only have a horribly underpowered laptop so when using rapier i must compile in release mode, and not having the log kinda sucks honestly.

Ratysz is right i believe, bevy can re-export the features from tracing preserving the current behavior like this:

[features]
default = ["tracing/release_max_level_info"]
release_max_level_debug = ["tracing/release_max_level_debug"]
release_max_level_trace = ["tracing/release_max_level_trace"]

I'd like to fix this i just have a couple questions.

1. Should bevy crate re-export the features as well or just bevy_utils? I'm pretty sure a user could then specify bevy_utils = { features = ["release_max_level_debug"], .. } in Cargo.toml to activate the feature
2. Should any other tracing features be re-exported? A quick glance at tracings Cargo.toml the relevant features are:
   • max_level_debug
   • max_level_error
   • max_level_info
   • max_level_off
   • max_level_trace
   • max_level_warn
   • release_max_level_debug
   • release_max_level_error
   • release_max_level_info
   • release_max_level_off
   • release_max_level_trace
   • release_max_level_warn
     The only 2 that really apply are release_max_level_debug & release_max_level_trace
3. Should the feature name stay they same? It makes sense in tracings context to only use the name 'release_max_level_debug' but bevy_utils isn't only logging 'release_max_log_level_debug' gives a bit more context.

[mockersf]

Should bevy crate re-export the features as well or just bevy_utils? I'm pretty sure a user could then specify bevy_utils = { features = ["release_max_level_debug"], .. } in Cargo.toml to activate the feature

I think the Bevy root crate needs to re-export the features and the default one need to be set at this level to be disable-able by the end user

Should any other tracing features be re-exported?

I would go with all the release_* ones as that's probably the ones that makes the most sense to use in a game

Should the feature name stay they same?

I think so, to help discoverability, but not sure

This has been a mildly annoying issue for me lately. I only have a horribly underpowered laptop so when using rapier i must compile in release mode, and not having the log kinda sucks honestly.

Side note, but if you put in your Cargo.toml

[profile.dev.package."*"]
opt-level = 3

your dependencies will be built in release but not your own code, which should allow for enough optimisations while still running your code in debug

[wendivoid]

Oh snap, Sorry for waiting so long to reply, I must have missed this. Hmm i didn't know you could use wildcards there.

My project is split into many sub crates that i want to be compiled in debug mode, i found the best way around this (for me) is to use the snippet above and specify my crates as being compiled in debug mode with

[profile.dev.package.crate-name]
opt-level = 1

Thanks for your help @mockersf