Switch to using LOCALAPPDATA as default location on Windows

[mrjoel]

Description

The current default on Windows of using getenv("APPDATA") results in the default location being in "${USERHOME}/AppData/Roaming". In many enterprise environments that is part of a Windows roaming profile, and is synchronized across a potentially slow network connection on login (i.e. during the login screen when no interaction is possible). The usage of this location by ccache has the unfortunate side-effect of synchronizing a large cache of binary data that is [mostly] inherently tied to a local machine (compiler versions, paths, etc.).

Instead, ccache should default to using LOCALAPPDATA instead which is intended for use by application to store local-only data (email cache, browser cache, etc.).

I'll try to draft a PR in the next week or so, with the following considerations in mind:

• The new default precedence for the config file should be to use ccache.conf in LOCALAPPDATA, then APPDATA. This provides a way to share config while allowing override on a per-machine basis. It also maps well to the existing configuration locations so no migration is required.
• The new default cache directory should be at LOCALAPPDATA/ccache
• Issue a warning if a cache directory is detected at APPDATA/ccache but is not explicitly configured for that location. The warning should include a recommendation to migrate/delete the cache location.
• Continue using the APPDATA/ccache as a default iff it exists but the LOCALAPPDATA/ccache version does not

[jrosdahl]

Instead, ccache should default to using LOCALAPPDATA instead which is intended for use by application to store local-only data (email cache, browser cache, etc.).

Sounds good to me. For reference, the use of APPDATA comes from 92cc99e.

• The new default precedence for the config file should be to use ccache.conf in LOCALAPPDATA, then APPDATA. This provides a way to share config while allowing override on a per-machine basis. It also maps well to the existing configuration locations so no migration is required.

OK.

• The new default cache directory should be at LOCALAPPDATA/ccache

OK.

• Issue a warning if a cache directory is detected at APPDATA/ccache but is not explicitly configured for that location. The warning should include a recommendation to migrate/delete the cache location.

This is unfortunately not possible since ccache should not emit anything other than what the compiler would do. The options are either to silently use the new location or to print an error message and exit with an error code.

• Continue using the APPDATA/ccache as a default iff it exists but the LOCALAPPDATA/ccache version does not

OK.

[mrjoel]

• Issue a warning if a cache directory is detected at APPDATA/ccache but is not explicitly configured for that location. The warning should include a recommendation to migrate/delete the cache location.

This is unfortunately not possible since ccache should not emit anything other than what the compiler would do. The options are either to silently use the new location or to print an error message and exit with an error code.

Ah, yes indeed. Offhand I lean toward the side of exiting with an error, but will consider it further. While the error would be a breaking change on upgrade, combined with point four (continue using previous location of two don't exist) I think it'd be a) a very uncommon case, and b) alerting to a legitimately ambiguous situation, and c) alert to a situation of possibly large cache using disk space without serving any purpose. On the other hand, depending on build system etc. actually seeing the error message may be hit or miss, leading to undue confusion.

[jrosdahl]

@mrjoel: Are you still interested in working on this?

[mrjoel]

Yes, although it's been back burnered for the last bit. If you're asking because someone else would like to do it before I get to it then that's completely fine. If you're asking whether it's worth keeping open then please do.

[jrosdahl]

@mrjoel: In #1023, there is a suggestion to use either %HOMEPATH% or %USERPROFILE% (with higher priority than %HOME% so that the location is consistent in Windows native environments as well as Unix-like environments like Git Bash). What is your opinion on this?

[rkitover]

I'll work on implementing this, I think this design is reasonable, and I also think a fatal error when a cache is detected in APPDATA is the best option.

In addition, I will change the secondary/global config from C:/Program Files (x86)/ccache/etc/ccache.conf to C:\ProgramData\ccache\ccache.conf if there are no objections.

We should also support a system-wide cache there in multi-user scenarios, @jrosdahl @Predelnik @cristianadam any suggestions on the best way to do that? Setting cache_dir in that config would work for example.

[jrosdahl]

I'll work on implementing this, I think this design is reasonable

Thanks. Do I understand correctly that you're aiming for %LOCALAPPDATA%/ccache as the cache location? As mentioned in #1023 (comment), I think I would prefer the same location regardless of execution environment on Windows. What is your opinion on this?

and I also think a fatal error when a cache is detected in APPDATA is the best option.

That's OK with me.

In addition, I will change the secondary/global config from C:/Program Files (x86)/ccache/etc/ccache.conf to C:\ProgramData\ccache\ccache.conf if there are no objections.

Sounds good.

We should also support a system-wide cache there in multi-user scenarios, @jrosdahl @Predelnik @cristianadam any suggestions on the best way to do that? Setting cache_dir in that config would work for example.

Yes, setting cache_dir in the system-wide configuration is one way. Setting a global CCACHE_DIR variable is another.

[rkitover]

I think I would prefer the same location regardless of execution environment on Windows. What is your opinion on this?

That's what I was going to do, and I think this makes the most sense. If someone wants UNIX semantics for config/cache they can use a cygwin/msys2/wsl ccache which is compiled that way. Most native UNIX ports do not make this kind of distinction in any case, it's confusing and error-prone.