aboutsummaryrefslogtreecommitdiff
path: root/docs/data_driven_config.md
diff options
context:
space:
mode:
authorZach White <skullydazed@gmail.com>2021-01-31 12:46:00 -0800
committerGitHub <noreply@github.com>2021-01-31 12:46:00 -0800
commitef6329af7c7be77b537fbfc5a5cc7105acc679f7 (patch)
tree911f2baa834648e09baff1e7cc21cafae47a8ce8 /docs/data_driven_config.md
parent6cada2a35f57629f821852ba629e33e9abee3e74 (diff)
downloadqmk_firmware-ef6329af7c7be77b537fbfc5a5cc7105acc679f7.tar.gz
qmk_firmware-ef6329af7c7be77b537fbfc5a5cc7105acc679f7.zip
Create a system to map between info.json and config.h/rules.mk (#11548)
* generate rules.mk from a json mapping * generate rules.mk from a json mapping * support for config.h from json maps * improve the mapping system * document the mapping system * move data/maps to data/mappings * fix flake8 errors * fixup LED_MATRIX_DRIVER * remove product and description from the vision_division keymap level * reduce the complexity of generate-rules-mk * add tests for the generate commands * fix qmk doctor when submodules are not clean
Diffstat (limited to 'docs/data_driven_config.md')
-rw-r--r--docs/data_driven_config.md44
1 files changed, 38 insertions, 6 deletions
diff --git a/docs/data_driven_config.md b/docs/data_driven_config.md
index 7e4f23284..c2ad4fed8 100644
--- a/docs/data_driven_config.md
+++ b/docs/data_driven_config.md
@@ -12,17 +12,18 @@ Now we have support for generating `rules.mk` and `config.h` values from `info.j
12 12
13## Overview 13## Overview
14 14
15On the C side of things nothing really changes. When you need to create a new rule or define you follow the same process: 15On the C side of things nothing changes. When you need to create a new rule or define you follow the same process:
16 16
171. Add it to `docs/config_options.md` 171. Add it to `docs/config_options.md`
181. Set a default in the appropriate core file 181. Set a default in the appropriate core file
191. Add your `ifdef` and/or `#ifdef` statements as needed 191. Add your ifdef statements as needed
20 20
21You will then need to add support for your new configuration to `info.json`. The basic process is: 21You will then need to add support for your new configuration to `info.json`. The basic process is:
22 22
231. Add it to the schema in `data/schemas/keyboards.jsonschema` 231. Add it to the schema in `data/schemas/keyboards.jsonschema`
241. Add code to extract it from `config.h`/`rules.mk` to `lib/python/qmk/info.py` 241. Add a mapping in `data/maps`
251. Add code to generate it to one of: 251. (optional and discoraged) Add code to extract/generate it to:
26 * `lib/python/qmk/info.py`
26 * `lib/python/qmk/cli/generate/config_h.py` 27 * `lib/python/qmk/cli/generate/config_h.py`
27 * `lib/python/qmk/cli/generate/rules_mk.py` 28 * `lib/python/qmk/cli/generate/rules_mk.py`
28 29
@@ -32,12 +33,43 @@ This section describes adding support for a `config.h`/`rules.mk` value to info.
32 33
33### Add it to the schema 34### Add it to the schema
34 35
35QMK maintains schema files in `data/schemas`. The values that go into keyboard-specific `info.json` files are kept in `keyboard.jsonschema`. Any value you want to make available to end users to edit must go in here. 36QMK maintains [jsonschema](https://json-schema.org/) files in `data/schemas`. The values that go into keyboard-specific `info.json` files are kept in `keyboard.jsonschema`. Any value you want to make available to end users to edit must go in here.
36 37
37In some cases you can simply add a new top-level key. Some examples to follow are `keyboard_name`, `maintainer`, `processor`, and `url`. This is appropriate when your option is self-contained and not directly related to other options. In other cases you should group like options together in an `object`. This is particularly true when adding support for a feature. Some examples to follow for this are `indicators`, `matrix_pins`, and `rgblight`. If you are not sure how to integrate your new option(s) [open an issue](https://github.com/qmk/qmk_firmware/issues/new?assignees=&labels=cli%2C+python&template=other_issues.md&title=) or [join #cli on Discord](https://discord.gg/heQPAgy) and start a conversation there. 38In some cases you can simply add a new top-level key. Some examples to follow are `keyboard_name`, `maintainer`, `processor`, and `url`. This is appropriate when your option is self-contained and not directly related to other options.
39
40In other cases you should group like options together in an `object`. This is particularly true when adding support for a feature. Some examples to follow for this are `indicators`, `matrix_pins`, and `rgblight`. If you are not sure how to integrate your new option(s) [open an issue](https://github.com/qmk/qmk_firmware/issues/new?assignees=&labels=cli%2C+python&template=other_issues.md&title=) or [join #cli on Discord](https://discord.gg/heQPAgy) and start a conversation there.
41
42### Add a mapping
43
44In most cases you can add a simple mapping. These are maintained as JSON files in `data/mappings/info_config.json` and `data/mappings/info_rules.json`, and control mapping for `config.h` and `rules.mk`, respectively. Each mapping is keyed by the `config.h` or `rules.mk` variable, and the value is a hash with the following keys:
45
46* `info_key`: (required) The location within `info.json` for this value. See below.
47* `value_type`: (optional) Default `str`. The format for this variable's value. See below.
48* `to_json`: (optional) Default `true`. Set to `false` to exclude this mapping from info.json
49* `to_c`: (optional) Default `true`. Set to `false` to exclude this mapping from config.h
50* `warn_duplicate`: (optional) Default `true`. Set to `false` to turn off warning when a value exists in both places
51
52#### Info Key
53
54We use JSON dot notation to address variables within info.json. For example, to access `info_json["rgblight"]["split_count"]` I would specify `rgblight.split_count`. This allows you to address deeply nested keys with a simple string.
55
56Under the hood we use [Dotty Dict](https://dotty-dict.readthedocs.io/en/latest/), you can refer to that documentation for how these strings are converted to object access.
57
58#### Value Types
59
60By default we treat all values as simple strings. If your value is more complex you can use one of these types to intelligently parse the data:
61
62* `array`: A comma separated array of strings
63* `array.int`: A comma separated array of integers
64* `int`: An integer
65* `hex`: A number formatted as hex
66* `list`: A space separate array of strings
67* `mapping`: A hash of key/value pairs
38 68
39### Add code to extract it 69### Add code to extract it
40 70
71Most use cases can be solved by the mapping files described above. If yours can't you can instead write code to extract your config values.
72
41Whenever QMK generates a complete `info.json` it extracts information from `config.h` and `rules.mk`. You will need to add code for your new config value to `lib/python/qmk/info.py`. Typically this means adding a new `_extract_<feature>()` function and then calling your function in either `_extract_config_h()` or `_extract_rules_mk()`. 73Whenever QMK generates a complete `info.json` it extracts information from `config.h` and `rules.mk`. You will need to add code for your new config value to `lib/python/qmk/info.py`. Typically this means adding a new `_extract_<feature>()` function and then calling your function in either `_extract_config_h()` or `_extract_rules_mk()`.
42 74
43If you are not sure how to edit this file or are not comfortable with Python [open an issue](https://github.com/qmk/qmk_firmware/issues/new?assignees=&labels=cli%2C+python&template=other_issues.md&title=) or [join #cli on Discord](https://discord.gg/heQPAgy) and someone can help you with this part. 75If you are not sure how to edit this file or are not comfortable with Python [open an issue](https://github.com/qmk/qmk_firmware/issues/new?assignees=&labels=cli%2C+python&template=other_issues.md&title=) or [join #cli on Discord](https://discord.gg/heQPAgy) and someone can help you with this part.