The configuration process allows to set non-existing values, which is quite error prone IMO.
It's very easy to write etesian.latchupDistance instead of etesian.latchUpDistance.
It would be nice to error out whenever a configuration parameter does not exist.
At the moment, the configuration is set in several steps (from what I understand here):
Python caching in CfgCache, crlcore/python/helpers/overlay.py
Apply the configuration to the C++ object Cfg, hurricane/src/configuration/hurricane/configuration/Configuration.h
Get or create the parameters on a per-tool basis, such as in etesian/src/Configuration.cpp. The paths used here are needed for validation.
To implement some validation, I think we'd need to lose the dynamic nature of the configuration. This way we can know whether the parameters exist somewhere when we apply them.
Is it something other people would like? Is there some value to a purely dynamic configuration that I missed?
The configuration process allows to set non-existing values, which is quite error prone IMO. It's very easy to write
etesian.latchupDistanceinstead ofetesian.latchUpDistance. It would be nice to error out whenever a configuration parameter does not exist.At the moment, the configuration is set in several steps (from what I understand here):
CfgCache,crlcore/python/helpers/overlay.pyCfg,hurricane/src/configuration/hurricane/configuration/Configuration.hetesian/src/Configuration.cpp. The paths used here are needed for validation.To implement some validation, I think we'd need to lose the dynamic nature of the configuration. This way we can know whether the parameters exist somewhere when we apply them.
Is it something other people would like? Is there some value to a purely dynamic configuration that I missed?