Den 2015-12-07 kl. 04:48, skrev Mike Frysinger: > On 02 Dec 2015 20:16, Pierre Tardy wrote: >>> i don't think getting rid out of the fs makes sense, but having memcache >>> be available dynamically as an additional layer sounds fine.. >> >> It does make a lot of sense for me as I have a high performance network, >> which is faster than local harddrive. So I would insist on keeping an >> option for memcached only. > > that isn't what i meant. i don't care about runtime config options but > about (1) the code and (2) build time control. fs should remain in the > source and memcache should be an additional configure flag which allows > the user to select it at runtime.
That is the way that it currently works. There is now a --enable-memcached flag, to avoid libmemcached being a mandatory requirement. In the code, it uses a #ifdef HAVE_LIBMEMCACHED But it still doesn't really *do* anything, unless you also set the configuration for memcached_conf (containing for instance --SERVER). Then there is a *second* boolean option, now called memcached_only, that only uses the regular cache for manifests and for stats / conf. So if that is set, it will avoid storing objects and friends in the file system cache but only store those in the memcached servers... Note that the use of binary packages (rather than using source ports) usually ends up just picking one of the options for you anyway ? So in that sense it's "better" to have it selectable at runtime, and for the feature to be there (by default). Otherwise it is "gone". Squashed everything, PR coming shortly. /Anders _______________________________________________ ccache mailing list firstname.lastname@example.org https://lists.samba.org/mailman/listinfo/ccache