Closed Allen-Webb closed 4 weeks ago
Ping, this is important for environments where even the loopback interface is not available, or a situation like #1435 to name a couple use cases. In the FreeBSD ports/packages build case with our recommended tooling, those who want to cache compiler artefacts with this are unable to unless a directory containing the Unix socket is mounted to each jail (container), which do not have TCP/IP network access during build.
Trying to see where best to hook such support.
If the quality of the patch is sufficiently high, and the feature is needed and the use-case described in sufficient detail and is plausible, we commonly don't oppose. We'd like to see you around maintaining the added complexity if you're a heavy user though. Little beats extensive testing and day to day use.
That said, I'd be happy to review a PR :) - and sorry for the long delay.
Hi, just implemented this feature as #2206. I have tested on MacOS (I don't have other OS on hand right now). Tested on MacOS and Linux.
Any feedback is welcome.
I am trying to use sccache across network namespaces and realized it is hard coded to use the loopback. Would you all be willing to take patches for specifying a command line option or environmental variable that would accept a unix socket path to use for listening and connecting?
Lets call this option "-L", "--listen-on-path" it would need to be compiled out for windows, but there are already code that uses
[cfg(not(windows))]
Alternatively to keep the flags the same across operating systems, it could just be set with an environment variable: SCCACHE_UNIX_LISTEN.