On Mon, Aug 1, 2016 at 12:10 PM, Sterling Hughes <[email protected]>
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
>>
>
