Create seperate targets/*.mk files: Add TPM1/TPM2/HOTP/Common/whiptail/fbwhiptail/tethering others.
Nobody has claimed this yet.
- Dominant language
- Makefile
- Stars
- 1.6k
- Forks
- 211
- Avg merge
- 4d 21h
- Merged PRs (30d)
- 6
Description
As the refactoring of qemu boards that was done under https://github.com/linuxboot/heads/pull/1642 showed for those boards to be used as reference, since they represent most of existing board flavors today, maintening them just makes no sense anymore.
The solution forward, as started already, is to have common goals mk files under targets dir, and for boards to just pick those targets into the board configurations, and where extensive documentation could then be inside of those target sub-Makefiles.
The qemu-coreboot* boards can easily be used as a base to do that forward.
Until then, when changes related to specific board configs, please compare your board to those reference boards to understand what makes what.
Ideally in the future, those sub-makefiles could also test things out prior of building a non-working board.
For example today, enabling tethering for a board without having the kernel config file adding those modules will fail at build time.
The Makefile could parse the Kconfig file, and tell which Kconfig options are missing, refusing to build the board. or even call internal helpers added to add those Kconfig options to the pointed config file for the developer to simply verify prior of commiting and pushing changes upstream.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read the qemu-coreboot* board configurations and the refactoring in PR 1642, then inspect the existing targets directory and board-specific Makefiles. Inventory the TPM1, TPM2, HOTP, Common, whiptail, fbwhiptail, and tethering groupings before defining the target files. Done means the common goals are separated and boards select them consistently, with any documented Kconfig prerequisites accounted for.
Written by the indexing model from the issue text.
Assessment
- Domain
- build-system
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100