Greg Troxel <gdt%lexort.com@localhost> writes: > Martin Husemann <martin%duskware.de@localhost> writes: > >> On Tue, Dec 06, 2022 at 05:15:32PM +0100, Adam wrote: >>> > I think ccache has to work on most platforms, without dragging in new >>> > compilers, except that maybe NetBSD 8 is at the point of >>> > not-really-supported-at-all. >> [..] >>> It needs GCC>=8, c99, and c++17. Fixed. >> >> That makes the pkg a serious pain on netbsd-9. >> It should be downgraded, fixed, or versioned. > > Agreed, that's not really "fixed", and this upgrade should have been > discussed. > > In particular, ccache is needed most on slower machines which are less > likely to be able to cope with requirements for shiny c++. > > Of course the real bug is upstream; those are not reasonable > requirements (well c99 is fine) for a tool like this. > > Please revert, and feel free to add devel/ccache4 with the new version. And, the new ccache needs cmake, and that isn't marked to skip. I really meant revert, which is in my view the appropriate action for changes that should have been discussed and were not, when there are significant objections. I realize you didn't foresee these difficulties, but this is upstream going off the rails (cmake, c++17) and such an update requires discussion, especially in pre-freeze times. This wasn't explicitly on the 12/1 freeze list (now it is), but it's in the same class of build infrastructure for which problems make it hard to deal with fixing other things. As I asked before, please revert so that devel/ccache is as it was, and fel free to have ccache4, which is our normal pattern for adding new versions of things that have to be versioned. (It is obvious that we will have 3 and 4 both for a long time.) I do not want to deal with the churn in other dependencies and the perhaps long chain of consequences, and it's already the case that it is proving trickier to fix than expected.
Attachment:
signature.asc
Description: PGP signature