Open rfairley opened 5 years ago
If we go with the makefile approach, an extension of that idea is to have a global config or ini file that the makefile sources where we can define all the default compiler options we want to use. Then all our compiler options could be cleanly listed and visible.
I like that idea. The ini file could store all our config for each component and for app, eliminating the need for SystemConf.h.
(pasted from comment in #175)
Since we want components to be reusable in other projects, components should not depend on SystemConf.h for configuration macros. Components should also be individually configurable, e.g. a separate
THREADED
symbol for each component (and probably a more specific name to avoid collision with other code that might useTHREADED
).We can deal with this in 3 ways:
Instead of a macro from SystemConf, the component should use a compiler symbol to configure different behavior (which would be defined using the makefile). The compiler symbols should have some identifier in the name to make it clear it's a component from our library and specific to that component- e.g.
UTRA_COMPONENT_MPU6050_USE_I2C_SILICON_BUG_FIX
Use a configuration file per component to set config macros, e.g.
MPU6050Conf.h
.Make some components private, and separate public components from private components by having something like a
Common/app/component
directory for the private components. The components can still be configured using macros fromSystemConf
in this case.I like option 1 as it means the makefile is the master configuration for how included components will be compiled, and it keeps the configuration separate for individual components. SystemConf would remain only to configure things in
Common/app
.To Reproduce Steps to reproduce the behavior:
Came up in #173 - unit tests should not have SystemConf included in the compiler chain