add 'KEYBOARD_LOCAL_FEATURES_MK' into build_keyboard.mk

[mtei]

Description

KEYBOARD_LOCAL_FEATURES_MK has the file name of the file that contains
the keyboard post-processing rules.

Post-processing rules convert keyboard-specific shortcuts that represent
combinations of standard options into QMK standard options.

Usage:

// file: keyboards/helix/rev2/rules.mk
KEYBOARD_LOCAL_FEATURES_MK := $(dir $(lastword $(MAKEFILE_LIST)))local_features.mk

HELIX_ROWS = 5              # Helix Rows is 4 or 5
LED_BACK_ENABLE = no        # LED as backlight (Enable WS2812 RGB backlight.)
LED_UNDERGLOW_ENABLE = no   # LED as underglow (Enable WS2812 RGB underlight.)
IOS_DEVICE_ENABLE = no      # connect to IOS device (iPad,iPhone)

// file: keyboards/helix/rev2/keymaps/a_keymap/rules.mk
LED_BACK_ENABLE = yes        # LED as backlight (Enable WS2812 RGB backlight.)

// file: keyboards/helix/rev2/local_features.mk
ifneq ($(strip $(HELIX_ROWS)), 4)
  ifneq ($(strip $(HELIX_ROWS)), 5)
    $(error HELIX_ROWS = $(strip $(HELIX_ROWS)) is unexpected value)
  endif
endif
OPT_DEFS += -DHELIX_ROWS=$(strip $(HELIX_ROWS))

ifeq ($(strip $(LED_BACK_ENABLE)), yes)
  RGBLIGHT_ENABLE = yes
  OPT_DEFS += -DRGBLED_BACK
else ifeq ($(strip $(LED_UNDERGLOW_ENABLE)), yes)
  RGBLIGHT_ENABLE = yes
endif

ifeq ($(strip $(IOS_DEVICE_ENABLE)), yes)
    OPT_DEFS += -DIOS_DEVICE_ENABLE
endif

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[drashna]

This looks like it's a re-implementation of:
#2046

[mtei]

I previously found #2046, but I forgot it and created this PR. I don't mind either implementation.

[drashna]

Yeah, it was on my minds, since I just went through all of our open PRs....

Also, I think the other PR may be a bit cleaner in its implementation and should be the way we go, if/when one of these gets merged.

Byt yeah, I do like the idea.

[drashna]

Double checking this PR, I think that seeb's may be the better implementation, and the one that we should go with, long term. It supports every layer of the makefile stuff, which also allows for some pretty cool stuff (well, the same stuff as here, but at all levels, from what I've seen.

[mtei]

Choose a more appropriate one. :-)

[stale]

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.

[drashna]

Mostly, I'm adding the "On Hold" label, since there is discussion around this topic (eg, the best way to handle this). And so the Stale bot doesn't close the PR

[mtei]

This is closed because I have opened a more general PR. #8422