aboutsummaryrefslogtreecommitdiffstats
path: root/lib/reltool/src/reltool_sys_win.erl
diff options
context:
space:
mode:
authorSiri Hansen <[email protected]>2012-02-15 16:36:27 +0100
committerSiri Hansen <[email protected]>2012-03-19 09:48:54 +0100
commit6f5e3e16019a3a4f9e9033d185b9c487967ad5fa (patch)
tree3d81f6e42a74e45e43ad4b305659bcd3b19e1618 /lib/reltool/src/reltool_sys_win.erl
parente3bb31270b1cc43a72a2c3942f496e5c8f93155b (diff)
downloadotp-6f5e3e16019a3a4f9e9033d185b9c487967ad5fa.tar.gz
otp-6f5e3e16019a3a4f9e9033d185b9c487967ad5fa.tar.bz2
otp-6f5e3e16019a3a4f9e9033d185b9c487967ad5fa.zip
[reltool] Update state and tables consistently for all types of config changes
OTP-9794 OTP-9968 The main idea behind the data structure in reltool_server is that the state shall reflect what is explicitly configured, and the tables shall contain this configuration plus everything that is derived. In some cases, however, this was not the complete truth: * the application table was never read * the module table was never updated on undo * the state contained a lot more than what was explicitly configured This commit re-writes major parts of the reltool_server for the sake of unifying the way the state and tables are updated: * The list of applications in the state now only contains those applications and modules for which there are explicit settings in the configuration (given at startup or changed from the GUI) * When changing any bit of the configuration, the tables are always emptied and every part is derived again from the configuration found in the state * All configuration changes now cause a re-read of the file system, meaning that if something has changed in the file system it will be reflected in the result of the configuration change. This is the case even if no file system related configuration is changed (e.g. root dir or lib dirs) (*POSSIBLE INCOMPATIBILITY*) * Requests for applications and modules from the GUI now always read the tables, not the state * When loading a new configuration file via the GUI, the old configuration is completly scratched, and only the new is valid (*POSSIBLE INCOMPATIBILITY*) * The handling of escripts which include archives of applications is changed to always produce one #app record for the escript in addition to one for each inlined application. All modules are listed as parts of the inlined application where it belongs and not as part of the escript's #app record. This is a temporary solution which will be modified and improved. The following bugs are corrected by this commit: * Loading a config which contains an escript via the GUI menu did not produce the same #app record as when loading the same configuration at reltool start. Paths, version and label could differ. * Loading config with same escript (source) twice caused reltool to add same module twice in #app.mods * Loading config with same escript (inlined beam) twice caused reltool to fail saying module is included by two different applications * Loading config which in addition to an existing escript also adds another escript for which the name sorts before the existing one would cause reltool to fail saying "Application name clash"
Diffstat (limited to 'lib/reltool/src/reltool_sys_win.erl')
0 files changed, 0 insertions, 0 deletions