summaryrefslogtreecommitdiff
path: root/LICENSE-APACHE
diff options
context:
space:
mode:
authorMassimiliano Culpo <massimiliano.culpo@gmail.com>2020-10-30 21:10:45 +0100
committerGitHub <noreply@github.com>2020-10-30 13:10:45 -0700
commit33c3c3c700cf0acd458389526974945e62fe895e (patch)
tree8f36028cdcab738a8b458a2584b73b7a45c03fa5 /LICENSE-APACHE
parent458d88eaad3c4e93210915ffa9b3bb64cc52d007 (diff)
downloadspack-33c3c3c700cf0acd458389526974945e62fe895e.tar.gz
spack-33c3c3c700cf0acd458389526974945e62fe895e.tar.bz2
spack-33c3c3c700cf0acd458389526974945e62fe895e.tar.xz
spack-33c3c3c700cf0acd458389526974945e62fe895e.zip
Config: cache results of get_config (#19605)
`config.get_config` now caches the results and returns the same configuration if called multiple times with the same arguments (i.e. the same section and scope). As a consequence, it is expected that users will always call update methods provided in the `config` module after changing the configuration (even if manipulating it as a Python nested dictionary). The following two examples should cover most scenarios: * Most configuration update logic in the core (e.g. relating to adding new compiler) should call `Configuration.update_config` * Tests that need to change the global configuration should use the newly-provided `config.replace_config` function. (if neither of these methods apply, then the essential requirement is to use a method marked as `_config_mutator`) Failure to call such a function after modifying the configuration will lead to unexpected results (e.g. calling `get_config` after changing the configuration will not reflect the changes since the first call to get_config).
Diffstat (limited to 'LICENSE-APACHE')
0 files changed, 0 insertions, 0 deletions