No subject

cache across all developers than to set up a single cache for each
subproject team. Also, in the above example, subprojects C and D have
the same configuration and so could actually use the same cache.
=20
My issue is that the real scenario is much more complex, with each
subproject being comprised many components, which in turn are components
etc. So identifying the configurations is not trivial. I suspect that in
reality, each project has some compilation in common with some of the
other projects, but it's hard to tell which. So if ccache can cope with
using a network-shared cache, then having one single (large) cache would
give maximum efficiency across all the projects, as any
cache-partitioning I impose (per-project or per-developer or
per-machine).
=20
I hope that makes sense, but I don't know how ccache actually reads the
cache. In effect, is it safe to use the same shared cache on multiple
machines? If not, then is it safe to run a parallel build (e.g. make -j
2) on a local machine with a local cache, as presumably that has the
same implications wrt. multiple concurrent cache updates.
=20
Thanks for your help!
=20
Tom


________________________________

	From: Vincent Dupuis [mailto:vincedupuis at hotmail.com]=20
	Sent: 25 September 2009 13:18
	To: Dalton, Tom
	Cc: ccache at lists.samba.org
	Subject: RE: [ccache] Build Safety
=09
=09
	Hi, and welcome to ccache!
=09
	> Date: Fri, 25 Sep 2009 10:22:14 +0200
	> From: tom.dalton at eds.com
	> To: ccache at lists.samba.org
	> Subject: [ccache] Build Safety
	>=20
	> Hi,
	>=20
	> I think I know the answer to this question, but I want a
second opinion!
	>=20
	> In the past, I have used the Clearcase version control system,
which has
	> it's own make system, clearmake. Clearmake provides some build
caching
	> functionality (which it terms wink-ins), that allows it to
'wink-in'
	> build objects from other users views. I have experienced a lot
of
	> problems with this system, because clearcase wouldn't detect
that two
	> users were building the same file in a different environment
(e.g.
	> external libraries at different versions. This caused me all
sorts of
	> issues.
=09
	That's why it is not very used.
=09
	> Is it possible for inconsistent environments between builds to
cause
	> ccache to incorrectly use a cached object instead of
recompiling? For
	> example, different builds of gcc, different external libraries
etc? What
	> circumstances could cause this?
=09
	for each compile ccache makes a key with the following
information:=20

		1. the pre-processor output from running the compiler
with -E=20
		2. the command line options=20
		3. the real compilers size and modification time=20
		4. any stderr output generated by the compiler

	if something changes then it recompiles and recache the new
key/.o
	so if you use a different external librairies, #1 and maybe #2
can change.
=09
	> Secondly, if there is not much that can break ccache, is it
possible to
	> use a shared cache (e.g. on an nfs-shared disk) to allow many
users on
	> many hosts to cache build results across several versions of a
single
	> product? (which will mean different gcc versions, libraries,
even
	> kernels.)
=09
	if each users use different gcc versions, libraries, even
kernels, then
	sharing the cache is not useful. It's better to use it locally.
Try to compile
	your product from scratch witch ccache and recompile (clean
before) and=20
	compare the time. (ie: time make all). Here is my current stats
at this moment:
=09
	cache directory
/home/vince/projects/raaf/ccache
	cache hit                          16462
	cache miss                         11307
	called for link                       70
	compile failed                        63
	preprocessor error                     4
	not a C/C++ file                    1198
	files in cache                      8779
	cache size                         793.5 Mbytes
	max cache size                     976.6 Mbytes
=09
	like you see, I skip compilation of 16462 files locally.
=09
=09
	> Thanks for your help - ccache sounds really useful, but I want
to make
	> sure there's no 'traps'!
	>=20
	> Thanks,
	>=20
	> Tom
	> _______________________________________________
	> ccache mailing list
	> ccache at lists.samba.org
	> https://lists.samba.org/mailman/listinfo/ccache
=09
=09
________________________________

	Naviguez plus vite avec Internet Explorer 8 Ici.
<http://go.microsoft.com/?linkid=3D9655263> =20