You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Simon Ratner <si...@proxy.co> on 2016/08/01 18:53:03 UTC
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 compiler
flags manually, but wondering if there is a better way.
Cheers,
Simon
Re: Explicitly disabling a feature
Posted by Sterling Hughes <st...@apache.org>.
:)
I just checked out the commit \u2014 works well with the new features as
well. folks should feel free to try it out, and send comments \u2014 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\u2019ve 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 \u201cdevelop\u201d branch of newt.
>>>
>>>
>>> On 2 Aug 2016, at 11:26, Sterling Hughes wrote:
>>>
>>>> OK, I\u2019m going to start this.
>>>>
>>>> One more thing I\u2019ll be adding.
>>>>
>>>> It\u2019s a common case for features to be used to create defines by
>>>> setting cflags.
>>>>
>>>> so, you define a feature \u201cADC_NRF52\u201d and then you have a
>>>> directive
>>>> like:
>>>>
>>>> pkg.cflags.ADC_NRF52: -DADC_NRF52
>>>>
>>>> I\u2019m 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 <st...@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 \u201c-\u201c before
>>>>>> it.
>>>>>> I\u2019ll 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\u2019s going on, so I\u2019ll restrict that \u2014
>>>>>> 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
>>>>>>
Re: Explicitly disabling a feature
Posted by Christopher Collins <cc...@apache.org>.
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\u2019ve 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 \u201cdevelop\u201d branch of newt.
> >
> >
> > On 2 Aug 2016, at 11:26, Sterling Hughes wrote:
> >
> > > OK, I\u2019m going to start this.
> > >
> > > One more thing I\u2019ll be adding.
> > >
> > > It\u2019s a common case for features to be used to create defines by
> > > setting cflags.
> > >
> > > so, you define a feature \u201cADC_NRF52\u201d and then you have a directive
> > > like:
> > >
> > > pkg.cflags.ADC_NRF52: -DADC_NRF52
> > >
> > > I\u2019m 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 <st...@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 \u201c-\u201c before it.
> > >>> I\u2019ll 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\u2019s going on, so I\u2019ll restrict that \u2014
> > >>> 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
> > >>>
Re: Explicitly disabling a feature
Posted by Christopher Collins <cc...@apache.org>.
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\u2019ve 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 \u201cdevelop\u201d branch of newt.
>
>
> On 2 Aug 2016, at 11:26, Sterling Hughes wrote:
>
> > OK, I\u2019m going to start this.
> >
> > One more thing I\u2019ll be adding.
> >
> > It\u2019s a common case for features to be used to create defines by
> > setting cflags.
> >
> > so, you define a feature \u201cADC_NRF52\u201d and then you have a directive
> > like:
> >
> > pkg.cflags.ADC_NRF52: -DADC_NRF52
> >
> > I\u2019m 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 <st...@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 \u201c-\u201c before it.
> >>> I\u2019ll 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\u2019s going on, so I\u2019ll restrict that \u2014
> >>> 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
> >>>
Re: Explicitly disabling a feature
Posted by Sterling Hughes <st...@apache.org>.
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\u2019ve 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 \u201cdevelop\u201d branch of newt.
On 2 Aug 2016, at 11:26, Sterling Hughes wrote:
> OK, I\u2019m going to start this.
>
> One more thing I\u2019ll be adding.
>
> It\u2019s a common case for features to be used to create defines by
> setting cflags.
>
> so, you define a feature \u201cADC_NRF52\u201d and then you have a directive
> like:
>
> pkg.cflags.ADC_NRF52: -DADC_NRF52
>
> I\u2019m 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 <st...@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 \u201c-\u201c before it.
>>> I\u2019ll 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\u2019s going on, so I\u2019ll restrict that \u2014
>>> 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
>>>
Re: Explicitly disabling a feature
Posted by Sterling Hughes <st...@apache.org>.
OK, I\u2019m going to start this.
One more thing I\u2019ll be adding.
It\u2019s a common case for features to be used to create defines by
setting cflags.
so, you define a feature \u201cADC_NRF52\u201d and then you have a directive
like:
pkg.cflags.ADC_NRF52: -DADC_NRF52
I\u2019m 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 <st...@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 \u201c-\u201c before it.
>> I\u2019ll 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\u2019s going on, so I\u2019ll restrict that \u2014 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
>>
Re: Explicitly disabling a feature
Posted by Wayne Keenan <wa...@gmail.com>.
On 2 August 2016 at 01:48, Sterling Hughes <st...@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
>
Re: Explicitly disabling a feature
Posted by Sterling Hughes <st...@apache.org>.
>
>
> 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 \u201c-\u201c before it.
I\u2019ll add a blacklist, with the ability to globally blacklist a
feature, and a whitelist. The whitelist will take precedence over the
blacklist.
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\u2019s going on, so I\u2019ll restrict that \u2014
unless people disagree?
Sterling
Re: Explicitly disabling a feature
Posted by Simon Ratner <si...@proxy.co>.
On Mon, Aug 1, 2016 at 12:10 PM, Sterling Hughes <st...@apache.org>
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; I just picked one example of many,
consider newtmgr, nffs, fcb, etc, and the number of (feature x dependency)
permutations quickly grows.
Right now, features are global variables set across the entire compile, and
> recursively resolved. We could add a map, something like:
>
> pkg.supress_features:
> - “config”: “SHELL”
>
> that would allow you to exclude certain features for specific packages,
> and have this settable either in the target definition or the app. Does
> that work?
This still requires insider knowledge about each package that might use a
feature, as well as each package that might export one. If I don't want
anyone to use a feature, I have to suppress it for every dep and keep this
list updated as I add/remove dependencies. And if a dependency exports a
new feature, I have to add it to every list.
It would be good to at least have an option to suppress a feature at the
top level, e.g.:
pkg.features:
- -SHELL
Maybe with syntax that can be expanded to allow whitelisting specific
packages:
pkg.use_features:
- SHELL:
- "@apache-mynewt-core/sys/config"
vs:
pkg.use_features:
- SHELL: false ## or [ ]
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.
Cheers,
simon
On 1 Aug 2016, at 11:53, Simon Ratner wrote:
>
> 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 compiler
>> flags manually, but wondering if there is a better way.
>>
>> Cheers,
>> Simon
>>
>
Re: Explicitly disabling a feature
Posted by Sterling Hughes <st...@apache.org>.
Yeah, that\u2019s a good point. I\u2019d 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, something like:
pkg.supress_features:
- \u201cconfig\u201d: \u201cSHELL\u201d
that would allow you to exclude certain features for specific packages,
and have this settable either in the target definition or the app. Does
that work?
Sterling
On 1 Aug 2016, at 11:53, Simon Ratner wrote:
> 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
> compiler
> flags manually, but wondering if there is a better way.
>
> Cheers,
> Simon