Create a base class for GPS, Galileo and BeiDou ephemeris, allowing to remove some duplicated code
Use BOOST_SERIALIZATION_NVP macro, less error prone than boost::serialization::make_nvp
Update .xsd files
This is not so cosmetic: Moved init() chores from connect() to the constructor for consistency with other implementations. Not relevant here since files are not processed in real-time, but is it common practice in other blocks to set everything needed (and get all the resources) in the constructor, before connect()
Moved the constructor code to the top of the file, also for consistency with other files. This is an opinionated practice, I know, since one could expect the same order than in the header file.
Improved comment formatting for Doxygen
Added and removed some blank lines to match the style of other files (two blank lines within method implementations, no two consecutive blank lines inside the method. Again opinionated, but for the sake of consistency.
Included the <tuple> library (include what you use)
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.
