[ccache] Using ccache with memcached

[Anders Björklund]

Pierre Tardy wrote:

>>     Here is such an attempt, to keep *both* features available:
>>     https://github.com/itensionanders/ccache/tree/memcached-only
>
> I like it very much. I think it adds great value for ccache, and to my
> old memcached-only attempt.

Yeah, if it doesn't bloat the code base too much it makes sense to
leave the final decision up to the user with runtime configuration.

> I did not realize the use for moxi also as a connection "keep-alive"
> mechanism, and a way to hide the syn-ack latency overhead. I think this
> is what you mean by "avoid some of the network overhead." .This perhaps
> would deserve a little bit more details in the doc.

Right, that is what I meant. Think it depends a bit on the number
of servers involved, but I don't think it can hurt much either way.
Suppose another paragraph or two couldn't hurt, but the more advanced
config can remain with memcached and moxi documentation - I think ?

However, it does make a lot of sense to offer the "complete package"
and is something that we are looking into. Software and configuration.
For us that would entail ccache*, moxi, distcc, memcached and distccd.
So it spans at least three or four different open source projects.

* including zlib and libmemcached

> Even if it is not ready, I think it would be worth to create a pull
> request, and make it easier for everybody to review the current code.
>
> This is what I used to do it, but its not easy to put and track review
> comments.
> https://github.com/jrosdahl/ccache/compare/master...itensionanders:memcached-only

Yes, that works for testing. You can append a .diff or a .patch to it,
and use "diff" or "git am". But that's more read-only, and not social.

I wanted to do some more squashing and rebasing to "master" - but I 
suppose there is no reason why all that couldn't be done as a PR...

> Mike already put a bunch of coding style review comments on my own
> commits. I would rather not fix them myself, as I know you already have
> an evolved version which is more suitable for merging.

I think some of these might also have been fixed by "uncrustify" ?

/Anders