The new config system in pcb-rnd

Lists and arrays

Non-scalar settings are arrays or lists. Arrays can be explicitly indexed The default policy is always overwrite.

There are three active policies: overwrite, prepend and append. When dealing with lists:

Step 3 is straight-forward: if policy is overwrite, reset the output list and copy the source's list into the output list. If policy is prepend (or append), keep the current output list and prepend (or append) the list provided by the source.

In practice this means the user can replace, prepend or append ordered lists from various sources. A common example is setting the library search paths.

examples

simple overwrite

Config sources (ordered by priority):
role priority policy content
system 200 overwrite A,B,C
user 400 overwrite (not defined)
project 600 overwrite D,E

Merge iterations:

step description output list after executing this step remarks
0. reset the output (empty)  
1. apply system A,B,C  
2. apply user A,B,C "not defined" doesn't mean "empty", so the list is not deleted - no change
3. apply project D,E replace the original output because of the overwrite policy

Example scenario: the project is restricted to local footprint libs; this setup makes sure no system or user configuration injects external footprint paths.

empty overwrite

Config sources (ordered by priority):
role priority policy content
system 200 overwrite A,B,C
user 400 overwrite (not defined)
project 600 overwrite defined to be an empty list

Merge iterations:

step description output list after executing this step remarks
0. reset the output (empty)  
1. apply system A,B,C  
2. apply user A,B,C "not defined" doesn't mean "empty", so the list is not deleted - no change
3. apply project (empty) replace the original output because of the overwrite policy

prepend

Config sources (ordered by priority):
role priority policy content
system 200 overwrite A,B,C
user 400 prepend (not defined)
project 600 prepend D,E

Merge iterations:

step description output list after executing this step remarks
0. reset the output (empty)  
1. apply system A,B,C  
2. apply user A,B,C "not defined" doesn't mean "empty", so the list is not deleted - no change
3. apply project D,E,A,B,C  

Example scenario: the project has its own footprint libs with two paths; these should be searched before system and user paths, still, system path is also kept so stock footprints can be found.

This is better than hardwiring A,B,C in the project's list: A, B and C may depend on the installation on a given system. A project file has no idea about how the system is installed but it is assumed system installation and the system configuration file are consistent.

append

Config sources (ordered by priority):
role priority policy content
system 200 overwrite A,B,C
user 400 append (not defined)
project 600 append D,E

Merge iterations:

step description output list after executing this step remarks
0. reset the output (empty)  
1. apply system A,B,C  
2. apply user A,B,C "not defined" doesn't mean "empty", so the list is not deleted - no change
3. apply project A,B,C,D,E  

Example scenario: the project has its own footprint libs with two paths; these should be searched after system and user paths. This means the local footprint lib has lower priority than the stock footprints. See system-dependent installation remarks in the previous point.

prepend+append

Config sources (ordered by priority):
role priority policy content
system 200 overwrite A,B,C
user 400 prepend X,Y,Z
project 600 append D,E

Merge iterations:

step description output list after executing this step remarks
0. reset the output (empty)  
1. apply system A,B,C  
2. apply user X,Y,Z,A,B,C  
3. apply project X,Y,Z,A,B,C,D,E  

list and hlist

There are two kinds of lists: string list (simply called list) and hash-list (called hlist).

Each element of a hlist is a hash node in the lihata conf file. These hash nodes are opaque to the conf system and must be processed by the plugin that uses the hlist. Normal merging still works on hlists: opaque elements can be prepended or appended and the whole list can be overwritten.

Each element of a plain (string) list is a text node in the lihata conf file, which is stored as a string in the memory by the conf system.