Add back logger

[tanaya-mankad]

This branch adds back the Courier logger to be able to pass json reading errors back out to the calling library.
Some other minor changes to the generator code too, mostly formatting and cleanup.
This generator code still doesn't have a test build setup, so the C++ changes aren't tested for functionality yet, but I'd like to hold that to another separate branch.

[spahrenk]

It's not clear to me where the loggers should be set. The set_logger functions are not declared in the headers, so the alternative is to just assign them directly, i.e.,

  data_model::ashrae205_ns::logger = hpwh.get_courier();
  data_model::core_ns::logger = hpwh.get_courier();
  data_model::rsintegratedwaterheater_ns::logger = hpwh.get_courier();
  data_model::rstank_ns::logger = hpwh.get_courier();
  data_model::rscondenserwaterheatsource_ns::logger = hpwh.get_courier();
  data_model::rsresistancewaterheatsource_ns::logger = hpwh.get_courier();

Is this the intended use? It seems a bit awkward.
P.S.: If any of them aren't set, it gives a segmentation violation, e.g.,
Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)

P.P.S.: It looks like spelling courierr isused in load-object.h. courier is used everywere else.

[spahrenk]

Would it be possible to automically skip defining empty functions? For example:
void from_json(const nlohmann::json& j, Schema& x) { }

Can we add #include <core.h> to the include list of each of the object header files? It's used for statements like
core_ns::Metadata metadata;

core.h needs to have #include <ashrae205.h>

[spahrenk]

I added some comments based what I'm seeing in the generated code. Some may be addressed in other PRs.

[tanaya-mankad]

Would it be possible to automically skip defining empty functions? For example: void from_json(const nlohmann::json& j, Schema& x) { }

Can we add #include <core.h> to the include list of each of the object header files? It's used for statements like core_ns::Metadata metadata;

core.h needs to have #include <ashrae205.h>

Yes and yes! Can you write up the first one as a separate Issue? I'll address them in different branches so as not to make this into an omnibus branch. (The core.h I'm already working on in my current branch.)

[tanaya-mankad]

It's not clear to me where the loggers should be set. The set_logger functions are not declared in the headers, so the alternative is to just assign them directly, i.e.,

  data_model::ashrae205_ns::logger = hpwh.get_courier();
  data_model::core_ns::logger = hpwh.get_courier();
  data_model::rsintegratedwaterheater_ns::logger = hpwh.get_courier();
  data_model::rstank_ns::logger = hpwh.get_courier();
  data_model::rscondenserwaterheatsource_ns::logger = hpwh.get_courier();
  data_model::rsresistancewaterheatsource_ns::logger = hpwh.get_courier();

Is this the intended use? It seems a bit awkward. P.S.: If any of them aren't set, it gives a segmentation violation, e.g., Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)

P.P.S.: It looks like spelling courierr isused in load-object.h. courier is used everywere else.

Unfortunately, at the moment that is basically the way it's used. The design was to support the factory creation pattern we were using in libtk205. Each "root" class contained a static logger instance, which the code autogenerator could assume would be used in all the support structs that were populated through the root class. We can definitely add a cleaner interface for simple schema.

I'll fix the naming issue for this PR.