Question about coding conventions post Docker

Hi guys,

I was wondering how we should be handling feature additions moving forward within the code. Given that mwm and PhracturedBlue has started the Docker build environment, and it seems that they'll be adding the ability to turn features on/off at compile time, should we be dealing with features from a #define standpoint and have everything in target_def.h?

If so would we also extend pin settings to the .h file and do away with stuff like has-pa or has-"module" as these can also be options that goto the makefile CFLAGS from the snack gui? When should I be using each file (.h vs .ini)?

Just thinking about things I'd like to work on and when I need to maintain hardware.ini compatibility, I really much prefer using #define in target_defs.h.

Thanks!

The build-selectable stuff was my plan. I don't know if PB thinks it's a good idea or not.

But that was for software features, not hardware configuration. The idea was to try and keep the 7e supported by dropping less important features in the official build, but make it easy for those who really needed them to turn off other things instead.

Hardware I wanted to go the other way, and move as much of the stuff that changes between builds into the hardware config file. That way, people wanting to upgrade their hardware would be less likely to need a custom build. See, for instance, the thread on getting a single 3 way on the 7e.

I guess I might have been jumping ahead and assumed that you guys were going to move away from providing binary files and instead deploy everything through the docker build environment as I saw numerous references to opentx. As far my experience there goes, they don't offer binaries on the firmware, just opentx companion which I would then select all the options I want and install the resulting firmware.

While I have preferences for #define as it makes things easier and cleaner, the ini files work as well just in a more complex manner. For example the whole extra switches/buttons has code to ignore sources defined in 2 files, had we used #define, the respective switches/buttons could have been sorted in just the capabilities.h file. It could have been simpler, but the fact that capabilities.h is used in macro defines to auto setup switches, stops us from having a conditional to just omit the respective switch (unless we copy the entire block). Also we end up with a lot of bitwise operation tracking to make sure that our masks are correct. It took me some time to track that flow... LOL.

Either way, hopefully we get more feedback and there can be some consensus. For now, I'll just follow along based on what's already been done, and rehash the code later if convention changes.