cmake: improved board handling for revisions #68702
Conversation
| OR (HWMv2 AND NOT EXISTS ${BOARD_DIR}/board.yml)) | ||
| message(WARNING "BOARD_DIR: ${BOARD_DIR} has been moved or deleted. " | ||
| "Trying to find new location." |
There was a problem hiding this comment.
Not a blocker, but we should also handle the case where this board.yml still exists, but ${BOARD} is no longer in it. Hence, we'd need to redo the full search to find the board if it was moved to a different yaml.
There was a problem hiding this comment.
Not a blocker, but we should also handle the case where this board.yml still exists, but ${BOARD} is no longer in it.
that is handle, but is handled inside list_boards.py.
So in case board is removed, then CMake will fail with a board not valid.
If board is renamed (and properly deprecated in deprecated.cmake, then the new board name will be used.
There was a problem hiding this comment.
I meant the case where the board has been moved, not removed or renamed. So far, this is caught if the cached ${BOARD_DIR}/board.yml doesn't exist, but imagine moving another board.yml in its place, with different boards.
There was a problem hiding this comment.
Should place a watch on that file for an update you mean? I think that's a reasonable request
There was a problem hiding this comment.
but imagine moving another board.yml in its place, with different boards.
so if board folder is named foo containing the board foo then you would move foo board to another place and instead move / update board.yml with the content of board bar without also renaming the board folder ?
Except for common names for qemu boards, then I don't see this as a very likely situation, although it shouldn't be hard to handle this use-case as should just use the board_list output failure, and re-run with no board dir arg.
There was a problem hiding this comment.
It's a real possibility that there is a folder containing multiple boards and one of those boards is removed entirely or moved somewhere else, thus the boards.yml file is updated, the old location for the board has changed. This is not some rare occurrence
There was a problem hiding this comment.
and one of those boards is removed entirely
Which is handled, cause you get an error stating the removed board does not exists.
moved somewhere else
and in this case the error of the non-existing board this is imprecise.
A user will need to do a pristine build to pickup the new location.
This is not some rare occurrence
Guess it depends on your definition of rare.
And it's not like it isn't handled, if you read above.
There was a problem hiding this comment.
Improved error message added for this situation.
tejlmand
requested review from
carlocaione,
povergoing,
lorc,
firscity,
sidcha,
erwango,
ABOSTM,
FRASTM,
yonsch,
fkokosinski,
kgugala,
stephanosio,
ibirnbaum,
carlescufi,
MulinChao,
ChiHuaL,
Mani-Sadhasivam,
mmahadevan108,
dleach02,
rerickson1,
simonguinot,
parthitce,
jackrosenthal,
nandojve,
ifyall and
npal-cy
as code owners
tejlmand
requested review from
vanti,
greg-leach,
LingaoM,
soburi and
avisconti
as code owners
tejlmand
force-pushed
the
hwmv2_boards_handling_revision
branch
from
27f2ea9 to
9f1f00f
Compare
tejlmand
force-pushed
the
hwmv2_boards_handling_revision
branch
from
9f1f00f to
1283216
Compare
tejlmand
force-pushed
the
hwmv2_boards_handling_revision
branch
from
1283216 to
288ddcf
Compare
|
Need rebase |
tejlmand
force-pushed
the
hwmv2_boards_handling_revision
branch
5 times, most recently
from
cb818b9 to
3062a4b
Compare
This commit improves board handling for boards in HWMv2. On a CMake rerun, then BOARD_DIR is passed to `list_boards.py` which is extended to take such parameter. This allows to run `list_boards.py` whenever CMake reruns without the penalty of searching for all board.yml files, as only the board.yml of the current BOARD_DIR is processed. This allows `list_boards.py` to be invoked and from there obtain list of valid revisions and board identifiers for further board validation. This removes the need for caching additional CMake variables related to the board identifier and revision and thereby remove the risk of settings becoming out of sync as only the board provided by user is needed. This work further ensure that use-cases described in zephyrproject-rtos#50536 is still supported. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
tejlmand
force-pushed
the
hwmv2_boards_handling_revision
branch
from
3062a4b to
acba025
Compare
This commit improves board handling for boards in HWMv2. On a CMake rerun, then BOARD_DIR is passed to
list_boards.pywhich is extended to take such parameter.This allows to run
list_boards.pywhenever CMake reruns without the penalty of searching for all board.yml files, as only the board.yml of the current BOARD_DIR is processed.This allows
list_boards.pyto be invoked and from there obtain list of valid revisions and board identifiers for further board validation.This removes the need for caching additional CMake variables related to the board identifier and revision and thereby remove the risk of settings becoming out of sync as only the board provided by user is needed.
This work further ensure that use-cases described in #50536 is still supported.