ccache: use "configure.ccache no"

[szhorvat (Szabolcs Horvát)]

After the last update (just a rev bump, [d6844634ee354f5e7709903b16f44312c28316ee/macports-ports]), ccache failed to build for me. It turns out that this happened because I had configureccache yes in my MacPorts configuration, so building ccache tried to use ccache itself. However, entire reason ccache had to be updated (actually just rebuilt) was that it became broken due to a library update. The error was:

dyld: Library not loaded: /opt/local/lib/libhiredis.0.14.dylib

Suggestion:

Please disable using ccache when building ccache itself, to avoid this kind of trouble in the future.

[ryandesign (Ryan Carsten Schmidt)]

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.

[ryandesign (Ryan Carsten Schmidt)]

For example, I note that, troublingly, the hiredis library install name is now /opt/local/lib/libhiredis.1.0.0.dylib. In other words, it looks likely that even a minor version update of the hiredis port would result in a new install name and necessitate a revbump of ccache and other dependents. It calls into question whether the developers of hiredis understand how library versioning is supposed to be done.

[ryandesign (Ryan Carsten Schmidt)]

Seems like hiredis also has a CMake-based build system. Maybe using it would result in a different (more stable) install name. (If so, that would be a bug to report to the developers.) There is discussion in ​this hiredis bug report about the (non-CMake) Makefile being problematic.

[ryandesign (Ryan Carsten Schmidt)]

The update of hiredis to 1.1.0 2 days ago again broke ccache (and everything else that uses hiredis) because of the library name change and the failure to revbump everything that linked with it. See #66443.