-
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
Makefile.features: prerequisites for moving CPU/CPU_MODEL to boards/Makefile.features #11478
Conversation
#11480 is in, rebase. |
I will rewrite the too long commit message at the same time. |
1620272
to
883b50c
Compare
Github is showing the diff in the creation time order instead of |
Or in other words,
|
Better give the reference on Github: https://help.github.com/en/articles/why-are-my-commits-in-the-wrong-order
This is a personal interpretation. From the link given above, they just recommend not using git rebase
|
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 think this is a good change. I'm waiting for another review.
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.
Good stepping stone towards #11477, I have a minor comment to improve variable documentation.
@@ -8,7 +8,7 @@ export QUIET # The parameter to use whether to show verbose make | |||
export APPLICATION # The application, set in the Makefile which is run by the user. | |||
export APPLICATION_MODULE # The application module name. | |||
export BOARD # The board to compile the application for. | |||
export CPU # The CPU, set by the board's Makefile.include. | |||
export CPU # The CPU, set by the board's Makefile.features. |
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 like the comment specifying where CPU should be defined, it documents a little bit the build system variables. Could we do the same for CPU_MODEL?
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 do it now.
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.
Not sure moving CPU etc to Makefile.features. Seems like hack, noone would expect it there.
How to solve the issue from #9913 without it then ? Setting a new file seems like an overhead right now. |
Also, it would then need to be defined before |
I think it does make sense to have them defined in Makefile.features if you think of CPU as another feature provided by a board. How I understand this, a board is not only an MCU but an CPU (MPU), with different peripherals and connections to different drivers. IMO it would be more intuitive to think of the CPU as another feature which is then included when needed.
In #9913 @cladmi hinted it could make event more sense if they were defined in a completely different file. Although I agree with that, this seems like a sensible stepping stone towards dependencies resolution while still making sense semantically. It also makes sense in a bigger picture where you may have 1 board with multiple CPU units (e.g. usb-kw41z witch also has a k22). @kaspar030 what do you think? |
Another direction for the change, would be to change the definition by defining first the hierarchy that defines a board, in separate files: Board/board_common_1/board_common_2/board_common_3/cpu/cpu_common/cpu_common2. Then from this automatically know which Makefile.features/Makefile.dep/Makefile.include to use and they would not need to include each other anymore as they are automatically included from the hierarchy directories. I just know it is a really complicated change, with the currently many inconsistencies, and requires to basically have everything fixed before it can be changed. And am not sure I want to change it if we do not have It could be an upcoming step but I do not really trust me on doing the change in the current state. |
Though I am not sure about the ramifications of this (it seems like it will touch a lot of files) it does seem to make sense. The Makefile.features are what the board has, periphs and whatnot, I could see how a cpu is like a periph... |
7e119d1
to
1c87ce2
Compare
@kaspar030 have your comments been addressed? |
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 like this, also (as @MrKevinWeiss pointed out) putting CPU
and CPU_MODEL
into Makefile.features
together with Peripheral stuff makes more sense (to me) than to put it in (or leave in) Makefile.include
� (which to me is more a file referencing other Makefiles).
I'd say: please squash |
it seems like we have two acks now. @kaspar030 should we proceed? |
yup! |
@cladmi please squash! |
1c87ce2
to
82b3b2c
Compare
…deps Part of moving CPU/CPU_MODEL definition to Makefile.features to have it available before Makefile.include.
Describe the ongoing migration. Part of moving CPU/CPU_MODEL definition to Makefile.features to have it available before Makefile.include.
Part of moving CPU/CPU_MODEL definition to Makefile.features to have it available before Makefile.include.
Prepare for when boards define `CPU` in `BOARD/Makefile.features`. Include '$(RIOTCPU)/$(CPU)/Makefile.features' directly when it is defined. This will allow removing the file inclusion from the `BOARD/Makefile.features`. The board must then not include it directly. Transitional change to allow migrating part by parts. Part of moving CPU/CPU_MODEL definition to Makefile.features to have it available before Makefile.include.
Prepare for when boards define `CPU` in `BOARD/Makefile.features`. Include '$(RIOTCPU)/$(CPU)/Makefile.features' directly when it is defined. This will allow removing the file inclusion from the `BOARD/Makefile.dep`. The board must then not include it directly. Transitional change to allow migrating part by parts. Part of moving CPU/CPU_MODEL definition to Makefile.features to have it available before Makefile.include. This can currently trigger including two times the cpu/CPU/Makefile.dep but allows a by board complete migration.
82b3b2c
to
fecc9c1
Compare
Squashed and rebased. |
Thank you for the review and decision to move in this direction. As this is a major change, I will notify it on the mailing list. However as soft-feature-freeze is already there, I would not start any big migration before the release is done. @MrKevinWeiss |
Thanks |
Contribution description
This pull request introduce a new
Makefile.features
file and prepares for handlingCPU/CPU_MODEL
being defined inboards/Makefile.features
instead ofMakefile.include
.It is somehow the official start of the migration.
This is an API change and may need to be advertised on the mailing list.
Testing procedure
Currently this should have no difference as nothing is defining
CPU/CPU_MODEL
in the board.Testing may come more from testing #11477 directly (TODO too)
Reviewing procedure
Please look at the review commit by commit too and ask any question on each steps.
undefine
inmakefiles/info-global.inc.mk
ensure that no definition will leak between stepsCPU/Makefile.features
currently break some boards (boards removinghwrng
afterkinetis/Makefile.features
, so defining CPU for these ones require a fix.Issues/PRs references
Tracking: move CPU/CPU_MODEL to Makefile.features #11477
Tracking issue: Build dependencies - processing order issues #9913
Depends on
#11480