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