some of these are ridiculous and so have been silenced. I'm a huge fan
of static code analysis but I have a hard time believing that writing
"0U" is a qualitative improvement over "0u".
I'm not sure that there is any value in continuing with a bad configuration
but be careful about changing the semantics of existing code. You never know
what else may depend upon it.
This was much worse than I thought. I had run clang-format at some point, but
apparently I subsequently made some non-compliant changes in pretty much every
file I touched.
I don't know how this didn't run before submitting the PR. CI tests are great!
The file-based signal sources were modified to not throw an exception on creation
but rather when connect() is called. The unit test was checking for an exception
upon construction.
The existing CMake logic is broken-ish; or rather log4cpp is broken-ish, and
this inhibits the use of C++17 std::filesystem.
All of the static libraries created are brittle; consider changing from
STATIC to OBJECT in the future?
also adds a base implementation that most signal sources should inherit from.
The gen_signal_source is inexplicably different (probably as a test fixture,
commonality was not valued).
Only the file_signal_source has been tested; all the sources are modified in the same
way, but we all know the only proof of correctness is testing.
The block factory was simplified a bit. Handling for legacy config files was pulled out
of the flowgraph; now when the "0" instance of a component (Foo0) is created, if there is
no config for it, then the legacy version (Foo) will be tried. This is different from
passing -1 for the item number (which is still supported). Theoretically, all existing
config files should still work.
From now on, new contributors do not have to sign the Contributor License Agreement (CLA) anymore. This has been replaced by the Developer's Certificate of Origin (DCO), which implies that contributed commits need to be signed, either automatically by git or by suffixing a 'Signed-off-by: Your Name your.email@example.com' line in the commit message(s) when doing a pull-request.
