[daliborfox]

This pull request updates the dbgprint module so that it makes use of C++20 standard library facilities instead of Windows ones where possible, and allows the module to work on non-Windows systems, having been tested on Linux and Mac:

On Mac, the operating system version for the log banner is retrieved from the SystemVersion.plist file, on other systems the /etc/os-release or /usr/lib/os-release file is queried. The output of uname -a is provided as a fallback in case those files don't exist.

Reading the .plist file does require an additional dependency of libxml2 on Mac, though it's a part of the macOS SDK, so the user doesn't need to install any additional dependencies themselves when building OpenTS with this module (build system support not yet available).

The default location for the logging directory is as follows:

• Windows: <dir-with-game-exe>\Debug\
• Mac: ~/Library/Logs/OpenTS/
• Others (Linux): $XDG_STATE_HOME/OpenTS/, with a fallback of $HOME/.local/state/OpenTS/
• Fallback: ./OpenTS-Logs/

A new feature is the ability to specify the desired location of the log file. If the -USERDIR=<path> command-line option is specified, the logs will be located in the following directory:

• <USERDIR>/Debug/

In order to gracefully use objects that dynamically allocate memory, the module holds its state in a lazy initialization singleton. This singleton contains an m_DebugDestroyed flag that causes all of the module's functions to gracefully fail if they try to make use of the shared state after it's already had its destructor called by the C++ runtime.

The same applies to the thread-local buffers used for holding the vsnprintf() formatting data.

As a consequence, there is a high likelihood that messages logged from the global destructors of other modules in the project will not end up being processed.

Another important thing to keep in mind is that the Debug_Init() function call is now mandatory, as it's used to process the command-line options for whether or not to enable the console, and where to store the logs. It is permissible to call DebugString() before Debug_Init() is invoked, e.g. from global constructors, but the messages will only be displayed and/or written to the log file / sent to the debugger after Debug_Init() had been invoked.

Please let me know if you disagree if some of the things I've done, or see room for improvement! I've tried my best to polish things up, but it's always possible that I've missed something.

[github-actions]

Development builds of 0e6ec23:

• opents-Win32-Debug-9abc29d
• opents-x64-Debug-9abc29d
• opents-Win32-Release-9abc29d
• opents-x64-Release-9abc29d

The links work without a GitHub account. Artifacts expire after 90 days, and this comment follows the latest successful build.

[ZivDero]

Hey! Overall looks solid, but found a few things:

1. std::chrono::current_zone is probably a no-go because apparently with MSVC it requires icu.dll shipped since Windows 10 1903. And while I personally do not care much for older Windows systems, losing support for them now over this would not fly well with others.
2. Where you use std::filesystem, please use the std::error_code versions, because the normal versions can throw exceptions.
3. You replaced the process ID with the thread ID for the file name tiebreaker, but under Linux/MacOS it can actually end up the same between two processes.
4. "Press any key" at console exit now holds the logger's lock and so any other thread that tries to write to the console on shutdown (e.g. audio) will get stuck waiting on it. You should release the lock before waiting for input.
5. You can now forget to call Debug_Init() which 5 tests actually do, and they keep buffering their logs indefinitely and unbound. I guess the minimal fix is to make them call it, too. Or dunno.
6. std::cout may be slower on Windows. Would be nice to measure it, if it actually is much slower then maybe keep WriteConsole on _WIN32.
7. A few minor things - missing <format> and <sstream> includes, bool requested that is never set to true, in some doc comments <param> is mistakenly inside the description itself.

And we're now onto 0.3.0 so that needs updating :P