Open klardotsh opened 2 years ago
It would help a ton if the upstream image actually shipped a not broken image that locks away most of the storage that the user can't access, leading to... Literally this.
Hint to the person implementing this documentation: we also provide a compile target for mpy_cross:
$ du -sh kmk
488K kmk
$ make compile
$ du -sh .compiled/kmk
228K .compiled/kmk
Getting Nice!Nano working is in the docs 😝 .
I've thought of getting a Github Action to compile KMK to mpy and post a .zip for users, and even taking it a step further of getting KMK into the CircuitPython Community Bundle, so it can be installed with circup.
CircleCI or other would be better suited for getting compiles going again. We used to have that, but it broke for reasons I don't remember, and it's better than leaving github to own this project. If it can't move platforms at any time, we aren't making open source software, and we want this to remain fully open.
Generally agreed that we should take as few dependencies on GH as possible, however, we do already have precedent of using GHA: https://github.com/KMKfw/kmk_firmware/blob/master/.github/workflows/test.yml is our lone CI workflow right now.
Part two of the "Josh had to rebuild his keyboard" saga: the discovery that the KMK codebase is so big, it can't be copied in full to even a NiceNano (which, back in the day, was one of the biggest MCUs we supported - certainly a far cry from the Pyboards of yore). In fact, I had to do all sorts of wild stuff like remove comments from various source files and manually stitch together a minimum file structure to get the thing to fit. It occurs to me that such a "minimum viable product" document could be helpful to those trying to bring KMK up on other constrained systems. Here's what it took to get my user keymap (klardotsh/iris) booted - it's still not the truly minimum product, as I use things like media keys and splits and blah-blah-blah, but it's a starting point.