Update FAQ

[FrankHB]

Add descriptions of the hack for shared location.

[lazka]

Hm, I'm wondering if that really helps reduce confusion. It's very vague and non-specific.

• It wasn't stated anywhere that native apps are not compatible (why would they be?)
• HOME is set in MSYS2, so what is this proposing?
• Symlinks don't work by default

Would it help if we would have docs for how to set HOME to USERPROFILE (as in change the cygwin defaults)? And some docs on symlinks?

[FrankHB]

Hm, I'm wondering if that really helps reduce confusion. It's very vague and non-specific.

• It wasn't stated anywhere that native apps are not compatible (why would they be?)
• HOME is set in MSYS2, so what is this proposing?
• Symlinks don't work by default

Would it help if we would have docs for how to set HOME to USERPROFILE (as in change the cygwin defaults)? And some docs on symlinks?

The current text is mainly for users as native language developers (probably as a majority of MSYS2's, I think), who can find the retionale quite easily once some keywords are provided here as hints. Nevertheless, I see it is not friendly enough to average users, or developers only having experience of Windows userland.

AFAIK the native application may or may not be compatible in per application basis. Traditional Windows applications usually have separated installations and configurations (System32 v. SysWOW64, Program Files v. Program Files (x86)), but this is not the recent case where applications installed in shared locations (like %AppLocalData%). This is also true for portable installations which users can choose arbitrary local path for installation once it is accessible (except when the application itself is aware of the separation by putting different exectuables in different architecture-specific subdirectories; that is, the installation directory is something like a sysroot). As a result, there is no general (system-wide) notion of multilib "prefix" like FHS or MSYS2 besides things like msvcrt.dll (already in System32/SysWOW64 that we do not expect to change). We should continue to accommodate the fact that even there may be some prefix-sensitive dependencies (e.g stdc++) in the installations of MSYS2 by default, ultimately the application will remain to work once a correct runtime configuration is provided. Such a configuration includs a properly configured %PATH% (as $LD_LIBRARY_PATH and ldconfigs in POSIX systems) and whatever additional per-user/per-application configs, say, %USERPROFILE%, %LocalAppData, %HOME%, or even . (equivalent to $ORIGIN rpath settings in ELF targets).

As of HOME, the points are:

• It can be directly set up in Windows host, and then shared among multiple environments (including multiple installations of MSYS2, Cygwin, and even old MSYS).
  • There are some compatibility troubles like assuming wrong case-sensitivties in the names and different behaviors on empty value of variables, but obviously not touched by HOME.
  • Setting it in some installation other than the host Windows environment is likely having more troubles.
• As it is not an out-of-box thing (it is not the default on Win32), it is an advanced technique deserved some words.
  • This also means that %HOME% is application-specific for native Windows applications. There is almost no need to worry a Win32 appliation misbehaves seriously caused by HOME.
• But why HOME instead of other variables? Because it is less verbose (compared to $USERPROFILE, esp. with ~ expansion in the shell language), and more importantly, using $HOME as a fallback is already known as a natual/common practice (albeit not popular in Windows userland).
  • This is certainly not specific to MSYS2, and there is nothing to do with the Cygwin/MSYS2 default (as it is already assumed to exist).
  • However, if the Windows application does not behave inconsistently against the convention (I haven't seen any), there can be a net win to make it easier to port configurations and scripts with POSIX systems back and forth (e.g. by interacting with less variables).
• In fact, having a common codebase like this (in bash) to switch faster among different systems is what I've practiced successfully for years.
  • Here bash is from MSYS2's /usr/bin. It works by default in the MSYS2 environment (to do some installation). With a carefully configured PATH (and MSYSTEM, but not needed in most cases), Win32 apps also work in the same shell.

I've missed the default status of symlinks, but for users already know about symlink (which is also not a default thing for Windows GUI users), I think they should known how to work around the default limitation. This should better be fixed to more tightly align with MSYS2 policies specific to symlinks, though.

As FAQ text this can be incomplete, but it is already a bit too lengthy. So yes, links will be help, besides the correctness and confidence of source.

Hope I can make some effort to improve in some next days.