Improve support for JVM max heap configuration #65
Conversation
|
This looks really good! I'm going to test it a bit before merging. In particular, I want to verify how all this interacts with the .cfg files now... my thinking was that if the cfg file has e.g. |
I didn't do auto-prefixing like that because I didn't want to impact other settings in the cfg, e.g. for Also, you have to refer to it as |
JaunchConfig fields prefixed with "cfg." will now explicitly allow override via reading .cfg files. This allows us to set default field values in the .toml but later allow the user to specify these values in a more-easily modified config file. The general pattern is illustrated here with the jvmMaxHeap field: - a cfg.max-heap field is delcared in the toml with a default value - jvm.max-heap is defined in the toml with a value of cfg.max-heap - when jvm.max-heap is interpolated it will resolve to the current cfg.max-heap value, which may have been overridden by a .cfg file Required for fiji/fiji#351
Previously we were performing special-case parameter processing (e.g. expanding %'s in jvmMaxHeap specifications) at the time of initial runtime configuration. However, this would happen a) before variable interpolation and b) only if the user hadn't manually specified a value. As a result, %'s would only work in a very limited number of cases (when set in the .toml) Instead, we now do a second "processArgs" pass that happens after variable interpolation. It is intended to operate on all runtime args at that point, whether they came from a toml configuration, user, etc... This allows the particular case of % calculation in jvmMaxHeap to trigger in all cases. Closes #64. Note that because we process every item in the arg list we are working around #63, without actually fixing it.
Adds necessary pre-reqs for fiji/fiji#351 by supporting
.cfgoverriding of a subset of JaunchConfig fields.Also improves % expansion support in
config.jvmMaxHeapspecification.