There hasn't been any problem using ccache when building ccache before. The only reason the problem now arose is that when the port was updated to version 4.4 6 days ago a dependency on the optional hiredis library was added and then when hiredis was updated to version 1.0.0 3 days ago its library version changed so ccache had to have its revision increased.
Using configure.ccache no in the ccache port ensures that the ccache port can be built if ccache is broken, and I suppose I'm not opposed to doing so since the ccache port does not take long to build so there is not a great benefit to using ccache when building it, but it does nothing to solve the general problem: any other port would still fail to build if ccache were broken. A user who has configured their MacPorts to use ccache still needs to be aware of the consequences of doing that, needs to be able to interpret the logs to discover that the reason for a build failure is a broken ccache, and needs to manually rebuild ccache in that case. MacPorts will not, for example, automatically try to rebuild ccache first before building anything else.
So it should be our goal to keep ccache from breaking in the future. Chris, any particular reason to add the hiredis dependency? And how likely do we imagine it is that hiredis will change its library version again? If we have no particular reason to add the hiredis dependency, or if it's likely that the library version will increase again and cause this breakage again, maybe we should backtrack and remove the hiredis dependency again.
