Skip to content

[core] Add ROOT_LOG env var support for RLogger#21455

Open
deveshbervar wants to merge 3 commits intoroot-project:masterfrom
deveshbervar:feature/rlogger-env-var
Open

[core] Add ROOT_LOG env var support for RLogger#21455
deveshbervar wants to merge 3 commits intoroot-project:masterfrom
deveshbervar:feature/rlogger-env-var

Conversation

@deveshbervar
Copy link

Why

Enables per-channel verbosity to be configured at startup via an
environment variable, without recompiling ROOT. This allows tracing
(e.g. CMS autoparsing after #7609) by simply setting ROOT_LOG.

What

Setting ROOT_LOG at startup now configures RLogger channel verbosity:

export ROOT_LOG='ROOT.InterpreterPerf=Debug(3),ROOT.RBrowser=Error'

Supported levels: Fatal, Error, Warning, Info, Debug, Debug(N).
gDebug is also applied as a global verbosity floor.

Changes

  • RLogger.hxx: added fEnvVerbosity map to RLogManager, added
    GetEnvVerbosity(), updated GetEffectiveVerbosity() to check
    per-channel env overrides before falling back to global verbosity
  • RLogger.cxx: constructor now parses ROOT_LOG and applies gDebug

Tests

Since RLogManager is a static singleton initialized once at process
startup, setenv() mid-test does not affect it. I would appreciate
guidance from the maintainer on the recommended approach for testing
this feature. Happy to add tests based on your feedback.

@deveshbervar
Copy link
Author

@dpiparo ping! PR ready for review. I have implemented the ROOT_LOG
environment variable support as described in the issue. Please let me
know if any changes are needed, especially regarding the test approach
for the singleton RLogManager. Thank you!

@dpiparo
Copy link
Member

dpiparo commented Mar 3, 2026

Is testing perhaps still missing?

@deveshbervar
Copy link
Author

Hi @dpiparo, tests have been added in core/foundation/test/RLoggerEnvVar.cxx.

Since RLogManager is a static singleton that parses ROOT_LOG once at
process startup, I used CMake's set_tests_properties ENVIRONMENT to
set ROOT_LOG before the test process starts, rather than setenv() mid-test.

Please let me know if this approach is acceptable or if you'd prefer
a different testing strategy. Thank you!

Comment on lines -88 to -94
// Is there a specific level for the channel? If so, take that,
// overruling the global one.
if (channel->GetEffectiveVerbosity(*this) < entry.fLevel)
return true;

// Lock-protected extraction of handlers, such that they don't get added during the
// handler iteration.
Copy link
Member

@pcanal pcanal Mar 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are those code comments no longer relevant/helpful?

@deveshbervar
Copy link
Author

Hi @pcanal,
Sorry, those comments were accidentally removed during editing.
Restored them now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants