Change Details

The CFG_SYSTEM namespace is above default but below every other namespace, including CFG_USER. It was intended to be for the "local.cfg" config file, which existed to let devs make changes without committing them to svn. This is a bit of a weird purpose, because: - user.cfg exists - one can just be careful Furthermore, the CFG_SYSTEM name implies somme connection with the user's system, when there is none. Because of this, HWDetect and other "system capabilities" checks need to change settings awkwardly to override user settings-but-not-command-line settings. This makes rendering options extremely awkward to navigate. If instead we make CFG_SYSTEM override all config namespace but the command line, then we can easily use this for hardware detection condor, while still letting the user override from the command line. This lets us clean up HWDetect and remove global variables. See Shadows / ShadowPCF for an example of the cleanup scope.

The CFG_SYSTEM namespace is above default but below every other namespace, including CFG_USER. It was intended to be for the "local.cfg" config file, which existed to let devs make changes without committing them to svn. This is a bit of a weird purpose, because: - user.cfg exists - one can just be careful Furthermore, the CFG_SYSTEM name implies somme connection with the user's system, when there is none. Because of this, HWDetect and other "system capabilities" checks need to change settings awkwardly to override user settings-but-not-command-line settings. This makes rendering options extremely awkward to navigate. If instead we make CFG_SYSTEM override all config namespace but the command line, then we can easily use this for hardware detection condor, while still letting the user override from the command line. This lets us clean up HWDetect and remove global variables in D1931.

The CFG_SYSTEM namespace is above default but below every other namespace, including CFG_USER. It was intended to be for the "local.cfg" config file, which existed to let devs make changes without committing them to svn. This is a bit of a weird purpose, because: - user.cfg exists - one can just be careful Furthermore, the CFG_SYSTEM name implies somme connection with the user's system, when there is none. Because of this, HWDetect and other "system capabilities" checks need to change settings awkwardly to override user settings-but-not-command-line settings. This makes rendering options extremely awkward to navigate. If instead we make CFG_SYSTEM override all config namespace but the command line, then we can easily use this for hardware detection condor, while still letting the user override from the command line. This lets us clean up HWDetect and remove global variables. See Shadows / ShadowPCF for an example of the cleanup scope in D1931.