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 <[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
> >>>
