Change lib8tion library to be usable in user keymaps

[alecgeatches]

This PR moves a header-defined constant in the lib8tion library to an implementation file so that FastLED library functions can be included and used in user code. Using the FastLED functions in code outside of rgb_matrix.c was previously not possible due to the header-defined b_m16_interleave array. See #5597:

[@alecgeatches: ] I'm having an issue using any of the lib8tion functions in my custom code. If I try adding #include "lib/lib8tion/lib8tion.h" to my keymap file, I get a linker error:

$ make ergodox_ez:alecg
QMK Firmware 0.6.328
Making ergodox_ez with keymap alecg

# ...

 [OK]
Linking: .build/ergodox_ez_alecg.elf                                                                [ERRORS]
 |
 | .build/obj_ergodox_ez_alecg/quantum/rgb_matrix.o:(.rodata.b_m16_interleave+0x0): multiple definition of `b_m16_interleave'
 | .build/obj_ergodox_ez_alecg/keyboards/ergodox_ez/keymaps/alecg/keymap.o:(.rodata.b_m16_interleave+0x0): first defined here
 | collect2: error: ld returned 1 exit status
 |
tmk_core/rules.mk:290: recipe for target '.build/ergodox_ez_alecg.elf' failed
make[1]: *** [.build/ergodox_ez_alecg.elf] Error 1
Make finished with errors
Makefile:535: recipe for target 'ergodox_ez:alecg' failed
make: *** [ergodox_ez:alecg] Error 1

From what I understand, this is due to the b_m16_interleave constant being defined in the header file lib/lib8tion/trig8.h included from lib8tion.h. Since the constant is defined in the header file, including the same header from anywhere else causes a linker error becuase it's already included in quantum/rgb_matrix.c.

[@pelrun: ] Simplest fix is to add 'static' to the definition of b_m16_interleave, which will remove any external visibility. A more complete fix will be to move the definition to a C file and include it in the build, but it's not necessary unless you're desperate to save a dozen bytes of ram or flash.

This PR takes the second approach since it seems a little cleaner and will save a handful of bytes for RGB_MATRIX_ENABLEd keyboards.

This is my first time contributing here, so please let me know if you'd prefer the static approach or would rather this be accomplished in a different way. Thank you!

[alecgeatches]

@pelrun Thank you for the notes! I have addressed them.

[XScorpion2]

With the custom animation pr coming up, you will be able to use the functions directly without any changes to lib8tion fyi #5338

This is because this method pulls you animation code into the rgb matrix compile unit after the math lib, so you will be able to access it without doing any includes on your end.

[pelrun]

Okay, looks like the build is having a tough time generating the lib8tion.a file, it's broken lots of keyboards.

[alecgeatches]

With the custom animation pr coming up, you will be able to use the functions directly without any changes to lib8tion fyi #5338

This is because this method pulls you animation code into the rgb matrix compile unit after the math lib, so you will be able to access it without doing any includes on your end.

@XScorpion2 That will be awesome! Thank you for all of your work on improving the animation support in QMK, it's a huge help for new people like me getting into the ecosystem. Do you think it's worth making these changes in case a user wants to use these functions in custom code? I understand it'll be making changes to the underlying lib8tion library, but I think there still might be use in cleaning it up so it can be included from multiple sources if necessary.

Okay, looks like the build is having a tough time generating the lib8tion.a file, it's broken lots of keyboards.

@pelrun Thank you for your help here. I can take a look at the build breaks to see if I can figure out why they're happening.

[XScorpion2]

I think it's useful as you said to allow others to use these faster math functions. As for your change, I think you can get the same effect with a simpler change by just marking the array static.

My main thoughts are around this point: how likely are we to take future updates to this lib?

Right now most of this lib is inlined for performance costing ~150 bytes (with lto) of firmware space. So I do like the idea of ripping apart this lib into reusable c/h files and reduce in line code duplication at the cost of a bit of performance, but that definitely will prevent future lib updates easily. Tbh I'm really leaning towards this approach but just want to make 100% sure before pulling the trigger.

[drashna]

Okay, looks like the build is having a tough time generating the lib8tion.a file, it's broken lots of keyboards.

Specifically, ARM boards are having this issue.

[pelrun]

Ah, there aren't any functions in there on an ARM build, just the variables. Libraries mustn't like that.

[alecgeatches]

Build is still failing, but from what I can tell the keyboards/zeal60/rgb_backlight.c file causing the errors is also failing for other builds like this unrelated one from 2 days ago. All of the other keyboards are compiling, so I think this change is passing otherwise.

[@XScorpion2: ] As for your change, I think you can get the same effect with a simpler change by just marking the array static.
...
Right now most of this lib is inlined for performance costing ~150 bytes (with lto) of firmware space. So I do like the idea of ripping apart this lib into reusable c/h files and reduce in line code duplication at the cost of a bit of performance, but that definitely will prevent future lib updates easily. Tbh I'm really leaning towards this approach but just want to make 100% sure before pulling the trigger.

@pelrun @XScorpion2 The code has been changed to match your suggestions to just convert the constant to static. @XScorpion2's suggestion for a full header rewrite to the lib8tion library sounds like a good idea, but tackling this is a little beyond my expertise.

I'm hoping this is a good compromise as it changes as little about the library as possible (in case of rewrite or wanting parity with lib8tion's main repo), and doesn't break ARM builds. Does anyone have issues with this workaround for the time being? Thanks!

[XScorpion2]

Looks good, failures in CI look unrelated to this change.