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 > is really simple: > > diff --git a/newt/builder/build.go b/newt/builder/build.go > index 3d54f0e..383bb95 100644 > --- a/newt/builder/build.go > +++ b/newt/builder/build.go > @@ -373,16 +373,16 @@ func (b *Builder) PrepBuild() error { > if appPkg != nil { > appBpkg = b.Packages[appPkg] > if appBpkg == nil { > appBpkg = b.AddPackage(appPkg) > } > b.appPkg = appBpkg > - } > > - b.featureBlackList = append(b.featureBlackList, > appBpkg.FeatureBlackList()) > - b.featureWhiteList = append(b.featureWhiteList, > appBpkg.FeatureWhiteList()) > + b.featureBlackList = append(b.featureBlackList, > appBpkg.FeatureBlackList()) > + b.featureWhiteList = append(b.featureWhiteList, > appBpkg.FeatureWhiteList()) > + } > > I didn't want to commit the fix since you might still be working on > this. > > I like the feature, though :). > > Chris > > > On Tue, Aug 02, 2016 at 03:21:39PM -0700, Sterling Hughes wrote: > > 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 <sterl...@apache.org> > > >> 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 > > >>>