cvs commit: src/lib/libarchive archive_private.h archive_read.c archive_read_data_into_fd.c archive_write.c archive_write_set_compression_bzip2.c archive_write_set_compression_gzip.c archive_write_set_compression_none.c

[Maxim Sobolev]

Dag-Erling Smørgrav wrote:
> Maxim Sobolev <sobomax at portaone.com> writes:
> 
>>Therefore, IMHO, the only realistical approach is to improve
>>tinderboxes to minimize detection window (i.e. faster, multi-CPU
>>hardware and/or tools like ccache) and to make breakage information
>>delivery more direct.
> 
> 
> Faster, multi-CPU hardware will not help.  The tinderbox is
> constrained by memory bandwidth, not CPU speed.  A cluster of seven
> $200 Mini-ITX boxes can do a full -CURRENT tinderbox run in two or
> three hours, vs. eight to ten hours on a single $1400 box.
> 
> Ccache won't help either, because buildworld always starts by building
> a new toolchain, which invalidates the cache.

Yes, but ccache can be easily extended to make it useable for 
buildworlds. Currently it uses path to, last modification time of (and 
probably size of) the compiler binary to decide validity of existing 
cache, which is not very intelligent check. I've verified that albeit 
they have different modification times (obviously), every buildworld 
produces compiler binaries with the same MD5 checksum. Therefore ccache 
can be extended to keep table with four values {path, modtime, size, 
MD5} for each compiler binary, so that it can lookup the MD5 checksum 
based on path, modtime and size of compiler binary and the use that MD5 
for deciding upon validity of the cache.

-Maxim