[MacPorts] #63419: ccache: use "configure.ccache no" (was: The ccache port should have "configure.ccache no")

[MacPorts]

#63419: ccache: use "configure.ccache no"
-----------------------+------------------------
  Reporter:  szhorvat  |      Owner:  ryandesign
      Type:  defect    |     Status:  assigned
  Priority:  Normal    |  Milestone:
 Component:  ports     |    Version:
Resolution:            |   Keywords:
      Port:  ccache    |
-----------------------+------------------------
Changes (by ryandesign):

 * owner:  (none) => ryandesign
 * cc: ryandesign (removed)
 * cc: cjones051073 (added)
 * status:  new => assigned


Old description:

> After the last update (just a rev bump, https://github.com/macports
> /macports-ports/commit/d6844634ee354f5e7709903b16f44312c28316ee),
> `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.

New description:

 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.

--

Comment:

 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
 [changeset:5f657dfd78cf566aeee30f571bc9afe2bd6c4da7/macports-ports updated
 to version 4.4] 6 days ago a dependency on the optional hiredis library
 was added and then when
 [changeset:1b199f0068917e5ecf7f9979206ba320e1cdd9d9/macports-ports hiredis
 was updated to version 1.0.0] 3 days ago its library version changed so
 [changeset:d6844634ee354f5e7709903b16f44312c28316ee/macports-ports 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/63419#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS