Also refer to bug #40444 where an additional patch was pushed.

I made the changes Mike outlined in comment #33 and added some documentation for the new startup file location to the manual and in the NEWS file:
http://hg.savannah.gnu.org/hgweb/octave/rev/8fd7d1d2a4ca

Marking as ready for test.

Thank you very much! I have seen in some places that MAX_PATH + 1 is more correct.

wchar_t path[MAX_PATH + 1];

With the attached modifications to your patch, the default-octave target finished building successfully (without the need to change the Windows API level).
When starting up Octave on Windows 10 1809, I see the following in the Command Window:

debug: load new startup file: C:\Users\Markus\AppData\Roaming\octave\octaverc
>>

While that seems reasonable to me, I haven't followed the discussion well enough to decide whether this is the correct path.
Personally, I would expect the start up file to be at C:\Users\Markus\Documents\octave\octaverc (i.e. below CSIDL_PERSONAL).
My impression is that files in %APPDATA% or %LOCALAPPDATA% shouldn't be edited by users directly. These are locations that are "more internal" to programs and get only used behind the scenes.

(file #46491)

@Anonymous: Could you please report your findings at bug #54662. I was left under the impression that Octave CLI won't start on Windows XP due to an unknown reason.

In the mean time, I tried to link to the missing libraries by adding the following to configure.ac:

diff -r ad0b74e52f95 configure.ac
--- a/configure.ac        Sat Mar 09 22:09:25 2019 +0100
+++ b/configure.ac        Sun Mar 10 09:59:37 2019 +0100
@@ -1267,6 +1267,26 @@
   ;;
 esac

+## Windows-specific module used for get_user_config_directory function
+case $host_os in
+  msdosmsvc | mingw*)
+    AC_CHECK_HEADERS([objbase.h],
+      [LIBS="-lole32 $LIBS"],
+      [AC_MSG_ERROR([Missing OLE32 required to build for Windows target.])],
+      [#include <windows.h>])
+  ;;
+esac
+
+## Windows-specific module used for get_user_config_directory function
+case $host_os in
+  msdosmsvc | mingw*)
+    AC_CHECK_HEADERS([knownfolders.h],
+      [LIBS="-luuid $LIBS"],
+      [AC_MSG_ERROR([Missing UUID required to build for Windows target.])],
+      [#include <windows.h>])
+  ;;
+esac
+
 ## Cygwin kluge for getrusage.
 AC_CHECK_FUNCS([getrusage])
 case $host_os in

However, the build still fails ultimately. I see the following message from the linker (and similar ones repeatedly) in the logs:

/bin/bash ./libtool  --tag=CXX   --mode=link x86_64-w64-mingw32-g++  -fopenmp -Wall -W -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -g -O2 -version-info 7:0:0 -no-undefined -bindir /home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/bin -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib  -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib  -Wl,-rpath-link,/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/qt5/lib -Wl,--export-all-symbols -o liboctave/liboctave.la -rpath /home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib/octave/6.0.0 liboctave/liboctave_la-liboctave-build-info.lo liboctave/liboctave_la-version.lo liboctave/array/libarray.la  liboctave/external/ranlib/libranlib.la liboctave/external/libexternal.la liboctave/numeric/libnumeric.la liboctave/operators/liboperators.la liboctave/system/libsystem.la liboctave/util/libutil.la liboctave/wrappers/libwrappers.la libgnu/libgnu.la -lcurl -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse -lsuitesparseconfig -larpack -lqrupdate -lfftw3 -lfftw3f -llapack -lblas -lxerbla -lreadline -ltermcap  -lpcre    -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/qt5/lib -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/lib/gcc/x86_64-w64-mingw32/7.4.0 -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/lib/gcc/x86_64-w64-mingw32/7.4.0/../../../../x86_64-w64-mingw32/lib/../lib -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/lib/gcc/x86_64-w64-mingw32/7.4.0/../../../../x86_64-w64-mingw32/lib -lm -lgfortran -lmingw32 -lmoldname -lmingwex -lmsvcrt -lquadmath -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -luuid -lole32 -lpsapi -lgdi32  -lm    -lws2_32 -lws2_32   -ladvapi32  -lws2_32 -lws2_32 -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib -liconv -R/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib   -luuid -lole32 -lpsapi -lgdi32  -lm
mv -f libinterp/.deps/liboctinterp_la-build-env-features.Tpo libinterp/.deps/liboctinterp_la-build-env-features.Plo

*** Warning: linker path does not have real file for library -luuid.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libuuid and none of the candidates passed a file format test
*** using a file magic. Last file checked: /home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib/libuuid.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.

I checked that the file is there at the indicated directory. But don't know how to proceed further.

We don't link with ole32 yet.

Oh, thank you, I didn't realize that was already in configure.ac!

Sure. Is _WIN32_WINNT something that should be set in mxe-octave so it applies globally to the builds of all dependencies? Or should Octave define it in configure.ac if it isn't already set by the user?

Thanks. Can we build mxe-octave with -D_WIN32_WINNT=0x0601 from now on?

👍

New bug for caching downloaded packages: bug #55873.

Regarding comment #10 the following also can be used for compatibility with older Windows systems.

WCHAR path[MAX_PATH];
SHGetFolderPathW(nullptr, CSIDL_LOCAL_APPDATA, nullptr, 0, path);

Err, "bug-notification emails".

Andrew, there's a bit of discussion about Windows over in bug #40444, see there.

> On macOS, I think there is a separate standard hierarchy, and I can include that as well here. I've seen some references to a standard location of ${HOME}/Library/Preferences. So that would make the startup file ${HOME}/Library/Preferences/octave/octaverc.
>
> @apjanke Does that look right to you?

Yes, ~/Library is the default location for the hierarchy of config files and persistent program state on macOS. Application state (like the Qt window location and widget arrangement) would go in `~/Library/Application Support`.

However, I'd recommend sticking with the Unix-y `~/.config/octave` or `~/.octaverc` for Octave on macOS.

The ~/Library hierarchy is mostly used by native Mac apps that are built using Apple frameworks, and they use plists and other Mac-y mechanisms. Most software I've seen come over from Linux keeps the `~/.config/myapp` or `~/.myapp*` pattern, and it doesn't cause any problems.

I don't think that Octave has a Mac developer that could provide expertise in using the `~/Library` hierarchy. I'm certainly not advanced enough: I don't really know what to do there, or what formats are appropriate for use in it. (I don't even know if using rc files instead of .plist files in ~/Library/Preferences is technically supported.) And the documentation I've seen on this file hierarchy seems to really leverage Apple frameworks for interaction with it, instead of defining the dir tree and file formats at a low level.

(At this point I have to confess to using ~/Library/Application Support myself in Octave.app - but that seemed to be the Rightest place for it in what is trying to be more of a native Mac app. $XDG_DATA_HOME would have been just as right, I think...)

And the source code would be simpler and easier to maintain just using the `~/.config/octave` mechanism on both Unix platforms. Since macOS seems to be the distant third-place platform for Octave power users and developers, I don't think a split bodes well for the fate of platform-specific codebase, even if it's not big.

Plus, ~/.octaverc is a convenience for multi-platform users: that way they can sync their Octave preferences across machines by just syncing ~/.config or ~/.octaverc across machines. Switching to ~/Library would require a more complicated configuration linking different local filesystem locations to a shared backing file depending on the platform.

And all the "howto" articles or bug reports online that explain how to edit or fix your Octave config or app state on Linux would still be applicable to Mac users, too.

There are no advantages I'm aware of to using ~/Library unless you're also using Apple's macOS app development frameworks as well.

So, I'd vote for not using ~/Library, and continuing to just treat Macs as a Unix-y system here.

Attached is a first draft at resolving this bug. This patch loads a new startup file, following the conventions of XDG_CONFIG_HOME on GNU/Linux and Unixy systems, and uses %LOCALAPPDATA% on Windows systems.

• Can someone who builds for Windows regularly test this patch for me? I have no idea if what I threw together is right. If it works, you should see a message "debug: load new startup file: ...", and the path to that file should look sane. If you then create that file, and put a "disp" or something in it, it should work as expected.

• @jwe I would appreciate any thoughts about how I am creating new library functions here. My idea is to have one new function in liboctave called "get_user_config_directory" that returns the platform-dependent base directory for config files, and another function, maybe "get_octave_config_directory" that returns the "/octave" subdir of the former, but I'm not sure where I want to place that one. There will also probably be future additions for returning a vector of configuration directories (both XDG and Windows define multiple configuration locations that could be read in sequence).

(file #46450)

I plan to start working on this for Octave 6.

My plan is to introduce a new user startup file that will be in the appropriate directory for application preferences for each system type. On GNU/Linux and Unixy systems, that will be ${XDG_CONFIG_HOME}/octave/octaverc, or ${HOME}/.config/octave/octaverc if XDG_CONFIG_HOME is not set.

On Windows, this will be %LOCALAPPDATA%\octave\octaverc.

The original startup file ${HOME}/.octaverc will still be loaded after loading this new standard startup file, and of course ${PWD}/.octaverc will still be supported as well. At this point, ${HOME}/.octaverc becomes a kind of special case of ${PWD}/.octaverc.

>Do you want the one to make a plan? Can you provide a patch?

Can you point me where .octaverc and .octave_hist are written?

>At least in Debian Wheezy, looking at all my environment
>variables, the only XDG variable I see is XDG_DATA_DIRS which is
>the less useful for us

There's no need to read the environment variable yourself : most language provide a library to use XDG folder:
with glib/GTK just replace g_get_home_dir() by
g_get_user_config_dir()

I'm very much in favour of this but is anyone really following this specification? At least in Debian Wheezy, looking at all my environment variables, the only XDG variable I see is XDG_DATA_DIRS which is the less useful for us. From their specification there's default values that should be used when their value is not used.

I meant to have proposed a ~/.octave directory rather than having a .octave_packages, .octaverc and .octave_hist files. But what tI was looking at the GNU Coding standards and didn't saw reference a reference to anything.

It seems like at least ~/.octaverc and ~/.octave_hist are stored in the home directory. It would be better to use the locations defined in the XDG Base Directory Specification.

https://live.gnome.org/GnomeGoals/XDGConfigFolders
http://standards.freedesktop.org/basedir-spec/latest/