Implement a logging solution

[hellkite500]

Create a basic logging shim that mimics Python's basic logging API. Namely, a namespace logging containing the following functions:

• void debug(const char *)
• void info(const char *)
• void warning(const char *)
• void error(const char *)
• void critical(const char *)

(edit: Added const to each above)

Such that a global call such as logging::warning("bad"); can be called.

This should go in include/utilities and src/utilities, and the interface should be pure C, taking C strings as input... the idea being that this may be usable by C and Fortran BMI modules in the future. (A max string size such as 1024 should be declared in the header)

The initial backing implementation should send the strings to std::cerr. If NGEN_QUIET is set, then the implementations for debug, info, and warning should become empty.

Future work intended includes possibly emulating the "logger" object from Python, more sophisticated backing implementations, and isolation of the header for inclusion in BMI modules. and passing a logger struct as a byte array via set_value.

Original content:

This conversation has come about several times, especially in recent PR reviews. We have a need for logging semantics that allow various kinds/classifications of information to be output to configurable log locations. This issue is intended to track any suggestions, considerations, recommendations, and progress toward that goal. From #522 , @program-- mentioned https://github.com/gabime/spdlog as a possible utility to use.

[PhilMiller]

From previous experience, the logging facilities in AMReX and WarpX were top-notch for handling multi-process consolidation and the logic of distinguishing "warnings in initialization", "warnings during first time step", "warnings later in the run"

[PhilMiller]

Also, we should consider interoperability with at least Python code. If we have an opportunity to steer code being written/adapted in other languages toward a preferred solution, that would be great.

[mattw-nws]

Also, we should consider interoperability with at least Python code. If we have an opportunity to steer code being written/adapted in other languages toward a preferred solution, that would be great.

Yeah ideally we'd want to have a shared logging structure between ngen and BMI models in various languages (might or might not be what you were referring to--we may have Python code run in the framework that is not in a BMI module I suppose)... but I'm not sure how we can do that. It's going to be annoying not to be able to unify any messages that come from BMI modules with messages coming from the engine... but BMI provides basically no way to do that, and I don't see a good way. The only option I see is to have some facility that both ngen and a BMI module could include separately, and each use independent of the other with messages going to the same destination by co-incidence... there are many downsides there but I don't have a better idea yet.