Implement an equivalent to `CCACHE_BASEDIR`

[luser]

CCACHE_BASEDIR allows ccache to get cache hits for the same source files stored at different paths, which is useful for developers building from different source trees:
https://ccache.samba.org/manual.html#_configuration_settings

We want this so that we can get cross-branch cache hits on our buildbot builds, which have the branch name in their build directory, and we also want this so we can get cache hits from the S3 cache for local developers' builds.

[posix4e]

Can't we always strip the cwd by default and have this for override? Maybe yet another env

[gumpt]

I am looking at this seriously, and after doing some cleanup of my newbie Rust, it should be ready for a pull request tonight.

[jwatt]

Do out of source object directories present a problem given the way the Firefox source is currently built. Say I have SCCACHE_BASEDIR=/home/jwatt and the following directory structure:

home
  jwatt
    src
      mozsrc1
      mozsrc2
    obj
      mozsrc1-debug
      mozsrc2-debug

When compiling /home/jwatt/obj/mozsrc1-debug/layout/svg/SVGImageContext.cpp (or rather, the unified file that includes SVGImageContext.cpp), the compiler is invoked from /home/jwatt/obj/mozsrc1-debug/layout/svg with the include path -I/home/jwatt/src/mozsrc1/layout/svg. If that path is rewritten to the relative path -I../../../../mozsrc1/layout/svg we are no better off since the mozsrc1 in the path will prevent a cache hit when the same file is built in mozsrc2.

To avoid that it would seem like sccache would need to actually cd to SCCACHE_BASEDIR, rewrite the paths to be relative to that directory, and invoke the compiler from there (if that's possible without causing knock-on issues).

[ncalexan]

In #104 (comment), @glandium said,

Furthermore, due to how sccache is used for Firefox builds, it would be better to have several base directories (an arbitrary number of them).

That seems incompatible with @jwatt's approach in #35 (comment).

@glandium, can you explain what you were thinking, and comment on @jwatt's approach?

[magreenblatt]

In regards to @ncalexan's comment above:

I'm involved in a project that builds both locally for developers and using automated builders and we would like to share the cache among all users.

On Windows we currently pass full include paths via the compiler command-line. Automated builders download Visual Studio and Windows SDK as an archive and extract to a specific directory. Individual developers often have Visual Studio and Windows SDK installed in the default system locations. Our source code is then downloaded in a completely separate directory

For example, a value like this on the automated builders:

"-imsvcc:\\users\\User\\cache\\vs-professional-15.5.2-15063.468\\vc\\tools\\msvc\\14.12.25827\\atlmfc\\include"

Would be equivalent to this on a developer machine:

"-imsvcC:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Professional\\VC\\Tools\\MSVC\\14.12.25827\\atlmfc\\include"

Being able to specify multiple basedir values would allow us to share the cache without requiring everyone to install files in the same locations.

[martinm82]

On Linux you could solve that quite easily by keeping your build tools in a docker image including sccache and mount the sources into the container an all your machines at the same location.

[niosHD]

To add an additional use case to this discussion. I am currently experimenting with building our internal libraries and tools with conan and just realized that effectively using sccache in this environment would need support for something like multiple base directories or something like path ignore patterns.

In short, when building a package foo/1.2.3@user/channel with conan the source is located in $CONAN_HOME/data/foo/1.2.3/user/channel/source and the build directory is $CONAN_HOME/data/foo/1.2.3/user/channel/build. Given that these paths also affect the compiler flags (i.e., include paths), I therefore only get cache hits when I build exactly the same package and version in the same namespace. Using $CONAN_HOME/data/<name>/<version>/<user>/<channel> as base directory would enable cache hits, across different versions of the package.

More than one base directory/ignore pattern is needed in the common case where the package additionally depends on other conan packages. For example, when foo/1.2.3@user/channel depends on bar/4.5.6@otheruser/otherchannel, additional include and link paths to $CONAN_HOME/data/bar/.5.6/otheruser/otherchannel/package/<someSHA>/ are provided to the compiler. Again, these paths have to be ignored in order to enable sccache hits.

[doronbehar]

Question: Was it ever considered to use sha256 sums for the files instead of their full paths? I know this is a different approach then what's taken in the ccache project but I think it's much more reliable. The idea is that the same way that every file path is mapped to an object in the cache, it's sha256sum could be used instead.