conda-build
conda-build copied to clipboard
09 add ccache support
For discussion. This will greedily find and use any ccache at present. I guess we want something more controlled.
Some results on macOS:
First build:
Resource usage statistics from building llvm-package:
Process count: 43
CPU time: Sys=0:19:03.4, User=5:51:18.6
Memory: 2.0G
Disk usage: 2.2M
Time elapsed: 1:22:47.0
Second build:
Resource usage statistics from building llvm-package:
Process count: 36
CPU time: Sys=0:01:55.6, User=0:08:46.9
Memory: 1.4G
Disk usage: 2.2M
Time elapsed: 0:09:28.7
ccache WIP PR: https://github.com/conda-forge/ccache-feedstock/pull/11
.. Windows support is from a fork at present. I added the main patch but it doesn't apply, regardless, I've not been able to get the Windows executable to work. It builds just fine, using the mingw-w64 toolchain, but is then capable of targeting MSVC.
I'm not sure how careful we need to be. How completely does ccache capture state? If there's no chance of accidental incompatibility, then global is a-ok. This is really exciting stuff!
Hey Mike. Ccache stores its, err, cache in ~/.ccache at present. I don't know if it includes, for example, a hash of the ccache executable itself when making cache names. If it does then I'm pretty happy to just be greedy. My idea for a command line option would be:
--ccache={none, conda, any} with a default of conda. In this case, either the build or sys prefix could be searched in, or we could make it more fine grained?
I was more wondering along the lines of compiler flags and friends. Is its cache key unique for any given set of preprocessor flags, compiler flags, compiler version, etc? If so, then global is totally fine. I think it would be insanely awesome to have a remote cache, such that build farms could really build files only when necessary.
Yes it is.
superseded by:
- https://github.com/conda/conda-build/commit/94c16481f8338138e4bb961fa2677f422c4631df
- https://github.com/conda/conda-build/pull/3932
- https://github.com/conda/conda-build/pull/3952