Same behavior, but allows lookups without constructing a std::string
(in most cases find() inputs use const char*, so this gets rid of some
string churn).
Configuration mapping was duplicated between three different tables.
Additionally default configuration values were strewn about. Making it confusing as to what the default value would end up being
Adds a new ConfigValues.inl header that defines a few things right next to each other.
Defines the enum name as usual.
Defines the JSON config option name.
Defines the Environment config option name
Defines the default value that the configuration should be
Instead of having the configuration being loaded and stored in to a
frontend system. First moves the backing store of the configuration in
to FEXCore.
Each layer that is constructed then loads its particular configuration.
After the layers are loaded, then a meta layer is constructed that
merges the layers flat.
This means we will no longer hit the problem where a configuration is
stored in the "main" configuration file, then environment and arguments
passed manage to overwrite it.
The order of the layers going from inner most layer to outer most, with
outermost overwriting previous layer configurations is as follows:
Main < Global application < Local application < Arguments < Environment
One step that needs to be changed in the future is that FEXCore can then
just load its configuration from the layers directly since the data is
in FEXCore now. This will be reserved for a future change so we are less
disruptive.
Just ensures that it gets stored in the correct XDG or ~/ config
directories.
If these don't exist then it'll get dumped in to PWD or cwdir, whichever
is available as fallback
In the case of multiple dozens of tests running, they will end up
loading and saving the config files dozens of times.
This was causing the configuration system to load in half saved files
that were causing common crashes in the posix unit tests.
Theoretically this could have happened at any time but it looks like
with the posix unit tests added, it is just more likely to happen.
Makes it so loading the configuration file is much more robust and
verbose on failure.
Makes it so saving the config file first saves to a temporary and then
moves in to the correct location. This causes the config saving to be
atomic in a sense so the unit tests won't corrupt other processes of FEX
trying to load the config file.
Ryan Houdek