role | default setting prio | location | presence | remarks |
---|---|---|---|---|
internal | 100 | (compiled into the executable) | always | the ultimate fallback; allows the application to run even if no other configuration file is found |
system | 200 | app's conf in $(CONFDIR) | recommended | should hold system and installation specific settings, e.g. path to the system-wise installed footprint library |
default board | 300 | app's default design typically in /usr/share/APP/ 1 | deprecated2 | pcb editable defaults |
user | 400 | e.g. ~/.pcb-rnd/conf-core.lht | recommended | store user preferences, user's common footprint lib path, etc; this is the first file the user can modify (even from the GUI) |
environment | 500 | environment variables (TODO) | occasional | inject the same (temporary) settings in multiple app sessions without having to change config files |
project | 600 | project.lht in the project directory | optional | local project settings - useful for large projects with multiple board (.lht) files |
design | 700 | saved in the design (board, schematics, etc.) | optional, common | per design deviation from the user+system config |
cli | 800 | command line argument | occasional | inject/change a setting for a single session; useful in batch/automated processing |
The application reads them all, then merges all settings into a master binary representation. If a setting is specified in multiple sources, the one with the higher priority wins, except for lists where it is also possible to prepend/append items. Default priorities are designed to result precedence in an intuitive way (e.g. design settings overwrite user settings). However, priority can be changed per setting, resulting in weak settings ("use this value if it was not already set") or strong settings ("I always want to use mincut, so I enable it from my user's config with high priority and a version controlled project setting can not turn it off")
Footnotes: