CCache: Segregating cache directories per port

[Christopher Nielsen]

> On 2020-12-11-F, at 15:52, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
> 
>> On 11 Dec 2020, at 7:23 pm, Christopher Nielsen <mascguy at rochester.rr.com> wrote:
>> 
>>> On 2020-12-11-F, at 14:16, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>>> 
>>> Just curious, but what exactly is the advantage of doing this? I am not sure i see what problem you are trying to solve that a single cache causes.
>>> 
>>>> On 11 Dec 2020, at 6:20 pm, Christopher Nielsen <mascguy at rochester.rr.com> wrote:
>>>> 
>>>> Is it possible to easily override the ccache directory via command-line, with the goal of maintaining separate caches per port?
>>>> 
>>>> I did some quick digging through the MacPorts TCL files, and didn’t see support for such an override.
>>>> 
>>>> My current solution — workable, though not ideal — is to update ‘ccache_dir’ in ~/.macports/macports.conf. That’s easily doable via a ‘port’ wrapper script.
>>>> 
>>>> But assuming I didn’t miss anything, would folks be open to having the ability to specify ‘ccache_dir’ from the port command-line? If so, I’ll contribute the changes.
>>>> 
>>>> Thoughts?
>> 
>> In short, I’d like to maintain separate caches for ports I’m working on — Mame being the best example, as it takes at least an hour to build locally — without the cache being flooded by other ports. And preferably without resorting to custom ccache configuration, etc.
>> 
>> Make sense?
> 
> Honestly, not really. Ccache can easily handle multiple concurrent builds to a single cache directory, and you can trivially increase the size of the cache if thats your problem, so I still don’t see what issue you are referring to by ‘being flooded by other ports’ as I don't see really what issue there would be having build artefacts in a single cache for more than one port.

Chris, I appreciate healthy skepticism. Particularly given that I’m relatively new to the maintainer party.

So, let me provide a few more reasons why this is important to me... and how it could also be tremendously useful to our fellow maintainers.

With segregated caches:
* There's absolutely no possibility of clashes or ill effects between ports — or between revisions of the same port — without depending on ccache's prevention measures. While there's no doubt that ccache is quite mature and reliable, it’s not infallible.
* It’s easy to maintain/archive caches that are critical to speeding up workflow, which are also as small as possible.
* It’s easy to clean the other cache(s) that aren’t critical, eliminating unnecessary bloat and disk usage.

Without segregation:
* There’s that pesky risk of clashes.
* The cache either grows without bounds (if sized large enough), or the critical items end up being aged out of the cache prematurely.
* You end up archiving a massive amount of cruft, most of which you neither need nor care about… because everything is stuffed into one massive pile of storage.

Does that help?

Again, I appreciate the skepticism. But on the flip side, I’ve probably spent 45+ minutes responding to the various skepticism… versus 5 minutes on the proposed enhancement. And the latter 5 minutes includes testing locally, as well as pushing the change to GitHub. LOL

Also note that we already have other developer-focused command-line overrides, so this isn’t a new concept.