On Tuesday 18 September 2012 17:07:53 Andrew Stubbs wrote:
> On 18/09/12 21:04, Mike Frysinger wrote:
> > On Tuesday 18 September 2012 08:44:29 Andrew Stubbs wrote:
> >> Clearly there are some technical challenges in doing this: we'd have to
> >> hash all the object files and libraries (a la direct
On 18/09/12 21:04, Mike Frysinger wrote:
On Tuesday 18 September 2012 08:44:29 Andrew Stubbs wrote:
Clearly there are some technical challenges in doing this: we'd have to
hash all the object files and libraries (a la direct mode), but those
problems are surmountable, I think.
or just re-use b
On Tuesday 18 September 2012 08:44:29 Andrew Stubbs wrote:
> Clearly there are some technical challenges in doing this: we'd have to
> hash all the object files and libraries (a la direct mode), but those
> problems are surmountable, I think.
or just re-use build-id ...
> The linker does not use
On 18/09/12 16:37, Justin Lebar wrote:
ldcache would hash object files and spit out linked files. It would
use an entirely separate cache. Its handling of command-line options
would be entirely different. Its processing of input files would be
entirely different. ISTM that very little would b
Hi,
I needed the following patch for ccache to build with clang. Without
this I get the following error:
[7905 eitan@radar ~/svn/ccache ]%gmake
(git)-[master]-
clang -DHAVE_CONFIG_H -DSYSCONFDIR=/usr/local/etc -I. -I. -MD -MP
-MF .deps/main.c.d -g -O2 -Wall -W -Werror -c -o main.o main.c
clang
On 18/09/12 15:34, Justin Lebar wrote:
I'm looking at ways to improve compile speed, and one obvious option is to
cache compile failures. I'm thinking of certain non-called-for-link autoconf
tests, in particular.
Doesn't autoconf have a cache of its own?
Yes, but only for repeated config test
> What I'm looking for is more concrete
> roadblocks I haven't considered.
You'd basically have to rewrite all of ccache.
ccache hashes header files and spits out object files.
ldcache would hash object files and spit out linked files. It would
use an entirely separate cache. Its handling of c
On 18/09/12 15:31, Justin Lebar wrote:
So, again, before I waste my time implementing this feature, are there any
other fundamental gotchas that would prevent it ever working or ever being
useful?
On a large project with many inputs to ld, you'd have to hash a /lot/
of object files, increasing
> I'm looking at ways to improve compile speed, and one obvious option is to
> cache compile failures. I'm thinking of certain non-called-for-link autoconf
> tests, in particular.
Doesn't autoconf have a cache of its own?
Anyway, ccache makes running the compiler faster. In the cause of
giving t
> So, again, before I waste my time implementing this feature, are there any
> other fundamental gotchas that would prevent it ever working or ever being
> useful?
On a large project with many inputs to ld, you'd have to hash a /lot/
of object files, increasing the overhead of ccache substantially
Hi all, again,
I've just posted about improving compile speed by caching compiler
failures, and in the same vein I'd like to consider caching
called-for-link compile tasks.
This is partly interesting for the many small autoconf tests, but is
also increasingly interesting for real compilation
Hi all,
I'm looking at ways to improve compile speed, and one obvious option is
to cache compile failures. I'm thinking of certain non-called-for-link
autoconf tests, in particular.
I'm aware that there's some danger here that we can end up caching
Ctrl-C interrupts, SIGTERM/SIGKILL terminat
12 matches
Mail list logo
