Apply changes to the InfiniTime build

[toastom]

I'm thinking this can be implemented best by doing some funky stuff with CMake build options in the src/CMakeLists.txt file. There's the INCLUDE_FILES list and the APPEND_SOURCE_FILES list. I might be able to work with those and first intelligently determine which apps and watchfaces the user should be able to enable and disable. Only allow apps and watchfaces and only allow those that won't break the build if we leave them out, like InfiniPaint.The user shouldn't be able to leave certain services out of the compilation like Bluetooth, or at least this is not planned for the first version of infinitweaks.

I'll need to add these options to the cmake file (probably need to submodule a new 'infinitweaks' branch of my InfiniTime fork) and then somehow allow the user to toggle the options on and off through their marked changes and the apply command. I'm a super noob to cmake, but maybe there is a way to read from some custom config (JSON?) file and easily set options that way.

Here are my first thoughts on how this can be implemented:

• A user marks some apps as changes to the build with exclude and include like usual
• They enter apply to apply marked changes
• This saves their changes in a config file with some compilation options
  • Ex. "COMPILE_INFINIPAINT" : false, "COMPILE_PADDLE" : false ...
  • Another benefit is that the changes are saved between compilations. No need to enter or remember 20,000 cmake build flags to compile the same firmware, although a user could just throw it all in a script...
• CMake reads this config file when building and it now knows which files to exclude from the compilation
• Some magical #ifdef hacks happen in the DisplayApp source files to actually get it to compile and display properly on the screen
• ...
• Profit Yay we should now have a wonderfully debloated PineTime.

I know this sounds ridiculously complicated and I'm sure it can be done with mostly CMake. But I also want to keep a fairly user-friendly (it's a cli tool I know) interface to make it simple for others to edit their IT builds. I could just throw out the config file idea and make apply edit the CMake file directly to set options, but that doesn't sound as elegant. Need to think on this more and hopefully create a simpler solution.

[toastom]

So I'm now realizing the separate config file is a dumb idea and completely overcomplicates an already somewhat confusing process. I'd much rather just include some default cmake options and then let the user manually enable and disable apps and watchfaces. This would be way less work on me and make the project way easier to maintain (and it would be less documentation for me to write, too).

I'm also now realizing that if the app build options live in that main CMakeLists.txt file (user could enable them through cmake ... -DBUILD_INFINIPAINT for example) then infinitweaks as it sits as a bash script right now is kind of useless. If a user can just as easily add an option to the build command as they can run my script, then why run my script? It would just be extra overhead.

Maybe instead of nixing the compile command in favor of making the user apply changes and compile on their own, I can instead mix the two in one apply and compile command (whose name will probably stay as apply). That way it will be easier for the user to mark a TON of changes to the firmware all at once. And this might mean that integration with the rest of the IT codebase would need to be added to introduce an easy customizability feature to infinitweaks (i.e. changing the color of UI elements).

I guess I REALLY need to think on this more and maybe play around with cmake build options on a smaller scale first to get ideas...