Support for additional settings #8
Assignees
Comments
ghost
assigned
This was referenced Mar 27, 2012
jcfr
added a commit
that referenced
this issue
Mar 28, 2012
…ttings. See #8 and #9 * Add function "readAdditionalSettings", the existing "readSettings" function has been split into two functions: - readSettings(filename) - readSettings(filename, settingType) <- this is a new function added to pimpl * settingsType corresponds to the type of settings file being read, it could be either "RegularSettings" or "AdditionalSettings". As of today, the method to read the settings is the same. Only the error message would be different.
jcfr
added a commit
that referenced
this issue
Mar 28, 2012
jcfr
added a commit
that referenced
this issue
Nov 28, 2012
* The launcher will look up for a file named: /path/to/user/settings/<organizationName|organizationDomain>/<applicationName>AdditionalLauncherSettings[-<applicationRevision>] If such file exists, library paths, paths and env variables settings will be considered. Library paths and paths will be prepended. Env variable behavior can be configured based on the location of the <env:VARNAME> statements. For example: FOO=<env:FOO>:Something or FOO=Something:<env:FOO> * It's also possible to configure the basename of the settings that is lookup. This can be done by settings: userAdditionalSettingsFileBaseName * <organizationDomain>, <organizationName>, <applicationName> and <applicationRevision> are read from launcher settings. For example: [Application] organizationDomain=www.commontk.org organizationName=Common ToolKit name=CTKAppLauncher revision=4810 * If application name is omitted, the following file will be looked up: /path/to/user/settings/<organizationName|organizationDomain>AdditionalLauncherSettings[-<applicationRevision>] * If organization name is omitted, the following file will be looked up: /path/to/user/settings/<organizationDomain>/<applicationName>AdditionalLauncherSettings[-<applicationRevision>] * If both organization name and domain are omitted, the following file will be looked up: /path/to/user/settings/Unknown Organization/<applicationName>AdditionalLauncherSettings[-<applicationRevision>] * If organization name, domain and application name are omitted, the following file will be looked up: /path/to/user/settings/Unknown OrganizationAdditionalLauncherSettings[-<applicationRevision>] * If application revision is omitted, prefix [-<applicationRevision>] will NOT be considered. * Add command line argument --launcher-ignore-user-additional-settings See #10, #8
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When using the launcher associated with ApplicationFoo while testing if some plugin can be loaded within ApplicationFoo, it could be useful to "temporary" associate settings without having to update the main settings.
The concept of
additional-settingscould be introduced.Part1 - See #9
The command line argument
--launcher-additional-settingscould be used to associate one (or more - see part3) setting file(s) that will be merge at run time with the settings read from the "main" settings file.Part 2 - See #10
The parameter
additional-settingscould eventually be a parameter read from the "main" settings file.If both 'additional-settings' is set within the main settings and the command line parameter '--launcher-additional-settings' are passed, all the settings will be "merged" together. This behaviour could be avoided by passing the command line
--ignore-additional-settings.Part3 - See #11
Support mutliple settings file passed using
--launcher-additional-settingsThe text was updated successfully, but these errors were encountered: