Skip to content
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

Merged
merged 5 commits into from
Jul 1, 2019

Conversation

cladmi
Copy link
Contributor

@cladmi cladmi commented May 2, 2019

Contribution description

This pull request introduce a new Makefile.features file and prepares for handling CPU/CPU_MODEL being defined in boards/Makefile.features instead of Makefile.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.

  • The undefine in makefiles/info-global.inc.mk ensure that no definition will leak between steps
  • The inclusion of CPU/Makefile.features currently break some boards (boards removing hwrng after kinetis/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

@cladmi cladmi added Area: build system Area: Build system Process: API change Integration Process: PR contains or issue proposes an API change. Should be handled with care. CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Area: boards Area: Board ports labels May 2, 2019
@cladmi cladmi added this to the Release 2019.07 milestone May 2, 2019
@cladmi cladmi added the State: waiting for other PR State: The PR requires another PR to be merged first label May 2, 2019
@cladmi cladmi requested a review from gschorcht May 2, 2019 17:39
@jcarrano
Copy link
Contributor

jcarrano commented May 3, 2019

#11480 is in, rebase.

@cladmi
Copy link
Contributor Author

cladmi commented May 3, 2019

I will rewrite the too long commit message at the same time.

@cladmi cladmi removed the State: waiting for other PR State: The PR requires another PR to be merged first label May 3, 2019
@cladmi cladmi force-pushed the pr/make/makefile_features branch from 1620272 to 883b50c Compare May 3, 2019 13:26
@cladmi
Copy link
Contributor Author

cladmi commented May 3, 2019

Github is showing the diff in the creation time order instead of commit order

@cladmi cladmi added the Process: needs >1 ACK Integration Process: This PR requires more than one ACK label May 3, 2019
@jcarrano
Copy link
Contributor

jcarrano commented May 6, 2019

GitHub emphasizes Pull Requests as a space for discussion. All aspects of it--comments, references, and commits--are represented in a chronological order. Rewriting your Git commit history while performing rebases alters the space-time continuum, which means that commits may not be represented the way you expect them to in the GitHub interface.

Or in other words,

GitHub emphasizes it's own vision of how you should work and you are expected to follow it because they know better (I mean they are GitHub).

@aabadie
Copy link
Contributor

aabadie commented May 6, 2019

Better give the reference on Github: https://help.github.com/en/articles/why-are-my-commits-in-the-wrong-order

Or in other words,

This is a personal interpretation. From the link given above, they just recommend not using git rebase

If you always want to see commits in order, we recommend not using git rebase. However, rest assured that nothing is broken when you see things outside of a chronological order!

Copy link
Contributor

@jcarrano jcarrano left a 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.

Copy link
Contributor

@fjmolinas fjmolinas left a 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.
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do it now.

Copy link
Contributor

@kaspar030 kaspar030 left a 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.

@cladmi
Copy link
Contributor Author

cladmi commented May 6, 2019

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.

@cladmi
Copy link
Contributor Author

cladmi commented May 6, 2019

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 Makefile.features.

@fjmolinas
Copy link
Contributor

Not sure moving CPU etc to Makefile.features. Seems like hack, no one would expect it there.

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.

How to solve the issue from #9913 without it then ? Setting a new file seems like an overhead right now.

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?

@cladmi
Copy link
Contributor Author

cladmi commented May 6, 2019

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 Makefile.dep parsed before Makefile.include as the current behavior is problematic and could really introduce bugs.

It could be an upcoming step but I do not really trust me on doing the change in the current state.

@MrKevinWeiss
Copy link
Contributor

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...
Currently it is in the Makefile.include, which looks like it is responsible for how to flash, debug and term, all things that are not related to building but to connecting. I could see why it may not belong there.

@cladmi cladmi force-pushed the pr/make/makefile_features branch from 7e119d1 to 1c87ce2 Compare June 14, 2019 17:02
@MrKevinWeiss
Copy link
Contributor

@kaspar030 have your comments been addressed?

Copy link
Member

@smlng smlng left a 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).

@smlng
Copy link
Member

smlng commented Jun 28, 2019

I'd say: please squash

@MrKevinWeiss
Copy link
Contributor

it seems like we have two acks now. @kaspar030 should we proceed?

@kaspar030
Copy link
Contributor

@kaspar030 should we proceed?

yup!

@MrKevinWeiss
Copy link
Contributor

@cladmi please squash!

@cladmi cladmi force-pushed the pr/make/makefile_features branch from 1c87ce2 to 82b3b2c Compare July 1, 2019 15:23
cladmi added 5 commits July 1, 2019 17:23
…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.
@cladmi cladmi force-pushed the pr/make/makefile_features branch from 82b3b2c to fecc9c1 Compare July 1, 2019 15:23
@cladmi
Copy link
Contributor Author

cladmi commented Jul 1, 2019

Squashed and rebased.

@MrKevinWeiss MrKevinWeiss merged commit 9b4c01c into RIOT-OS:master Jul 1, 2019
@cladmi cladmi deleted the pr/make/makefile_features branch July 1, 2019 16:09
@cladmi
Copy link
Contributor Author

cladmi commented Jul 1, 2019

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

@MrKevinWeiss
Copy link
Contributor

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: boards Area: Board ports Area: build system Area: Build system CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Process: API change Integration Process: PR contains or issue proposes an API change. Should be handled with care. Process: needs >1 ACK Integration Process: This PR requires more than one ACK
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants