Refactor the CLI so it can be used by other libraries

[baconpaul]

The CLI is a useful tool and if you are developing external nodes you want to use it. This commit makes it so that is easier.

It takes the following approach

1. Split the CLI into a libcli which exports a function previously known as main with an added callback, and a new executable which just calls that
2. Have the new function have a registerCallback which you can pass
3. Add cmake targets for the library only
4. Add a couple of inlines which avoid duplicated symbols from headers so you can get this all to work

As a result, a library can write a 'test' cli which uses the entire current CLI with one function injected with a couple of lines of cmake, and the internal CLI still works just with one extra initialization time call to an empty function.

[baconpaul]

OK if you want to see how this works look at

https://github.com/baconpaul/sst-elementary-bindings

where i build a custom CLI which adds my callbacks (and works!)

to build you need to check out and submodule that but then you need to pull this PR branch for the libs/elementary submodule.

But the key is: sst-elementary-bindings makes its own CLI application, but the only code I needed was

#include "CLIEngine.h"
#include "sst-elementary-bindings.h"

int main(int argc, char **argv)
{
    return ElementaryCLIMain(argc, argv, [](auto &a){
        sst::elementary::registerSSTElementaryBindings<float>(a);
    });
}

[baconpaul]

Oh I want to make a small cmake change. The cli library should be static

[baconpaul]

Alright pushed up that change! Let me know what you think

With this I can definitely pull in the filters and wave shapers from surge easily.

[nick-thompson]

Yea love this idea, and it's really a clean change to enable this flexibility for devs.

One high level thought: do you think it'd be worth nudging the Benchmark functionality into the same structure while we're here? The benchmark cli tool is the same thing but instead of writing to the audio driver it loops the Runtime::process step on the main thread so you can profile it. Or do you think it's sufficient just to have the realtime output?

[baconpaul]

To your bigger question : now I look at it yes it certainly looks like benchmark should get the same change! I hadn’t even read that code tbh. But it indeed seems symmetric.

[nick-thompson]

Hey @baconpaul, just pushed some changes to fix up the rest of the benchmark split as we chatted about in Discord, and I tweaked a bit else to satisfy my own aggressive nitpicking, I hope that's ok! Let me know if this looks good on your end.

[nick-thompson]

🙌 thank you @baconpaul! Elementary's first public contributor :D