[riot-notifications] [RIOT-OS/RIOT] makefiles: add new target info-board-supported (#12187)

Gaëtan Harter notifications at github.com
Tue Sep 10 11:44:06 CEST 2019


Many small remarks.

The `0` and `1` in the code do nothing, on failure it returns `2` as it is a failed recipe.

<details><summary><code>man make section EXIT STATUS</code></summary>

```
EXIT STATUS
       GNU  make  exits with a status of zero if all makefiles were successfully parsed and no targets that were built failed.  A status
       of one will be returned if the -q flag was used and make determines that a target needs to be rebuilt.  A status of two  will  be
       returned if any errors were encountered.
```
</details>

```
BOARD=chronos make --no-print-directory  -C tests/unittests/ info-board-supported; echo $?
/home/harter/work/git/RIOT/makefiles/info-global.inc.mk:88: recipe for target 'info-board-supported' failed
make: *** [info-board-supported] Error 1
2
```

Using a `test -n "$(findstring ...)"` would do the same without the confusing wrong `0` and `1`.
I prefer using `findstring` when the first element should not be a pattern.

If keeping the implementation as a `global`, I would rather get rid of the `BOARD=none` it is a stupid handling as nothing ever used the `none`.
It could be replaced by a `PARSE_GLOBAL_GOALS ?= $(if $(filter $(GLOBAL_GOALS),$(MAKECMDGOALS)),1)`.

#### Caveat with the global

I know I also use the output of `info-boards-supported` for `compile_and_test_for_board.py` as it was the only reasonably simple solution at that time, but it is a different dependency parsing and error detection than the normal execution.

This must be fixed but there is still a long road to go https://github.com/RIOT-OS/RIOT/issues/9913

If an error would have been shown by usage it would have given more insight to help fixing this, so was also a bit on purpose :)


<details><summary>boards supported ignores 'CONFLICTING' features</summary>

```
BOARD=stm32f4discovery make --no-print-directory -C tests/warn_conflict/ info-board-supported; echo $?
0
```

But it still reports errors on compilation:

```
BOARD=stm32f4discovery make  --no-print-directory -C tests/warn_conflict/ QQ=@
The following features may conflict: periph_dac periph_spi
Rationale: On stm32f4discovery boards there are the same pins for the DAC and/or SPI_0.

EXPECT undesired behaviour!
Building application "tests_warn_conflict" for "stm32f4discovery" with MCU "stm32f4".

   text	   data	    bss	    dec	    hex	filename
   8728	    120	   2564	  11412	   2c94	/home/harter/work/git/RIOT/tests/warn_conflict/bin/stm32f4discovery/tests_warn_conflict.elf
```
</details>


<details><summary>boards supported ignores 'TOOLCHAIN' features</summary>

```
TOOLCHAIN=llvm make --no-print-directory -C tests/nordic_softdevice/ info-board-supported; echo $?
0
```

```
 TOOLCHAIN=llvm make --no-print-directory -C tests/nordic_softdevice/ QQ=@
The selected TOOLCHAIN=llvm is blacklisted: llvm


EXPECT ERRORS!


Building application "tests_nordic_softdevice" for "nrf52dk" with MCU "nrf52".

make[1]: Nothing to be done for 'prepare'.
```
</details>

So with this in mind, I question if it is not better to correctly handle it as a normal target as it is really needed instead of patching it again.

I started some code to factor the `WHITELIST/BLACKLIST` https://github.com/cladmi/RIOT/commits/pr/make/boards/more_variables , and a with all the refactoring done in https://github.com/RIOT-OS/RIOT/blob/master/Makefile.features we are not far away to have all the information.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/12187#issuecomment-529858944
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190910/76c1ce96/attachment-0001.htm>


More information about the notifications mailing list