New logger subsystem

[TheJJ]

We need a better logging system.

Filtering messages, verbosity levels, origin tracking, backtraces, ...

[mic-e]

fak u jj

[o11c]

On colors in logs:

Terminal programs that can output color should have a --color command-line option. --color is short for --color=always (some programs get this wrong). --color=never and --color=auto also exist; the latter is the default if the option is not found on the command line at all.

If --color=auto is chosen, check isatty(3) on the file descriptor you are writing to - either stdout (STDOUT_FILENO=1) or stderr (STDERR_FILENO=2). Output written to files other than stdout and stderr should ignore the command-line option and output no color. (Possibly there might be a separate configuration option color_in_log_files but this probably wouldn't be available as a command-line option. There's also an exception if you explicitly open a new tty.)

As a GUI program that only writes to stdout/stderr as a secondary sink, it feels funny for openage to accept --color, but the same principles should apply.

[o11c]

As for the API itself, I think it is a fatal mistake to think in terms of logging strings. Instead, log structures. In particular, this is useful for what I do a lot, which is parse files. My logging structure is like:

enum class LogLevel { WARNING, ERROR };
struct LogMessage {
    io::LineSpan span;
    std::string message;
};
struct LogEntry {
    LogLevel level;
    LogMessage main_message;
    std::string option; // think [-Wfoo] from gcc; don't store the "-W" because "level" controls how it prints
    std::vector<LogMessage> notes;
};

Additionally, since I'm making a server, it's my goal to switch all my logging to syslog, since otherwise I have to reinvent log rotation and everything manually.

[mic-e]

@o11c Don't worry, I have a pretty sophisticated design (I just was too lazy to actually implement it up until now).

[franciscod]

@mic-e _deaztec crickets