-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc/doxygen: add build system doc page for BOARD, CPU, FEATURE #12473
Conversation
@cladmi if you can take a look and see if this makes sense with the global picture you had for these concepts/variables in the build system scope it would be much appreciated :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This summarize well what I had also understood of the RIOT build system for BOARD/CPU/FEATURES.
It describe the currently expected state. It is not always respected and still has flaws but at least gives a common explanation.
I had my dirty version in #10062 (comment)
This document does not explain "why" it is this way but keeping with this allows releasing it as reference.
I got stuck not writing a similar document because I wanted to have the why and ended up with nothing.
On features a lot more could be said with with the policy/dependency resolution that somehow explain why it is this way, the limitation, the future, but is a big task on its own so good to not include it in there.
Somehow, the fact that I only stayed in tracking issues tells me that there would have been good to have a place for documenting these earlier in the repository. To allow moving the still not entirely precise issues to the repository in a better formatted document. Not an RDM as it just representing what is supposed to be there and in a more loose format. It would also push to have documentation first for these things and prevent things that go against the documentation just because somebody wants it his way. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I llke this document, it makes things clearer with features. Maybe you could also add some words about: where features are provided (in Makefile.features), where features are required (in application Makefile or Makefile.dep) and eventually some words about the FEATURES_USED variable ?
FEATURES {#features} | ||
======== | ||
|
||
`FEATURES_PROVIDED` are hardware (including toolchain) features (e.g.:`periph_hwrng`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
`FEATURES_PROVIDED` are hardware (including toolchain) features (e.g.:`periph_hwrng`, | |
`FEATURES_PROVIDED` are available hardware (including toolchain) features (e.g.:`periph_hwrng`, |
======== | ||
|
||
`FEATURES_PROVIDED` are hardware (including toolchain) features (e.g.:`periph_hwrng`, | ||
`periph_uart`) that are available or characteristics (e.g:`arch_32bits`) of a board. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
`periph_uart`) that are available or characteristics (e.g:`arch_32bits`) of a board. | |
`periph_uart`) or characteristics (e.g:`arch_32bits`) of a board/cpu. |
`periph_uart`) that are available or characteristics (e.g:`arch_32bits`) of a board. | ||
|
||
Providing a `FEATURE` | ||
-------------------- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-------------------- | |
--------------------- |
-------------------- | ||
|
||
For a `FEATURE` to be provided by a `board` it must meet 2 criteria, and for | ||
`periph` and other `hw` it must follow the 3rd criteria. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is hw
?
-------------------- | ||
|
||
For a `FEATURE` to be provided by a `board` it must meet 2 criteria, and for | ||
`periph` and other `hw` it must follow the 3rd criteria. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
`periph` and other `hw` it must follow the 3rd criteria. | |
`periph` and other `hw` it must follow a 3rd criteria. |
CPU/CPU_MODEL {#cpu} | ||
====== | ||
|
||
`CPU` and `CPU_MODEL` refer to the `SOC` (system on a chip) or `MCU` (microcontroller) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SOC was already used earlier but not defined. I would move the definition when it's used the first time. Also no need to "highlight" it with backticks. Same for MCU. Maybe use italic ?
and the way each manufacturer groups there products. | ||
|
||
These variables allows declaring the `FEATURES` that the mcu/soc provides as well | ||
resolving dependencies. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resolving dependencies. | |
as resolving dependencies. |
BOARDS {#boards} | ||
====== | ||
|
||
In RIOT build-system terms a `BOARD` is a grouping of: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In RIOT build-system terms a `BOARD` is a grouping of: | |
In the RIOT build-system, the variable `BOARD` is a grouping of: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't agree with the need of mentioning variable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, but add a comma after terms
, this is more readable.
sensor/actuator, but it doesn't necessarily provide that `FEATURE`. | ||
|
||
e.g.: | ||
- `samr21-xpro` provides a `at86r233` radio as well as the necessary |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- `samr21-xpro` provides a `at86r233` radio as well as the necessary | |
- `samr21-xpro` provides a `at86rf233` radio as well as the necessary |
@aabadie addressed your typo comments and requested for more info in two commits. |
I still see unaddressed comments. Did you forget to push ? |
Damn I did, will address tomorrow |
c6b789d
to
692ae71
Compare
@aabadie rebased and now your comments are addressed please take a look. |
ping @aabadie |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All my comments are addressed and the document is now IMHO in a good shape.
ACK
Please fix the remaining whitespaces, you can squash directly. |
692ae71
to
e31c07d
Compare
@aabadie Maybe I should move this to the |
e31c07d
to
963ec79
Compare
Got ACK to do it |
I generated the doc locally and it looks nice. My ACK holds :) |
Contribution description
This PR is part of #8420 and tries to get to a definition of what a
BOARD
,CPU
andFEATURE
is. Having an agreement on this should help resolving discussion on #11676 and others about what aFEATURE
is and how it should be used. This should also help maintainability by having an agreement on the definition.Testing procedure
Do you agree with the definitions?
Does naming make sense?
Does the placing make sense?
Issues/PRs references
Part of #8420