Add support for loading config from a clcache.conf file

[formiaczek]

This is useful and the GCC version of ccache also implements a similar concept.

It might be useful in situations where some default settings could be specified or when environment is not passed correctly down to the compiler chain.

This change introduces support for clcache.conf file to allow clcache to read settings from there.

The precedence is as follows:

1. If present, the Environment variable's value is used, or
2. [current_working_dir]/clcache.conf is loaded, or, if not found
3. [%USERPROFILE% or ~/].clcache/clcache.conf is be loaded, or if not found
4. [%ALLUSERSPROFILE% or /etc/].clcache/clcache.conf is loaded.

In each case, once a clcache.conf file is found, no other conf file is considered and values only from this file are used. It is also loaded only once (and all its values then cached) - all to avoid unnecessary performance penalties.

(relevant tests were also added)

[formiaczek]

There seems to be an issue with continuous-integration builds:

Python 3.6.6
pip install -U pip setuptools wheel
ERROR: To modify pip, please run the following command:
c:\python36\python.exe -m pip install -U pip setuptools wheel
You are using pip version 10.0.1, however version 18.0 is available.

But it doesn't seem like in scope of this PR, so I didn't try to fix it, sorry. I could still run tests manually though and they all pass.

Also, another thing to add to compliment the above would be to add CLCACHE_MAX_SIZE to settings / Environment config: just so that different CLCACHEs don't really require having to call 'clcache -M'.

And another nice (and really easy) thing to add would be suffixes. CCACHE allows for something like:

ccache -M 100M  # sets it to   100,000,000 bytes
ccache -M 1G    # sets it to 1,000,000,000 bytes

Hope you like the change and will pull it, I'm sure it'll be useful.

[formiaczek]

Oh, and another useful thing would be for tests to override CLCACHE_CL with some 'dummy (mock)' 'cl.exe' (e.g. a python script) - so that one could run tests without having VisualStudio compiler suite installed. It'd allow for maybe faster / cleaner test execution.

[formiaczek]

I have another idea for a suggestion (if you don't mind, sorry for spamming).

The 'Integration' part of Wiki (https://github.com/frerich/clcache/wiki/Integration) could probably benefit from having the CLTask integration information as described in Caveats (https://github.com/frerich/clcache/wiki/Caveats) as a main way to integrate it (as it's clean), and maybe the compiler binary replacement could be really a 'workaround' than a 'main way of integrating' with MSVC? I've spend some time searching / trying myself how to avoid modifications to system installation until I really bothered to read Caveats.. which had this information I was looking for.. maybe just me, but again - it's just a suggestion :)).

[siu]

:+1: Good suggestions

[frerich]

I think your suggestions sound really good, but unfortunately I have to admit that I didn't get around to maintaining this project as much as I'd like to; I only just returned from my summer vacation and on my desk there's a pile of other tasks to work on unfortunately - only little time left for 'recreational programming' in my spare time. Furthemore, I stopped using clcache myself a couple of months ago, the remaining C++ project I'm involved with (using a proprietary build system) doesn't really benefit from it anymore.

Hence, I wonder: what would be a good way to contact users/contributors to the project and invite others to step forward and take over maintainership? There are a number of users of this tool in various projects and I feel it's still very worthwhile to continue putting work into clcache, e.g. by implementing improvements such as the one you describe.

[formiaczek]

I didn't get around to maintaining this project as much as I'd like to

Understood, no worries - I think it's in a good state, and it seems to work for me :) I had the same with some of my pet projects: it's not easy to keep up with out-of-work stuff in one's spare time. But it's still worth it - as if not people who do this, there'd be no useful software for those who need & use it :)

I wonder: what would be a good way to contact users/contributors to the project and invite others to step forward and take over maintainership?

I'm not sure. But I think maybe mentioning this on a Wiki / README page in form of 'new maintainers needed' or something? There are many people who often ask on various forums/groups how they could get into open-source. They usually get generic (and not very useful) replies like: 'Find something on github/sourceforge and try contributing / fixing some issue etc'. This project already has a fair and friendly invite for contributions IMO.

There are a number of users of this tool in various projects and I feel it's still very worthwhile to continue putting work into clcache,

Agreed! :+1: Myself including, I've recently picked up clcache - thanks for creating it! (I'm really a Linux person, but I need MSVC tools and would like to use tools like this one whenever possible). I've been using CCACHE, icecc/icecream for years and I think they're great. They fill out an important gap in the toolchain (IMO compilers could really offer this out of the box..maybe someday?).

Anyway, I don't want to volunteer that much as I can't promise too much regarding time to maintain it, but I don't mind from time to time having a look / code-review or something? I for sure won't mind providing features that I think are needed / helpful to make it more useful (and I'll try to do it keeping high quality standards, as required) so they hopefully could be merged.

I think the most important thing would be to fix the continuous integration as this is really a first source of truth on sanity of proposed changes ;)

[codecov-io]

Codecov Report

Merging #320 into master will increase coverage by 0.09%. The diff coverage is 84.44%.

@@            Coverage Diff             @@
##           master     #320      +/-   ##
==========================================
+ Coverage   88.23%   88.32%   +0.09%     
==========================================
  Files           4        4              
  Lines        1275     1302      +27     
  Branches      190      196       +6     
==========================================
+ Hits         1125     1150      +25     
- Misses        111      112       +1     
- Partials       39       40       +1

Flag	Coverage Δ
#integrationtests_memcached	67% <64.44%> (+0.15%)	:arrow_up:
#unittests	85.4% <80%> (+0.15%)	:arrow_up:

Impacted Files	Coverage Δ
clcache/__main__.py	90.17% <84.44%> (+0.05%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 6d62cc1...40b5736. Read the comment docs.