The extra work involved in loading the logger and creating the record
struct involves move codegen than is necessary if we take this kind of
approach (which we previously used in 0.3). It's a bit unfortunate to
have these public-but-not-public functions, but I think it's worth it.
We want to minimize the footprint of logging so people feel comfortable
using it!
A main function containing nothing but `warn!("hello world")` shrinks
from 204 bytes to 124 bytes in x86_64 with this change.
Closes #275
log
A Rust library providing a lightweight logging facade.
A logging facade provides a single logging API that abstracts over the actual logging implementation. Libraries can use the logging API provided by this crate, and the consumer of those libraries can choose the logging implementation that is most suitable for its use case.
Usage
In libraries
Libraries should link only to the log crate, and use the provided macros to
log whatever information will be useful to downstream consumers:
[dependencies]
log = "0.4"
#[macro_use]
extern crate log;
pub fn shave_the_yak(yak: &mut Yak) {
trace!("Commencing yak shaving");
loop {
match find_a_razor() {
Ok(razor) => {
info!("Razor located: {}", razor);
yak.shave(razor);
break;
}
Err(err) => {
warn!("Unable to locate a razor: {}, retrying", err);
}
}
}
}
In executables
In order to produce log output executables have to use a logger implementation compatible with the facade. There are many available implementations to chose from, here are some of the most popular ones:
- Simple minimal loggers:
- Complex configurable frameworks:
- Adaptors for other facilities:
Executables should choose a logger implementation and initialize it early in the runtime of the program. Logger implementations will typically include a function to do this. Any log messages generated before the logger is initialized will be ignored.
The executable itself may use the log crate to log as well.