Rebrand Library OR Extract non-Arduino logging core into another library

[phillipjohnston]

I had this thought yesterday, because the core logic I used is general C++ and not tied to Arduino. I've created a repo for a C++ embedded logger to house some of the core code and generalize it. The goal is that the core library would live there, and the arduino-logging library would submodule it, provide arduino-specific logging strategies, examples, and support the library organizational structure.

There's a two problems I'm thinking about ways to address:

I like a more organized project structure, and Arduino enforces a top-level file set for libraries, or else things aren't properly discovered
I think I can solve this with wrapper headers, but I ran into some include problems earlier today, so I need to work out the kinks
There are C++14/C++17 features that I use in the original library that had to be stripped out for the Arduino ecosystem, I'm not sure how I want to manage that dichotomy

[phillipjohnston]

Thoughts from Kelley:

I share the question and concern. A couple of thoughts. Newer loggers would probably use the std library, streams, etc Guessing there is a big body of C/C++ projects now using new features yet, but wanting logging. Rather than trying to make one logging library satisfy every one, it might make more sense to divide the audience. No streams. vs streams. etc. Then add a stream version later for other systems. You'll get a lot of useful feedback along the way.

[phillipjohnston]

From Kelley:

Consider generalizing the project name for broader C++ use. The library is generic but just happens to support Arduino. (and doesn't use streams)

I think that generalizing the project is another worthwhile approach.

The only downsides with sticking to Arduino-support in the base class are:

1. I would pick a different organization scheme than the Arduino environment requires
2. I would use policy-based design in a general C++/embedded version
3. I'd use C++17 features

Maybe we have both, too. Maybe this is rebranded into a general library, and it's our C++11-only version that just so happens to support Arduino. Our full-octane version could be C++14/17 and up.