Tue 08 Aug 2017 08:43:46 PM UTC, comment #1:
From a high-level view, in order to actually address this, it would help to itemize what the little things are that would make this work, and then address them in individual bug reports. For some there are already open bug reports, so please try to find those and add them as dependencies of this bug.
For example there are already open bug reports about making the user configuration depend on the USERPROFILE setting in Windows, and on the Freedesktop configuration setting on unixy systems. If startup scripts, config files, history, etc could be read from another directory based on well-known environment variables like USERPROFILE and XDG_CONFIG_HOME, that would take care of a small piece of this.
The Octave interpreter already has a facility to load startup commands from package global, site global, and user-specific locations. I suspect that Qt has a facility for loading its settings files this way also, so the GUI settings could live with the software rather than in the user's home/profile directory.
Another change might be to make the default global and local pkg paths depend on OCTAVE_HOME and USERPROFILE or XDG_DATA_HOME by default if that's not already the case (e.g. I set up my environment to install packages in ~/.local/lib/octave and ~/.local/share/octave). The global pkg prefix and cache are the relevant ones for Windows users by default.
And then of course you want the contents of the pkg cache that contain OCTAVE_HOME in their path name to also use the value of OCTAVE_HOME, so when the whole thing moves to a different location you don't have to rebuild the cache.
And you probably want all of this to work when OCTAVE_HOME is a path name with spaces or non-ASCII characters in it.
|