Also would be nice to add defalut `/etc/ccache.conf` with `sloppiness = time_macros` to allow `makepkg` to use ccache like before, without having to know to include this in your ccache configuration.

Backporting the patch sounds nice, thanks for the reference.

IMO this is something that should be documented somewhere. I dont quite like the idea to override upstream default configurations just to make ccache happy for makepkg. This would have potentially undesired effect on non package builds and people would need to look at downstream overridden config to find out why. Our main selling point is to avoid exactly that.

@anthraxx It may be a bit bold move but perhaps including `if check_buildevn "ccache" "no"` before exporting SOURCE_DATE_EPOCH in `makepkg` would be a better solution.
After all if you are building with `BUILDENV+=(ccache)` you're not going after reproducibility aren't you (¬_¬'')ԅ(￣ε￣ԅ)
[patch for pacman:6.0.0alpha1](http://ix.io/2LB5/diff)
* have to move `REPRODUCIBLE` after sourcing the libraries to have the `check_buildenv` function available.
* produce the same package as original `makepkg` but won't export `SOURCE_DATE_EPOCH` to `build()` function resolving the issue with `ccache:4.1`

this would break reproducibility for other packages like python. conditionally not defining SOURCE_DATE_EPOCH is really a no go on that regard. Also, why wouldn't you go for reproducibility when using ccache?

Other solution that would work, with the patch from ccache:4.2, would be to squeeze `export CCACHE_SLIPPINESS=time_macros` in `libmakepkg/buildenv/compiler.sh.in` [patch:> http://ix.io/2LBm/diff ]

Something like that would make more sense in my opinion as it has less undesired side effects.

@anthraxx ccache:4.2 just landed in community, what about pacman fix for time_macros sloppiness loosening.

This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.