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
>

Reply via email to