Add a command line option (-d, --directory) to specify a custom location for the cache

[nlebedenco]

Add a command line option (-d, --directory) to specify a custom location for the cache as suggested in #264.

[nlebedenco]

This PR is considerably simpler than #262 which was apparently rejected. The motivation was the difficulty to integrate with CMake projects that cannot or should not use a shared buildcache dir. The only solution at the moment is to set the BUILDCACHE_DIR env var in the shell instance prior to calling CMake but this is cumbersome and ultimately requires a custom shell script to setup the env and then invoke CMake. The intuitive solution of setting an env var in the cmake script itself does not work either because setting CMAKE_[LANG]_COMPILER_LAUNCHER will cause a second CMake instance to be launched that does not inherit env vars of the parent instance (at least not on Windows, haven't tested on Linux/macOS). Having a command line option provides full control in CMake and extends to other config options since specific paths in a project could contain pre-defined config.json files for specific needs.

[mbitsnbites]

Thank you @nlebedenco . I will have a look at this.

In the meantime, could you please expand on why passing the directory via the BUILDCACHE_DIR environment variable is not sufficient for your use case.

[nlebedenco]

I'm seeking to control whether to use buildcache and where the cache dir is located using CMake cache variables. The former is possible by assigning CMAKE_[LANG]_COMPILER_LAUNCHER but the latter is impossible because some generators (e.g. Ninja) can only support alternative launchers and analyzers by invoking a second CMake instance with a special command such as cmake -E __run_co_compile and it cannot inherit env vars set by set(ENV{BUILDCACHE_DIR}). The only choice left is to set the env var in the user profile or make sure that the terminal session or the IDE used by a developer has the correct BUILDCACHE_DIR value set before invoking cmake. This is tedious and error prone. In particular it is harder to ensure consistent settings other than the default because the config.json must be located in the buildcache_dir and the default location is in the user's home folder. If the BUILDCACHE_DIR env var is not set there is no warning and the program silently falls back to default. As a consequence, Lua extensions are not used, remote cache is not used, etc. And soon, working in two projects with different config.json files becomes impractical.

[nlebedenco]

Bump

[mbitsnbites]

Sorry for the delay.

I approve with the feature addition, but I have a few comments:

1. I think that the handling of the -d, --directory option should be placed before the first config init call. It would avoid unnecessary double-initialization, and the logging configuration would be correct.
2. Some additional wording about the -d option could be added to doc/configuration.md (e.g. after the first paragraph).
3. The help text needs to be further updated, e.g:

Usage:
    buildcache [options] [command]
    buildcache [options] compiler [compiler-options]

[mbitsnbites]

On second thought it's not very straight forward to parse the -d option before the first config initialization. I'm looking into various solutions.

[mbitsnbites]

@nlebedenco I made a slightly revised version of this PR in #290 - please check if you think that it works as you intended.

I made a few changes:

• Improve the help text (long overdue - it was incorrect/misleading even before this PR)
• I only allow options (only -d/--directory right now) before a command or the compiler name, so I dropped the else-if part in the option parsing logic.
• The configuration is reset to default before loading the -d override config (I discovered that the config was cumulative, which was probably not what you intended).

Closing this PR now (feel free to comment in #290 ).