-
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
treewide: clean up architecture specific toolchain setup #15996
Conversation
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 one looks good, there are just two changes I would put in different commits. This is a nice cleanup and I don't expect any impact since thee include still happens after the CPU
one so any board/cpu specific configuration can still override the generic one.
@@ -9,6 +9,14 @@ config CPU_ARCH_XTENSA | |||
select HAS_ARCH_32BIT | |||
select HAS_ARCH_ESP | |||
|
|||
config CPU_ARCH_XTENSA_LX106 |
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 these changes should be In another commit.
CPU_ARCH = armv4t | ||
CPU_CORE = arm7tdmi_s | ||
CPU_ARCH := armv4t | ||
CPU_CORE := arm7tdmi_s |
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.
Do you mind putting these changes in its own commit, they are not really related to the whole PR. And you can add the argument for doing this to the commit message.
@@ -1,3 +1,5 @@ | |||
CPU_ARCH := risc-v |
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.
Same for this one, can you add to a commit where you say "adding missing arch or something like that", or fix missing arch and you can ad comment on the :=
change in that commit as well.
Makefile.include
Outdated
@@ -394,6 +394,9 @@ include $(BOARDDIR)/Makefile.include | |||
INCLUDES += -I$(RIOTCPU)/$(CPU)/include | |||
include $(RIOTCPU)/$(CPU)/Makefile.include | |||
|
|||
# include architecture specific settings | |||
include $(RIOTMAKE)/arch/$(CPU_ARCH).inc.mk |
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.
include $(RIOTMAKE)/arch/$(CPU_ARCH).inc.mk | |
-include $(RIOTMAKE)/arch/$(CPU_ARCH).inc.mk |
With this we can avoid the empty files I believe.
Done. And a rebase seems to also be needed due to a merge conflict. |
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.
ACK, lets see what the ci says.
Sorry @maribu I forgot to check the ci result and now this one needs a rebase :( |
This is where it is located for all other platforms, let's have this consistently.
This is where it is located for all other platforms, let's have this consistently.
Use xtensa-lx106 for the ES8266 and xtensa-lx6 for the ESP32, instead of xtensa for both. This is later needed to allow differentiating between those two for the toolchin selection.
Instead of having each CPU family including $(RIOTMAKE)/arch/<ARCH>.inc.mk, just include $(RIOTMAKE)/arch/$(CPU_ARCH).inc.mk at Makefile.include
Simple expansion is recommended by official documentation [1] for a multitude of reasons over recursive expansion, of which predictable behavior (and, thus, maintainability of Makefiles) and performance are the biggest arguments. [1]: https://www.gnu.org/software/make/manual/html_node/Flavors.html
Strange, |
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.
ACK
looks like mips is missing |
No, it worked fine prior to the XFA merge. The issue seems to be that the order of linker flags is slightly different with this PR for MIPS. All other arch but MIPS include I will investigate this later. I believe there is some value in having the toolchain, CFLAGS and LDFLAGS setup as consistent as possible between all archs, as this eases refactoring and maintaining stuff. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions. |
@maribu, ping :) |
This is the type of PRs that horribly break things in a way that Murdock won't catch it, e.g. by triggering a build system bug that ends up half of the test cases not being build anymore. I agree that I should get back to this PR and push it forward, but maybe it is better to wait for the next development cycle before I break everything :) |
@maribu Sorry for jumping into this discussion so late. To be honest, I would prefer to drop the changes for ESPs for now, as they conflict with PRs #17842, #17844, and the PR for ESP32S3 support that is hopefully coming in the next few days. In these PRs
Merging your changes now would cause a lot of conflicts when these very large PRs are rebased, and I would have to check everything again to make sure it still works. So I would prefer to clean it up later if it is still necessary. |
I currently have no time to push this PR. Let's get ESP32-C3 in first. I can rebase and adapt this afterwards when I have time. |
Contribution description
Architecture specific toolchain setup is done mostly in
makefiles/arch/<ARCH>.inc.mk
, except for ESP and ARM9. Those oddballs are changed to the common pattern for consistency.Secondly, each CPU family included the architecture specific settings on its. However, as the architecture was is already known once the features are resolved, one can simple include
$(RIOTMAKE)/arch/$(CPU_ARCH).inc.mk
directly in$(RIOTBASE)/Makefile.include
.Testing procedure
If the toolchains are not properly set up, Murdock will complain. In addition, it might make sense to pick one example application and board for each platform and confirm that binaries doesn't change.
Issues/PRs references
One step towards making #15993 possible without reordering the processing of
Makefile.dep
andMakefile.include
.