Is there a reason for a centralized file? For me it would make more sense to add a number of groups in a board makefile or something else in the board specific directory?

Could the same effect be achieved by using FEATURES_PROVIDED?
Like FEATURES_PROVIDED += arch_cortexm wordsize_32bit cpu_fam_cm4

Having a centralized list may be more difficult to maintain when boards are added or removed, but easier to maintain if new groups are added.

besides maintaining a central list, it also goes against modularity, i.e., having boards, drivers, etc outside the RIOT core repo (in the future).

After some thought I'm with @bergzand and @gebart, and that it would be better to create those groups based on something that can be defined within the boards directory or configuration. Though I'm not sure if FEATURES_PROVIDED is the right place, as it will easily get (semantically) overloaded.

First: I am a big fan of this PR. In my opinion, it improves the situation by mainly enabling us to do things (that were either cumbersome or not possible before):

• vastly simplify black/whitelisting for applications, not only making their Makefiles better readable, but also removing the need for maintaining ALL the tests/applications every time we add/remove a board
• make a developers/maintainers life much nicer, by being able to selectively do buildtests, instead of always running the full make buildtest club

Regarding the actual implementation: I think whether using or central file or not depends on the answer of these questions:

• do we want it to be more easy to add/remove/modify groups, or to add/remove boards? The first case is much simpler with a central file (as otherwise potentially many different boards have to be touched).
• what are the performance implications? Is there a difference and how much is it?

Integrating a central file with external boards should be a straight forward process. I would propose something like

-include ${BOARD_GROUP_EXT}

in the groups file. This allows for defining some external groups somewhere (including external boards, or simply doing custom sub-groups useful for individual developers), and use it by building with

BOARD_GROUP_EXT=/home/foo/dev/bla/muh.mk

while muh.mk might contain something like

MCUGROUP.mine := samr21-xpro stm32f3discovery external_board_123
MCUGROUP.cortexm += external_board_123

Other remarks:

• I would vote strictly against using the FEATURES_PROVIDED var for this in any case, is it does have a different semantic (has vs is)
• I would prefer renaming the base var to BOARD_GROUP, as the semantics is around boards and not MCUs...
• IMHO the run-time check for completeness in not needed, but should be moved to a static test. This way we can ensure, that the group file stays always consistent in master (and we might even want elaborate checks...
• On top of the static checks, we could also add a script that can auto-create the groups file based on some predefined rules...

I would vote strictly against using the FEATURES_PROVIDED var for this in any case, is it does have a different semantic (has vs is)

+1

I would prefer renaming the base var to BOARD_GROUP, as the semantics is around boards and not MCUs...

+1

IMHO the run-time check for completeness in not needed, but should be moved to a static test. This way we can ensure, that the group file stays always consistent in master (and we might even want elaborate checks...

+1

On top of the static checks, we could also add a script that can auto-create the groups file based on some predefined rules...

Sounds like an idea. Then again, we don't add/remove boards that often. If any PR that does that fails CI tests if a board is not added/removed, I think we should be good.

besides maintaining a central list, it also goes against modularity, i.e., having boards, drivers, etc outside the RIOT core repo (in the future).

We could move the actual grouping into a file in $(RIOTBOARD). That way, should anyone provide a different RIOTBOARD folder, it is at least easily possible to override.

Is there a reason for a centralized file? For me it would make more sense to add a number of groups in a board makefile or something else in the board specific directory?

The main reason is that in order to spread this information over 100+ files, all those would need to be parsed. Apart from being slow (I'm assuming this), the grouping is very useful to not parse e.g., blacklisted board folders.

We could move the actual grouping into a file in $(RIOTBOARD). That way, should anyone provide a different RIOTBOARD folder, it is at least easily possible to override.

yap. But also having the possibility to 'extend' the board group file would enable us to (i) use custom, short-term groups (whatever a developer seems fit, but does not have any reason to be in master -> group of random boards that I have on my desk etc), and (ii) to combine external boards with the internal board path. So maybe do both?

• moved actual grouping into boards/
• added static test script
• removed dynamic test
• added support to global targets (try BOARDS=avr8 make buildtest)
• renamed from MCU* to BOARD_*

Having a centralized list may be more difficult to maintain when boards are added or removed, but easier to maintain if new groups are added.

Where do you see the difficulty? adding/removing boards would require to edit the list, but that doesn't happen that often, no?

besides maintaining a central list, it also goes against modularity, i.e., having boards, drivers, etc outside the RIOT core repo (in the future).

We currently allow RIOTBOARD to override the board directotry. This is still possible. Do you see other modularity concerns?

Having a centralized list may be more difficult to maintain when boards are added or removed, but easier to maintain if new groups are added.

Where do you see the difficulty? adding/removing boards would require to edit the list, but that doesn't happen that often, no?

To exaggerate a bit: Its like when you run a liqueur store and have to maintain a list with the names of all adults above (or the opposite, i.e., all kids below) 16 or 18 that are (not) allowed to buy alcohol instead of just checking ID cards for the persons age. Further, while you only specified a small number of groups (for now), it is easily imaginable that others will add on numerous lists to make arbitrary board selections, and to maintain/update those lists will be cumbersome in the long run.

Though I agree with @haukepetersen that FEATURES_PROVIDED is the wrong place to put such things. I also agree with the others that using a similar concept might be better then a multitude of centralised lists. For instance we might call it TAGS or LABELS and those would contain something like CPU architecture, i.e., mips, arm, ... or other stuff that describe them e.g, 8bit, 16bit, 32bit ... and so on. Btw. IMHO this PR mixes board and CPU characteristics, for instance BOARD_GROUP.8bit, in essence 8bit is not a characteristic of the board itself but of its CPU - though I agree the board inherits that from its CPU in a way.

I also want to raise another issue I see with this PR: its rather make specific. IIRC you @kaspar030 are/were looking into or testing alternatives to RIOTs build system currently based on Makefiles and make. Wouldn't it make sense to implement such grouping features -- to be clear: I agree they are useful, I'm sceptical about the approach taken for implementation here -- independent of any build system, e.g. by using JSON or YAML to describe CPUs, boards, and so on - maybe a bit similar to what you proposed for the testrunner /testsuite in #7258?

Its like when you run a liqueur store and have to maintain a list with the names of all adults above (or the opposite, i.e., all kids below) 16 or 18 that are (not) allowed to buy alcohol instead of just checking ID cards for the persons age

Sticking with this analogy: if a customer comes to the counter and wants to buy a bottle of gin, it is indeed quite easy to check his/her/its ID to figure out if the person is allowed to do so. But in the use case presented here, we have a different scenario: we want to get a list of all persons who like gin, or who are over/under 18. In this case, it is much simpler and faster, to look a a list we might have in the store instead of calling every single person!

Analogy aside: as I wrote before, the key point here is the performance aspect, so can we/do we want to cope with the drawback of having to parse a (potentially large) number of files instead of a single file? And is the maintenance of a central group file really soo bad, considering the use of wildcards (nucleo%)?

From what I understand from the source:

• "BOARD_GROUP.name" are set of boards, currently by cpu arch, by cpu bit width
• Adding a new board, simply says to add the board in the correct group (sorted alphabetically, so easy to merge multiple sources)
• When setting BLACKLIST, boards groups can be used by using deferred assignment as they will be defined later.
• ALL_BOARDS is set by using all BOARD_GROUP.name

So the use is mainly for CI and not users, because you cannot do specific application depending on a board group.

How I understand it:

The information that is now used for grouping looks like a specific value for a property.
So a group is the result of "all boards whose arch is armv7a" or "all boards whose cpu is 32b"

And in that sense, it is similar to FEATURE_PROVIDED but with pre-calculated query results for, maybe, performance reasons.

Tell me if I am wrong, as I only rely on code and not documentation.

And is the maintenance of a central group file really soo bad, considering the use of wildcards (nucleo%)?

Also, there are currently many "central" lists like

BOARD_BLACKLIST := arduino-uno arduino-duemilanove arduino-mega2560 chronos \
                                      msb-430 msb-430h telosb wsn430-v1_3b wsn430-v1_4 z1

They would become much shorter and more maintainable.

Using FEATURES_PROVIDED for board grouping would, need more logic for the blacklist case, as in, how do we blacklist a board that does provide a feature.

Using the central file might not be optimal in terms of maintainability, but adding the decentralized solution to our make system seems way more work to me, and it is not clear that the performance overhead would be acceptable.

I suggest we go with this PR's concept for now and change to something not using a centralized file as soon as that has been done.
Any adapted black/whitelists will probably work unchanged with a decentraliced solution.
And this PR makes sure, through it's static test, that the central file at least knows about every board.

And in that sense, it is similar to FEATURE_PROVIDED but with pre-calculated query results for, maybe, performance reasons.

Tell me if I am wrong, as I only rely on code and not documentation.

You're right.

Closed in favour of #9081.