On 10/12/15 19:32, vkr wrote:
Sorry. It is not the manifest file that it tries to update. But the ".d"
files. I think it is a real bug.
In read-only mode, when ccache tries to run cache look up in
preprocessor mode, it tries to put_file_in_cache for .d file
unconditionally.
if
On 10/12/15 17:16, Anders Björklund wrote:
Andrew Stubbs wrote:
Most of the rest of the time is spent doing MD4. I have some ideas how
to optimize that (by sharing them across runs), but nothing ready to post.
I would be interested in your thoughts on how to speed that part up.
My
On 11/12/15 10:16, Andrew Stubbs wrote:
[*] The implementation was included in some editions of the Sourcery
CodeBench toolchain, so you can find them in the source package if you
really want to. I think you can find it here:
https://sourcery.mentor.com/GNUToolchain/release3047 (free
On 10/12/15 03:13, vkr wrote:
Hello Andew,
The answer is "no", because it is necessary to run the preprocessor in
order to fill the cache and record the file list that direct mode lookups
use.
What are the consequences if we don't let ccache record the file list, but
just run the preprocessor
Unless I'm missing something, the ccache sources are currently not
buildable. :-(
ccache.c: In function ‘put_file_in_cache’:
ccache.c:808:42: error: ‘struct conf’ has no member named ‘compress_level’
source, dest, conf->compression ? conf->compress_level : 0);
On 03/09/15 23:03, Robert Houghton wrote:
Is looks like ccache v3.2.1 will not use the CCACHE_BASEDIR option when
considering paths provided by -isystem. Is this intentional, an oversight,
or a bug?
I'd say it's not intentional. -I and -isystem differ only in the search
order, which shouldn't
On 23/07/15 22:28, Joel Rosdahl wrote:
(Sorry for the delayed reply, I have been on vacation.)
No problem; me too!
No no, doing an extra read of initial data is not needed. If something I
wrote implied that I must have been unclear.
OK, all clear now. I don't recall the exact code path for
On 05/07/15 16:47, Joel Rosdahl wrote:
Hi,
I did have a look at how feasible it is, and basically I think it
can be done.
Yes, caching failures (from the compiler, not the preprocessor) would be
feasible and I think that it's a good idea, at least as an optional feature.
I'm not very
On 30/06/15 15:30, Akim Demaille wrote:
Could ccache offer a mode where even failed compiled be ccached?
I'd like to see this too!
Or rather, I would have liked to see this on a project I worked on a
while ago. It's not really a common use case for most people, I'd
imagine, and not
On 12/11/14 20:22, Joel Rosdahl wrote:
Since the manual wasn't clear enough, what kind of information do you
think would be good to add to the How ccache works section?
Suggestions are very welcome.
FWIW, I think that any detailed description is too much for the user manual.
However, it might
On 19/08/14 01:35, Martín Cigorraga wrote:
I already set CCACHE_DIR to use my tmpfs /tmp/ccache directory:
~ echo $CCACHE_DIR
/tmp/ccache
You need to export the variable before it can be seen by programs other
than your shell.
I'm not familiar with fish shell, but there's a tutorial here:
On 15/01/14 16:16, Piotr Kiszka wrote:
I am trying to use ccache during kernel building.But there is always
zero cache hits during second kernel compilation:
I've observed this also. It's annoying!
The problem seems to be something in the way the kernel config
autogenerates the header files.
On 29/11/13 16:26, Lubos Lunak wrote:
So I think actually CCACHE_CPP2 set is the normal way and _not_ having it set
can be considered to be a performance hack.
This is an interesting idea. The split preprocess-compile is, indeed,
the most common pain-point in my experience.
That said, it
On 20/10/13 10:18, Joel Rosdahl wrote:
bug?
Yes, see the discussion on
http://www.mail-archive.com/ccache@lists.samba.org/msg00920.html.
By the way: I'm still torn on what to do, but I'm leaning towards keeping
direct mode on by default (documenting the behavior, of course).
I've thought
On 09/10/13 22:05, Joel Rosdahl wrote:
The ccache version included with Ubuntu (and Debian), claims to be
version 3.1.9 [...] it lacks the -o and -p options [...]
The new config handling, including the -o and -p options, is part of the
development branch and hasn't been released yet.
Hi,
The ccache version included with Ubuntu (and Debian), claims to be
version 3.1.9, but it doesn't look very similar to the upstream version.
In particular, it lacks the -o and -p options, and appears to handle the
config files very differently.
What is the relationship between the two
On 01/01/13 17:19, Joel Rosdahl wrote:
By the way, the patch is missing some headers, so git am doesn't
understand it. I suggest using git format-patch instead of git
diff for generating future patches.
I thought I did? Thunderbird likes to wrap inline patches, so I used the
attachment
I'm going to have to withdraw the suggestion, at least until
I've looked at it more closely.
Andrew
On 20/11/12 21:51, Andrew Stubbs wrote:
Hi all,
This isn't meant to be a final patch, but more of a starting point up
for discussion. Before it's a finished patch it'll need some autoconf
work
implementation otherwise.
Note that the compiler will always inline calls to memcpy for small
byte-counts, so this is a big win.
Signed-off-by: Andrew Stubbs a...@codesourcery.com
---
configure.ac |2 ++
mdfour.c |8
2 files changed, 10 insertions(+)
diff --git a/configure.ac b
.)
In addition to just being nice-to-have on its own, this might also open
up some previously-too-expensive possibilities for fixing the flaws in
direct-mode caching, or even making improvements.
Thoughts?
Andrew
From 6522b925ae2631c50e7c6dd841f172377a19239f Mon Sep 17 00:00:00 2001
From: Andrew
On 12/11/12 14:08, Bogdan Harjoc wrote:
No but there is room for improvement. This could be optional, like a
CCACHE_COMPRESS that saves 99% instead of 40% when I routinely recompile 20
kernel branches, for example (v2.6.x, 3.0.x, 3.4.x, -git, -next, -ubuntu,
etc).
I realise that the more
On 06/11/12 16:53, Eitan Adler wrote:
Perhaps you should get a better version of env?
Perhaps I should! I'm running Ubuntu 12.10, so I'm surprised about that.
But even if I did there would be many others with the same issue.
The followup to this discussion indicates that /bin/sh seems to
On 05/11/12 17:58, Eitan Adler wrote:
-#!/bin/sh
+#!/bin/bash
This line is buggy:
please http://blog.eitanadler.com/2012/10/binbash-considered-harmful.html
for why.
I ideally the non-portable bashims get fixed but if not the shebang
line must be /usr/bin/env bash not /bin/bash.
While it is
On 05/11/12 22:35, g@free.fr wrote:
ccache-3.1.8 'make check' work with dash, no?
There's no problem with configure or make, only with test.sh.
Andrew
___
ccache mailing list
ccache@lists.samba.org
On 06/11/12 10:05, g@free.fr wrote:
On my debian stable machine (x86 32 bits), I set sh as a symlink to dash and
changed my script to emit SHELL='/bin/dash'
test is ok with 3.1.8 (ccache is statically linked to glibc in my
configuration).
I looked with checkbashims on test.sh git version
On 04/11/12 19:10, Joel Rosdahl wrote:
The direct mode, which was introduced in version 3.0 almost three years
ago, has a design bug. The essence of the problem is that in the direct
mode, ccache records header files that were used by the compiler, but it
doesn't record header files that were
On 04/11/12 19:10, Joel Rosdahl wrote:
Since a quick fix likely isn't possible in the short term, and I would like
to release ccache 3.2 soon, we have to decide whether the direct mode
should default to off or on. Please share any opinions!
Incidentally, you appear to have committed a patch
The test script fails with shells other than bash. At least dash
doesn't work.
Signed-off-by: Andrew Stubbs a...@codesourcery.com
---
test.sh |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test.sh b/test.sh
index 4c78617..a334f62 100755
--- a/test.sh
+++ b/test.sh
On 04/11/12 16:25, Justin Lebar wrote:
Here's the last patch I got. Gmail tells me it was also sent to the
list; maybe it somehow got filtered.
I /think/ I'm including the attachment here...
That one look right to me.
Andrew
___
ccache mailing
8805b9c30df98fb297be259700e703799b067731 Mon Sep 17 00:00:00 2001
From: Andrew Stubbs a...@codesourcery.com
Date: Tue, 9 Oct 2012 15:17:19 +0100
Subject: [PATCH] Detect __DATE__ and __TIME__ correctly.
To: ccache@lists.samba.org
The code to detect __DATE__ and __TIME__ was off-by-one, and therefore
totally failed to detect
Hi Joel,
I've encountered a bug while playing with ccache: temporal macros are
not detected correctly.
Patch attached.
Andrew
From ada18fd6326c54fdb08ec1f66c923b9c601aa00e Mon Sep 17 00:00:00 2001
From: Andrew Stubbs a...@codesourcery.com
Date: Mon, 8 Oct 2012 13:14:40 +0100
Subject: [PATCH
On 04/10/12 01:50, Shentino wrote:
Would snooping on the compiler's own error messages help weed out
transient failures like out of memory, disk full, and so on?
I recently compiled webkit-gtk and it managed to exhaust all of my
memory AND swap.
This does raise an interesting choice!
On the
On 22/09/12 13:13, Joel Rosdahl wrote:
On 18 September 2012 14:16, Andrew Stubbs a...@codesourcery.com wrote:
I'm aware that there's some danger here that we can end up caching Ctrl-C
interrupts, SIGTERM/SIGKILL terminations, out-of-memory failures, and all
manner of other non-reproducible
On 18/09/12 22:59, Mike Frysinger wrote:
the linker's --build-id and associated .note.gnu.build-id section. you can't
hash the entire object because it can change between compiles. build-id lets
you say regardless of the hash of the entire object, we know the content that
matters is unchanged.
34 matches
Mail list logo
