Hi Jose,
for me it still makes sense to have commands to say "is it hardware
supported" and a different one for "the board have enough memory when
compiled in the reference environment".
The first one is a hard constraint and should never change (except by
adding hardware support implementation), so it is really boards supported.
The second one is a soft constraint, it can change if the RIOT version
string is not set to a fixed string like in CI and gets longer, you
change a compile flag, if your gcc version is different, if you compile
with DEVELHELP=1 or if you modify code in the main.c.
It is mainly an information for CI
So I would like to keep both.
There is already a trick to have access to the list of supported boards
by using the debug command `make
info-debug-variable-BOARD_INSUFFICIENT_MEMORY`.
A dedicated command could be added for this. I would even filter it with
`BOARDS` if the variable is set.
But adding also a summary command could be useful for your need.
In my usage when testing, I mainly need to know "is my board supported",
and then "has my board enough memory" and do not care about other boards
so I set `BOARDS=my_board` for the `info-boards-supported` target.
I may also add dedicated commands for this instead of checking if my
board is in the output.
Gaëtan
On 22.05.2018 11:52, Jose wrote:
Hello all,
I've been using the `make info-boards-supported` command for a RIOT
related project. I need to show all supported boards for an
application (examples, etc).
The problem I've found is the fact that `info-boards-supported` shows
boards tagged by BOARD_INSUFFICIENT_MEMORY (so, in theory they can be
compiled but strictly speaking they won't be supported by the board).
I know Murdock is currently using this command to compile all examples
(and prevent linking them if they don't fit in the board). Would make
sense to add another command that shows all boards that are
(compile+flash) supported? I somehow feels "info-boards-supported" is
misleading, but changing the name might be extra work since it's used
by Murdock.
Comments? ;)
Cheers,
José
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel