Add initial GNU make Makefile #91
Conversation
Test jobs for commit 467dcab |
|
Since this is non-draft, is this ready for review? |
|
Yes, please! |
lool
left a comment
lool
left a comment
There was a problem hiding this comment.
Could we do the flash part and update the README+workflow? Otherwise we have a Makefile that is unused and only does part of the job we care about
See my commit message - I agree that we need to do this, but I'm breaking this up into steps. Otherwise I have to implement all build options across README.md and all workflows all at once, and that's too big for a single PR. |
|
Ready for re-review please. Sorry I'm not used to working inside GitHub regularly. Next time I'll try to submit all comments together. |
We have a fairly complicated build process in qcom-deb-images, as evidenced by the current README.md. Giving developers a one-command build instead means: 1. Simplified instructions for developers, or in other words, moving instructions for manual entry from README.md into automated invocation via the build system. 2. Automated dependency/rebuild tracking, reducing the instances where a full rebuild is required, or the easiest option, during development iteration. 3. Building only what is necessary for a given target. 4. The opportunity to move towards running CI before submission in a PR, rather than CI being entirely defined inside .github/workflows/ and therefore inaccessible for running locally. This is too complex to attempt all at once. Instead I'm doing it in multiple small steps, and this is the first step. Overall, my plan is: 1. Introduce a basic Makefile that works. 2. Per item, implement in the Makefile what CI requires that is already implemented in .github/workflows/. 3. Per item, replace complex build invocation steps made directly from .github/workflows/ with calls to the Makefile instead. 4. Once the elements covered by README.md are all covered, I'll update the instructions to use the Makefile instead. Note that CI for the Makefile should therefore not be necessary to implement directly; it'll happen step by step as CI is moved into it through step 3 above. If there are gaps in CI coverage that the Makefile does cover, then we can implement those as separate CI items to call from .github/workflows/ as we wish. In time, this should make .github/workflows/ simpler, and encode our knowledge of how to invoke the various tools (including debos) into the source tree itself, rather than via manual instructions in README.md that are also duplicated in .github/workflows/ Signed-off-by: Robie Basak <[email protected]>
|
Looks good, could you just test that kvm works as to make sure it's not broken for people that have it? |
Test jobs for commit b0892e7 |
|
This is ready to land except for testing KVM. I'm just waiting on approval for full access to an arm64 machine with KVM :) |
|
KVM verified, so this can land now. |
2 participants
We have a fairly complicated build process in qcom-deb-images, as evidenced by the current README.md. Giving developers a one-command build instead means:
Simplified instructions for developers, or in other words, moving instructions for manual entry from README.md into automated invocation via the build system.
Automated dependency/rebuild tracking, reducing the instances where a full rebuild is required, or the easiest option, during development iteration.
Building only what is necessary for a given target.
The opportunity to move towards running CI before submission in a PR, rather than CI being entirely defined inside .github/workflows/ and therefore inaccessible for running locally.
This is too complex to attempt all at once. Instead I'm doing it in multiple small steps, and this is the first step. Overall, my plan is:
Introduce a basic Makefile that works.
Per item, implement in the Makefile what CI requires that is already implemented in .github/workflows/.
Per item, replace complex build invocation steps made directly from .github/workflows/ with calls to the Makefile instead.
Once the elements covered by README.md are all covered, I'll update the instructions to use the Makefile instead.
Note that CI for the Makefile should therefore not be necessary to implement directly; it'll happen step by step as CI is moved into it through step 3 above. If there are gaps in CI coverage that the Makefile does cover, then we can implement those as separate CI items to call from .github/workflows/ as we wish.
In time, this should make .github/workflows/ simpler, and encode our knowledge of how to invoke the various tools (including debos) into the source tree itself, rather than via manual instructions in README.md that are also duplicated in .github/workflows/