From e9755521ab73f5ae87e578ed1826fe128de426a7 Mon Sep 17 00:00:00 2001 From: Fredric Silberberg Date: Mon, 16 Jul 2018 19:10:23 -0700 Subject: [PATCH] Update README with rules.mk ordering information. --- docs/feature_userspace.md | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/docs/feature_userspace.md b/docs/feature_userspace.md index c8fa406cb0..5f7c05b83b 100644 --- a/docs/feature_userspace.md +++ b/docs/feature_userspace.md @@ -31,6 +31,20 @@ The reason for this, is that `.h` won't be added in time to add settings ( So you should use the `config.h` for QMK settings, and the `.h` file for user or keymap specific settings. +`/users//rules.mk` will be included in the build _after_ the `rules.mk` from your keymap. This allows you to have features in your userspace `rules.mk` that depend on individual QMK features that may or may not be available on a specific keyboard. For example, if you have RGB control features shared between all your keyboards that support RGB lighting, you can `define RGB_ENABLE` in your keymap `rules.mk` and then check for the variable in your userspace `rules.mk` like this: +```make +ifdef RGB_ENABLE + # Include my fancy rgb functions source here +endif +``` +Because of this, any time you turn on QMK features in your `users//rules.mk`, you should conditionally enable them only if the flag isn't already defined, like this: +```make +ifndef TAP_DANCE_ENABLE + TAP_DANCE_ENABLE = yes +endif +``` +This will ensure that you can explicitly turn off features for an individual keymap. + ## Readme Please include authorship (your name, github username, email), and optionally [a license that's GPL compatible](https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses). @@ -122,4 +136,4 @@ By default the userspace used will be the same as the keymap name. In some situa ``` USER_NAME := mylayout -``` \ No newline at end of file +```