Mercurial > mm7
view lib/swig/swigwin-2.0.11/CCache/debian/README.Debian @ 2383:342b73a61a60
sub_407A1C - refactoring min-max
author | zipi |
---|---|
date | Sun, 22 Jun 2014 14:39:50 +0100 |
parents | b3009adc0e2f |
children |
line wrap: on
line source
Installing ccache ----------------- The recommended way to use this with Debian is to either create "cc" and "gcc" symlinks to /usr/bin/ccache in your private bin directory (which must be before the real cc and gcc in your path), or use CC="ccache gcc" on the make command line. Another option is to just prepend /usr/lib/ccache in your PATH environment variable, like export PATH="/usr/lib/ccache:$PATH" Note that ccache works with both native and cross compilers. Ignoring whitespace ------------------- If you wish to set up ccache so that it ignores blank lines, have a look at the CCACHE_UNIFY option. However, please note that this option is off by default since the reported line numbers may not match the source files anymore. NFS Issues ---------- (from John Coiner <john.coiner@amd.com> on the ccache mailing list) When CCache creates a hardlinked output file, it calls utime() to update the timestamp on the object, so that Make realizes that the object has changed. On NFS, utime() has no coherency guarantee, AFAIK. When utime() runs on host A, and our parallel implementation of Make is running on host B, sometimes Make doesn't see the new timestamp soon enough -- and neglects to relink the final binary. That's a one-way ticket to Silent Mysterious Failure Town. Instead of relying on the object file timestamp, we create a dummy file with a reliable timestamp: objs/foo.o objs/foo.o.built : if ( ccache gcc -o foo.o -c foo.c ) ; \ then touch objs/foo.o.built ; \ else exit 1; \ fi binary : objs/foo.o.built gcc -o binary objs/foo.o NFS does make a coherency guarantee, that if a file is written and close()d on host A, and subsequently open()ed on host B, that the second open() will reflect all modifications and attributes from the close(). Since Make does open() when checking timestamps, and the dummy file is close()d when it's created, the binary will always relink after the object is recompiled. -- Francois Marier <francois@debian.org> Sun, 20 May 2007 17:35:36 +1200