Option to disable (or enable) verbose/debug output about vkbasalt

[mcoffin]

So, I was thinking about taking a pass at this, and cursory google'ing of "C++ logging frameworks" yielded quite mixed results.

Old suggestions seemed to indicate log4cxx as a viable option, but the project seems largely abandoned.

Just doing a lightweight custom solution with either environment variables or compile-time pre-processor directives is an option, and seemed preferrable until I thought about the users of this project.

Users here actually likely want to be able to configure logging backends to back with a file (to separate output from the actual application output), while still having the option to go straight to stdout if that is what they prefer.

I'd be willing to put in the grunt work to tackle this, after we have a discussion on what logging framework/strategy is likely best going forward.

I've seen Apache Mesos's usage of glog, and while it's not perfect, it might be good enough for our use case.

Regardless, especially if you're primarily a C++ developer (I've been more Rust-focused in this space when possible), particularly for a library used by other applications, please chime in on your experiences with logging frameworks, and what you think might offer a good solution going forward.

To be honest, given the non-transparent-in-logs way that vulkan-icd-loader loads layers, I think that adding a dynamically-linked logging framework dependency is probably not the way to go. We don't want users who don't have a dynamic library available invisibly having nothing happen with the layer, since that's a bad experience.

In summary, my opinion is that a good logging framework/strategy solution here would meet the following criteria.

1. Ability to control "levels" of logging
2. Able to be configured via either vkBasalt.conf or environment variables, without another config file for the logging framework.
3. Statically linked, or at least in some way not requiring any runtime dependencies to be installed by the end user.
4. (more optional than other things on this list) Ability to configure different logging backends, to either dump to a file, or journalctl logs from systemd, or just plain stdout, etc.
5. (even more optional) Ability to have 0-cost logging levels at compile time. (i.e., if the user doesn't compile with debug or trace log levels, then those log messages should be 0-cost at runtime. While this usually won't matter, it could impact performance for workloads that make heavier or more frequent use of the functions interrupted by the vkbasalt layer that output logging information.

Let me know your thoughts, and I'll give this one a go, despite it being a lot of boring find/replace boilerplate work.

[mcoffin]

Further investigation yielded that gabime/spdlog might be a good option as well.

[DadSchoorse]

https://github.com/DadSchoorse/vkBasalt#debug-output