[Buildroot] [PATCH] ccache: make default host-ccache cache dir fit for multi-user setups
Peter Korsgaard
peter at korsgaard.com
Fri Jul 7 15:26:55 UTC 2017
>>>>> "Arnout" == Arnout Vandecappelle <arnout at mind.be> writes:
Hi,
> I think Thomas's point is: ~/.br-ccache is fine, ~/foo/bar/directory is not
> fine, even if that is what was configured in the buildroot config from which the
> external toolchain was generated (and which is NOT the buildroot configuration
> used by the final user, otherwise this problem wouldn't even occur).
Well, it is a choice made by whoever built the sdk, just like the gcc
version and C library or whatever.
If it truly makes sense to make this configuable is another question. I
have never used that feature at least (but we have plenty of other
features that I also don't use).
> I think Thomas, like me, means that we should instead revert
> d93a0b402934309c632d4a825b7fe6183ce8c4c7.
That is also an option, but as we have been carrying this patch for > 3
years, there might be people using it.
> In fact, I think we should drop this Buildroot-specific patching entirely. As
> far as I can see, BR_CACHE_DIR was introduced to replace the normal CCACHE_DIR
> because way back when our ccache didn't reliably detect the compiler and would
> reuse object files that we actually created with a different toolchain. So the
> Buildroot-specific ccache would disable fingerprinting completely. Obviously, if
> it would then reuse the same cache directory as the normal ccache, there would
> be a huge risk that target ccache would use cached objects for the host...
> Nowadays we have the fingerprinting in place (which is hopefully still
> reliable), so the reason for have a separate cache dir is gone IMO. So I think
> we should just use CCACHE_DIR instead of BR_CACHE_DIR. BR2_CCACHE_DIR still
> makes sense, since you may want to encode a shared ccache in your Buildroot
> config. But I think it should default to empty, where empty means don't export
> CCACHE_DIR and rely on ccache's default.
Yes, I have also always been uneasy about these ccache patches - But I
normally don't use ccache, so I'm not sure how bullet proof the finger
printing is.
> Such a change, however, would first require a test to be set up. And testing
> ccache is decidedly non-trivial. Therefore it's a more long-term goal.
> Therefore, this patch makes sense after all. Indeed, if a user currently
> generates an SDK with the default configuration, it will definitely do the wrong
> thing (pointing to another user's br-ccache directory). So I'll change my weak
> NACK into a weak ACK.
Ok, thanks.
--
Bye, Peter Korsgaard
More information about the buildroot
mailing list