-
-
Notifications
You must be signed in to change notification settings - Fork 8.2k
mimxrt/Makefile: Refactors Makefile. #8800
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
mimxrt/Makefile: Refactors Makefile. #8800
Conversation
Reworks grouping of Makefile variables and reorders variable values in alphabetic order.
Replaces preprocessor macro for SDRAM option form #ifdef to #if in order to allow always setting the define `MICROPY_HW_SDRAM_AVAIL` just with the appropriate value 0/1. This reduces one `if`in Makefile.
Removes separate `if` case in Makefile for setting SDCARD option define.
Reworks handling and configuration of different board flash types in makefile, linker scripts and board makefiles.
Reworks source file and compile flags selection for floating point support.
Thanks, this looks good. I'm just wondering about the last commit that "fixes formatting". Can this be squashed into earlier commits, or is it intended to be separate? Because it changes some |
It is a pleasure. You are right about the last commit. I will split it into two. The change in behaviour is intended though. That setting has to be (only) set by the board Makefile. |
Removes conditional assignment because respective variables should only be set in board makefiles. Hence no conditional assignment needed.
Fixes formatting in linker scripts for flash type conditionals.
ebb6774
to
5512c9f
Compare
I modified the previous commit and split it into two with descriptive commit message. Additionally I fixed your review findings. I have two unrelated questions. First of all, I know you have a lot of other more important things at hand but I still have a PR open for adding a bootloader for the mimxrt port (#8229). Is there any chance that this PR will be merged anytime soon or at all? I know that this is a big change which would require a lot of effort from your side. I really would like to see that PR merged so if you could give me any guidance on how I could make the change easier for you to review I would be thrilled. On the other hand if there is no realistic chance for it to be merged please let me know so I will not spend the effort to keep it up to date all the time. Secondly I used to rebase all the time for the PRs such that there is no merge commit present and then force pushed the chances. I am just wondering if you would be also ok when I would regularly merge the current main branch into my PRs to keep them up to date? |
I will review it soon.
No, merging makes it harder to rebase (sometimes). It's best to just leave it as-is. A rebase and force push is only needed by you if things change drastically on master, and usually I would ask you to do it. Otherwise you can just leave a PR as is once you open it. |
Add new board: Cytron EDU PICO
Refactors grouping of Makefile variables and reorders variable values in
alphabetic order.
Reworks handling of board specific options for SDRAM, SDCARD, flash, and floating point with modifications in the Makefile, linker scripts and board makefiles to simplify over all build scripts.
Signed-off-by: Philipp Ebensberger philipp.ebensberger@3bricks-software.de