On Tuesday 18 January 2005 17:23, Stuart Herbert wrote: > On Tuesday 18 January 2005 15:13, Stuart Longland wrote: > > What exactly does confcache do? The above was literally: > > > > $ tar -xjvf /home/portage/distfiles/kdebase-3.3.1.tar.bz2 > > $ cd kdebase-3.3.1 > > $ time ./configure --cache-file=/tmp/kdebase-cache > > $ make distclean > > $ time ./configure --cache-file=/tmp/kdebase-cache > > $ time ./configure --cache-file=/tmp/kdebase-cache -n > > > > Isn't the third case what confcache would attempt to do? > > It does the second case. Don't see the point in doing the third, because > you still have to do the second one anyway when you build the package. > > Has the advantage that it safely maintains a cache for the entire box, and > knows when the cache is invalid and needs rebuilding. It was written > because configure is a major bottleneck for building packages on SMP boxes. > Oh, and because configure doesn't know how to manage its own cache file. To expand on what Stuart said: it uses portage's sandbox to determine what files affect configure's tests, stores their mtimes/checksums in its cache, and rebuilds the cache iff one of those files changes. It'd be a lot nicer if configure gave us an interface to run individual tests, so that we wouldn't have to flush the entire cache on every change; but in practice, when doing an 'emerge kde', it's quite effective.
-- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951
pgpJ6GAm0S0YQ.pgp
Description: PGP signature
