> On 2020-12-11-F, at 15:52, Chris Jones <[email protected]> wrote: > >> On 11 Dec 2020, at 7:23 pm, Christopher Nielsen <[email protected]> >> wrote: >> >>> On 2020-12-11-F, at 14:16, Chris Jones <[email protected]> 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 <[email protected]> >>>> 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.
