what do you think about this approach to get rid of some boards list?
@cladmi your comments are very welcomed.

I think the approach is not good (I have a PR that can do it in a nicer way, e.g. without having to modify all boards). I'll comment why later (I'm AFK for the moment).

@aabadie take your time. If you're referring to your PR #11676 then this looks very similar to my approach taken here, just netif instead of ccn-lite. Hence, I'm a bit puzzled why you think this approach is not good?

What can be improved here is, to link the feature ccn-lite with the package and thus get rid of the USE_PKG here and move it to Makefile.dep (or so).

But before adding this I would like to get opinions if this is the way to go at all.

This somehow seems to me a reverse logic. Why is a network stack a feature provided by a board?

mhm, yeah the naming ... but we use the same mechanism for feature cpp. In general, the idea is to replace the boards list and use an already in place mechanism of the RIOT build system instead. We could introduce a better naming for this, but the mechanism would be the same as for FEATURES.

For C++ it somewhat makes sense, as architectural requirements need to be fullfilled by the MCU to run C++. But for CCN-lite it isn't an archictectural requirement that adds the board to the whitelist, isn't it? If it is, maybe this should be a dependency of CCN-lite, which in turn is provided by the board. E.g. (I don't know if this is actually the case here: FEATURE_PROVIDED += malloc.

This somehow seems to me a reverse logic. Why is a network stack a feature provided by a board?

It would indeed be better to have the network stack provide that feature. But currently the build system is not up to the task. (@cladmi: Maybe you have an idea how modules could provide features? So that checking if required features are indeed provide takes places after the dependencies of used modules have resolved.)

Back to topic: This is not be the ultimate and final solution. But boards are pretty static, while applications are moving targets. Also, out of tree applications could also use the features, while they would have to manually keep up with the black and white lists.

@miri64 I agree this is not optimal, but to reiterate: the feature mechanism is ready-to-use and can immediately help to get rid of the BOARDS_{WHITE|BLACK}LIST.

For instance, we have 2 LUA examples with BOARD_BLACKLIST using the feature concept we can remove this lists and add FEATURES_REQUIRED += lua to both examples (and add feature lua to boards that are compatible).

This helps to remove clutter from the app Makefile and keeping the lists up to date in all applications. This makes it also easier when adding a new board, instead of updating numerous lists in many applications and tests, we just add the feature to the board (or not, if not supported). So its basically one-line per board in its Makefile.features instead of adding the board to the respective list (white|black) in numerous applications and tests.

I think you misunderstood me. I did not say using features is a bad idea nor that the naming is misplaced. I just think, we should rather name the features the board provides that others don't so that compilation or a working application are ensured instead of using the brute force approach of just putting the module there. Just one example: Most applications involving ethos don't work on some boards because they use Segger RTT rather than UART to communicate with the host machine and this is why they are blacklisted. So the FEATURE_PROVIDED by the board to remove those blacklist entries wouldn't be ethos, but e.g. stdio_uart (edit: and ethos would in turn have this feature as a dependency).

I think #9081 is a good example of what I was talking about.

@miri64 ah okay, now I get what you mean.

It might be sometimes difficult to find the features that cover all boards in a whitelist (or blacklist). Anyway, I'll look into that and add changes here.

It might be sometimes difficult to find the features that cover all boards in a whitelist (or blacklist). Anyway, I'll look into that and add changes here.

In that case we can discuss this, but for ccn-lite specifically, I don't really expect that.

So the FEATURE_PROVIDED by the board to remove those blacklist entries wouldn't be ethos, but e.g. stdio_uart (edit: and ethos would in turn have this feature as a dependency).

This is what I think I should do with #12304.

Regarding providing ccn-lite as a feature, this is totally non sense to me. In fact, any board with a radio should be able to run ccn-lite. ccn-lite is not a feature, it's a library, a module. To knowi if ccn-lite can be built for a given board, the main criteria is rather: does the board provide an interface (e.g. netif) or not ?

This was the initial goal of #11676, where the first versions were providing the netif feature at the board level. But after some thoughts, I realized it was a lot of code duplication for something that is, in fact, provided by the radio drivers implementing the netif/netdev interface.
Now I'm very convinced that the netif feature should be provided by radio drivers themselves. What is missing is a consensus on how this should be managed by the build system.

closing this needs a different approach