Logging framework

[winterheart]

Currently we have a somewhat crippled logging facility based on an old ddebug/mono submodule. It is available only on Debug and does not provide any useful information on Release build. There was another attempt to use the spdlog library (#212), but we reverted it as it added unneeded external dependency.

For our needs logging framework should have following features:

• Header-only or extremely lightweight embedded library that allows us to use logging without dllexports in our external libraries.
• GPLv3-compatible license.
• Library should support console (stderr/stdout) and file output, with configurable format of message (like timestamp, severity, location and message).
• ostream (<<) and printf-like syntax for creating messages.
• Optionally support for C++17 and STL containers.

After some research I'd like to propose to switch the plog library (https://github.com/SergiusTheBest/plog) as the most suitable solution.

[Lgt2x]

ok for the lib, also noting that it uses CMake (easy integration) and allows sharing instances across libs, which is going to be handy for logging in network code and level scripts. I would prefer actual functions to macros for easier debugging, but it's fine.

A few notes/questions:

• Header-only means we can integrate it as an embedded 3rd party. No more use for USE_LOGGER which should be removed
• I wish we can still keep our own logging module wrapping it, so we only expose our logging functions to the rest of the code. This way, plog is only linked to our log internal library. This allows us to change logging lib without changing thousands of lines if we need to, and to limit functions used (maybe don't use all logging levels?).
• Logging should be enabled all the time for all builds, but default level changes between release and debug
• Should we add CLI options to control log level, and output to stdout or file? -logfile is already a thing, but I'm wondering if the default should be output to file rather than stdout

[Jayman2000]

Why is plog a better option than spdlog?

[winterheart]

Why is plog a better option than spdlog?

Main issue of spdlog that we forced to pull extra dependencies from outside into build process like external libfmt.

[Jayman2000]

Why is plog a better option than spdlog?

Main issue of spdlog that we forced to pull extra dependencies from outside into build process like external libfmt.

I agree that it’s a good thing that plog has less dependencies than spdlog (As far as I can tell, plog only depends on the standard library which is great!). That being said, I disagree that having extra dependencies is the main issue of spdlog.

Here’s what I think that the main issue of spdlog is: when we were using spdlog, we had three different logging systems, mprintf(), SDL_LogMessage() and spdlog. Even if we get rid of the mprintf() stuff entirely, we would still be left with two different logging systems. As long as we depend on SDL, we also depend on SDL_LogMessage(). If we want all log messages to go through spdlog, then we would have to write a custom SDL_LogOutputFunction because SDL uses its own logging functions internally (example).

I’m skeptical about using plog because I don’t think that it makes sense to have two different logging systems for one program. I think that it would make more sense to just define macros that call SDL_LogMessage() with any additional data that we want embedded in the log message (filename, line number, timestamp, etc.).

[Lgt2x]

Implemented by #546 and #587 . Very happy with how it turned out