:)
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...
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
