-
-
Notifications
You must be signed in to change notification settings - Fork 40.6k
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
Introducing a flexible build environment, especially improving STM32 builds #16536
Conversation
I'd suggest putting this on hold to some degree until discussion occurs on #16534 -- if we go down a specific route it makes little sense making a whole bunch of changes only to find out that it's irrelevant after discussion. |
I modified the Currently, I am test building all keyboards with their default keymap, so that I can catch any errors. |
@tzarc Yes, but I find it easier to discuss, when you have some code to look at. In this PR I will continue implemeting things as a basis for discussion and improvement. |
Thank you for your contribution! |
Exempting this from stalebot processing -- we want to get something along these lines in, eventually. |
Description
This aims to fix #16534.
Improved
mcu_selection.mk
for STM32This PR introduces a separate
mcu_selecion_stm32.mk
, just for STM32 processors. It is loaded withinmcu_selection.mk
and requires much less manual work for adding support for new chips. Find it inbuilddefs/mcu_selection_stm32.mk
.Update all keyboards to specific processor models
I updated all affected boards (using STM32) with a specific processor variant.
For the processor variant, I selected the one, which is used as the default model in the current firmware, so everything builds just like before.
The new
ProcessorFactory
This PR introduces a new
ProcessorFactory
, which replaces the old lists of supported chips. It assembles the list of supported processors by itself when it is provided with the corresponding information. For that, it uses the additionalProcessor
class. Seelib/python/qmk/processors.py
.Building
I tested all boards with their default keymap with
all of them build fine. No errors were reported. See the build log here.
new_keyboard
CLIThe
new_keyboard
CLI was adjusted as well, now presenting a list of all supported processors and memory configuration suffixes:Output of 'qmk new-keyboard'
Further info
For the moment, I removed the check against
keyboard.jsonschema
and do all checking in Python directly. I find it sensible to only check for compatible processors in a single place.Types of Changes
Issues Fixed or Closed by This PR
Checklist