jia200x/configurations-tf-draft-01

## configurations-tf-draft-01

### Problems we want to solve
Here's a list of problems we might want to solve. Feel free to discuss

- [ ] Application specific configuration (#9825)
- [ ] Kernel/modules configurations (expose defaults, override configs, load from external sources, etc)
    - [ ] All modules seeing all other modules configuration values. This breaks encapsulation and means that a rebuild for EVERYTHING must be triggered each time ANYTHING changes.
    - [ ] Configurations dependencies (a module might require to set some configuration from another module, but that can be also defined elsewhere. E.g `CFLAGS += -DFF=some_value -DFF=conflicting_val` => the value will be _silently overwritten_.
- [ ] Configuration for ~external~ modules (specially if [#8987 (comment)](https://github.com/RIOT-OS/RIOT/pull/8987#issuecomment-383043605) gets implemented)
    - [ ]  Configuration in makefiles can be evil. If the external pkg is not from a trusted source, it could eventually run arbitrary code injected via Makefiles. it is not even possible to get package metadata from a makefile without risking running arbitrary code
- [ ] Metadata and build configuration:
    - [ ] Improve board/periph configuration (define boards withouth touching the RIOT folder, switch between configurations, override, etc)
    - [ ] Description of available periphs/devices and it configurations

### Corollaries (related problems)
- It's required to touch the RIOT folder in order to add new packages, drivers, or even a different board configuration (WIP #9811, and also #9105?)
- This:
```
- A: It is not easy to have more than one version of a PACKAGE and not possible to have more than one version of a MODULE.
- B: All components must live in RIOT.
- A+B = To update a component one has to update all of RIOT. Updating all of RIOT means getting new version of other components, whether that is necessary/wanted or not.
```

	### Problems we want to solve
	Here's a list of problems we might want to solve. Feel free to discuss

	- [ ] Application specific configuration (#9825)
	- [ ] Kernel/modules configurations (expose defaults, override configs, load from external sources, etc)
	- [ ] All modules seeing all other modules configuration values. This breaks encapsulation and means that a rebuild for EVERYTHING must be triggered each time ANYTHING changes.
	- [ ] Configurations dependencies (a module might require to set some configuration from another module, but that can be also defined elsewhere. E.g `CFLAGS += -DFF=some_value -DFF=conflicting_val` => the value will be _silently overwritten_.
	- [ ] Configuration for ~external~ modules (specially if [#8987 (comment)](https://github.com/RIOT-OS/RIOT/pull/8987#issuecomment-383043605) gets implemented)
	- [ ] Configuration in makefiles can be evil. If the external pkg is not from a trusted source, it could eventually run arbitrary code injected via Makefiles. it is not even possible to get package metadata from a makefile without risking running arbitrary code
	- [ ] Metadata and build configuration:
	- [ ] Improve board/periph configuration (define boards withouth touching the RIOT folder, switch between configurations, override, etc)
	- [ ] Description of available periphs/devices and it configurations

	### Corollaries (related problems)
	- It's required to touch the RIOT folder in order to add new packages, drivers, or even a different board configuration (WIP #9811, and also #9105?)
	- This:
	```
	- A: It is not easy to have more than one version of a PACKAGE and not possible to have more than one version of a MODULE.
	- B: All components must live in RIOT.
	- A+B = To update a component one has to update all of RIOT. Updating all of RIOT means getting new version of other components, whether that is necessary/wanted or not.
	```