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: Bootutil robustness

> On Aug 1, 2016, at 3:34 PM, Simon Ratner wrote: > > On Mon, Aug 1, 2016 at 12:03 PM, marko kiiskila > wrote: > >> Hi Simon, >> >> thanks for taking a peek. >> >>> On Jul 30, 2016, at 3:01 PM, Simon Ratner wrote:

Re: Bootutil robustness

On Mon, Aug 1, 2016 at 12:03 PM, marko kiiskila wrote: > Hi Simon, > > thanks for taking a peek. > > > On Jul 30, 2016, at 3:01 PM, Simon Ratner wrote: > > > > Hi devs, > > > > I started poking at libs/bootutil, and have two questions: > > > > 1. > > >

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