OK - added:
pkg.feature_blacklist:
".*": SHELL
pkg.feature_whitelist:
".*newtmgr.*": SHELL
these two can be enabled in any of the top-level packages (app, bsp and
target.) where the key is the package name, and the value is the
feature name. if something is in the blacklist, it is ignored, unless
it is also in the whitelist.
i’ve also added defines by default for every feature that is enabled.
so if the SHELL feature is enabled, then FEATURE_SHELL is added to the
compiler line.
in the case above, the SHELL feature would be hidden from every package,
except for the newtmgr package, which would have the SHELL feature
enabled, and the FEATURE_SHELL define provided.
this is available in the “develop” branch of newt.
On 2 Aug 2016, at 11:26, Sterling Hughes wrote:
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
