Re: Explicitly disabling a feature

:) I just checked out the commit — works well with the new features as well. folks should feel free to try it out, and send comments — just update newt in develop. sterling On 2 Aug 2016, at 20:16, Christopher Collins wrote: Oops... I didn't mean to reply-all. Sorry for the spam...

Re: Explicitly disabling a feature

Oops... I didn't mean to reply-all. Sorry for the spam... Chris On Tue, Aug 02, 2016 at 08:16:08PM -0700, Christopher Collins wrote: > Hi Sterling, > > Just a heads up - this commit breaks the "newt test" command. The > problem is that there is no app when a package is being tested. The fix

Re: Explicitly disabling a feature

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

Re: Explicitly disabling a feature

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

Re: Explicitly disabling a feature

On 2 August 2016 at 01:48, Sterling Hughes 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

Re: Explicitly disabling a feature

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;

Re: Explicitly disabling a feature

On Mon, Aug 1, 2016 at 12:10 PM, Sterling Hughes wrote: > Yeah, that’s a good point. I’d probably add another feature to > libs/config which is CONFIG_SHELL, which allows you to turn off SHELL for > config, under the current system. > That doesn't really solve the problem;

Re: Explicitly disabling a feature

Yeah, that’s a good point. I’d probably add another feature to libs/config which is CONFIG_SHELL, which allows you to turn off SHELL for config, under the current system. Right now, features are global variables set across the entire compile, and recursively resolved. We could add a map,

Explicitly disabling a feature

Hi devs, Is there a way for a project to exclude a feature provided by a dependency? For example, I want to include libs/shell to reuse its code, but do not want other packages (say, libs/config) compiling in shell-dependent code. I could always skip declaring it as a dep and supply the right