Open fujitatomoya opened 3 weeks ago
I'll state upfront that I'm not against this feature.
But are there any practical uses for it? While I think that our logging subsystem has a number of problems, swapping out the disk logging backend at runtime doesn't seem to be one of them. So I'd like to hear about a practical use before we spend time on it.
@clalancette
the use case (not production yet) that i have off the top of my head, to support 2 (or multiple) logger backend in the same system.
spdlog
, that just stores the logging files in specific file system. (on-system log just in case.)note: i am spending a couple of days for rcl_logging_syslog
(forwarded to FluentBit), so i can share more details about this. I think i can disclose the source code with some documentation in this weekend. (or hopefully today 😄 )
@clalancette i developed some PoC based on syslog
and support FluentBit
, please see overview https://github.com/fujitatomoya/rcl_logging_syslog
Feature request
Feature description
Currently there is no way to select the logging backend without building
rcl
. This is because that when buildingrcl
, we must choose the logging implementation to be used.In default
rcl_logging_spdlog
is selected ifRCL_LOGGING_IMPLEMENTATION
is not set. But we can change it withRCL_LOGGING_IMPLEMENTATION
and available logging backend library.e.g
rcl_logging_noop
and, no log files are generated with
rcl_logging_noop
This generates the constraint that whole system needs to use only specified logging backend in this workspace. It would be nice if we can build the logger backend libraries, and select the logging backend when the program starts.
Implementation considerations
Current related code is,
https://github.com/ros2/rcl/blob/dcfe9ba4f95e3c0d546d30b3f03b769df16667a1/rcl/cmake/get_default_rcl_logging_implementation.cmake#L26-L34
Probably we can escalate
RCL_LOGGING_IMPLEMENTATION
like howRMW_IMPLEMENTATION
works to select the rmw implementation when executing programs.