OK, I’m going to start this.
One more thing I’ll be adding.
It’s a common case for features to be used to create defines by
setting cflags.
so, you define a feature “ADC_NRF52” and then you have a directive
like:
pkg.cflags.ADC_NRF52: -DADC_NRF52
I’m going to look at all created features, and automatically create a
set of defines for them, i.e.: ADC_NRF52 automatically creates the
-DFEATURE_ADC_NRF52 define at the compiler line.
Sterling
On 2 Aug 2016, at 2:36, Wayne Keenan wrote:
On 2 August 2016 at 01:48, Sterling Hughes <[email protected]>
wrote:
I had lots more here about managing feature dependencies in general,
but
ended up snipping it because it is a complex beast and I would need
to
give
it more thought. In the meantime, I think the most important
property for
maintainability is to blacklist globally and whitelist per package;
blacklisting individual packages doesn't scale with the number of
dependencies.
Makes sense to me. I think it will be easier/more understandable to
add a
suppress features configuration variable than a “-“ before it.
I’ll add a
blacklist, with the ability to globally blacklist a feature, and a
whitelist. The whitelist will take precedence over the blacklist.
I like this idea, and I'd like the Mynewt stats to be a feature that
can be
black listed.
I ended up #ifdef'ing out all the stats to conserve RAM on the
micro:bit
platform.
It seems to me that these should only be specified at at the target
or
application level, as digging through packages here seems insane in
terms
of figuring out what’s going on, so I’ll restrict that — unless
people
disagree?
I think supporting blacklisting or whitelisting at the BSP level would
be
useful, for example, a 'blacklist all stats' setting in any kind of
micro:bit BSP is pretty much mandatory with the 16kb RAM limit and a
micropython interpreter running user scripts :)
Sterling
