(accidently added some leftover test folders, fixing...)

I found the problem why the naming, features re-usage and definition did not fit me. The lack of clarity was hiding the problem. I think it is currently incorrectly using the feature concepts.

The arch definitions and the blacklisting are done on provided features, and not on used features which is for me wrong.

From my understanding:

FEATURES_PROVIDED are hardware (including toolchain) features that are available for this board. It can require having code to make them available to the application. In that case, it means first enabling this feature by having it put in FEATURES_USED, which currently happens only if it is mentioned in FEATURES_REQUIRED or FEATURES_OPTIONAL.

Then the build system only process them if they are in FEATURES_USED.
It was even reinforced when changing the FEATURES_CONFLICT handling: #8925 as there was no reason to care about disabled provided features.

In the current implementation these arch_% features will almost never be in FEATURES_REQUIRED and still be always enabled because of course, the architecture is 16bit.

If it is required to have this information available in the code, like for examples in tests where it would be easier to use a macro than a sizeof(int) == 2, it would somehow require re-exporting these enabled features. As done before #8292

However, it means only exporting used features, not the available but unused ones.

Also, if for any reason, some module needs to blacklist against another feature than arch_ it would complained about disabled features as in #8925.

Ideas

Re-using the concept of FEATURES is I think adapted here, but not as provided ones.
I would add these arch_ ones directly to a used/enabled features list, or a new adapted name and not in the provided list.

The problem is even more hidden because both feature blacklisting, which should be global to all features, and adding arch features was done in the same pr.

I found the problem why the naming, features re-usage and definition did not fit me. The lack of clarity was hiding the problem. I think it is currently incorrectly using the feature concepts.

I don't see a problem.

FEATURES_PROVIDED -> "the platform provides a feature"
FEATURES_REQUIRED -> "this feature must be provided"
FEATURES_OPTIONAL -> "this feature will be used if available"
FEATURES_USED -> "list of all required or optional and provided features"

The latter two are used for periph_* in order to select periph_% modules when appropriate.

This PR adds:

FEATURES_BLACKLIST -> "this feature must not be provided by the platform"

In order to re-use fiddly make loops, each feature in FEATURES_BLACKLIST gets added to FEATRUES_REQUIRED with prefixed "!" as "!<feature_name>".

The arch definitions and the blacklisting are done on provided features, and not on used features which is for me wrong.

Some features are provided and can lead to code linked in when used, some are "always there". It is a matter of definition.
We can argue about the naming, or the meaning, or definition, or personal feelings, or whatever, forever. Or we can add two lines of dokumentation and take a useful improvement.

@cladmi You issue seems to be rooted in the assumption that features should be exported to code. If we consider features a build-system only "feature", there is no issue, right?

My view is that the way it is implemented here, BLACKLISTED works perfectly with arch_ because of course they are always present.

But if for any reason, you want to do an app/library that should not work if, for example periph_pm is not included. Then the blacklisting as it is now would prevent using it if the board/cpu as pm support even if not activated and compiled.

What I was thinking maybe one of these solutions:

• iglobally add in the build system that arch_% are required, blacklisting could be done against FEATURES_USED.
• Define them in FEATURES_USED directly and adapt the required parts
• Add a new variable for this specific case FEATURES_INCLUDED or something they are provided and used without possibility to deactivate them.

Huh, why did I close this?

But if for any reason, you want to do an app/library that should not work if, for example periph_pm is not included. Then the blacklisting as it is now would prevent using it if the board/cpu as pm support even if not activated and compiled.

If an app should not work if periph_pm is not included, that turns into it should only work if it is included. Thus periph_pm should be a required feature.

If you meant, an app or library should only work if periph_pm is not included (even though it is available as a feature), then this is out of scope for features, and should be handled by the module system. periph_pm is both a module and a feature. If actually used, the feature turns into a used module.

If you meant, an app or library should only work if periph_pm is not included (even though it is available as a feature), then this is out of scope for features, and should be handled by the module system. periph_pm is both a module and a feature. If actually used, the feature turns into a used module.

As said, I personally understand that BLACKLIST should be applied to used features not on available ones, like FEATURES_CONFLICT.

As we have different understanding on the semantic, I would like to have other point of view on this. It is an API design, where there are subjective choices, so having other developers feedback could help.

I will also do a documentation PR to summarize what was said here on the existing FEATURES variables.

FEATURES_BLACKLIST_GLOBAL should also be part of info-build.

Sorry I think it is actually FEATURES_BLACKLIST here.

Sorry I think it is actually FEATURES_BLACKLIST here.

addressed

Thanks!