[ccache] environment variable for maxsize ?

[Mike Frysinger]

On Wed, Mar 19, 2008 at 6:15 PM, Bogdan Harjoc  wrote:
> You are perhaps referring to the variable that gentoo's portage [1]
> accepts (and passes to ccache as an option).

it was my understanding that ccache respected this.  didnt realize we
were hacking around the limitation in Gentoo by faking out the env var
-> cmdline opt.
-mike

[ccache] environment variable for maxsize ?

[Mike Frysinger]

On Wed, Mar 19, 2008 at 4:48 PM, Bogdan Harjoc  wrote:
>  Is the fact that the cache size limit is only configurable as a
>  commandline option intentional ? There seem to be environment
>  vars for virtually everything else but this.

use CCACHE_SIZE
-mike

[ccache] new ccache maintainer

[Mike Frysinger]

On Sun, Jan 17, 2010 at 18:27,   wrote:
> ?> could we get a "ccache" product on https://bugzilla.samba.org/ ?
> ?> there's a long standing issue with .i files i reported a while ago ...
>
> yep, I think that will be part of the new revitalised ccache project :-)
>
> My apologies for being such a slack maintainer. I think Joel will be a
> big improvement!

sorry, i didnt mean for it to sound that way.  i wanted to make sure
there was a place for us to start posting patches/etc... that would be
saved until processed.
-mike

[ccache] new ccache maintainer

[Mike Frysinger]

On Sun, Jan 17, 2010 at 17:56,   wrote:
> I'm happy to announce that Joel Rosdahl will be taking over as the
> ccache maintainer.
>
> I've been far too slack with ccache maintainence lately, and I'm very
> happy with the quality of the work that Joel has been doing in his
> private branch. I think Joel is the right person to look after ccache
> and make sure it continues to develop.
>
> It will take us a few days to update the website and do a few admin
> things. For example, Joel will be moving ccache to git (probably
> hosted on git.samba.org).
>
> Many thanks to Joel for volunteering!

could we get a "ccache" product on https://bugzilla.samba.org/ ?
there's a long standing issue with .i files i reported a while ago ...
-mike

[ccache] Collecting and merging unofficial patches (was environment variable for maxsize ?)

[Mike Frysinger]

On Wed, Mar 19, 2008 at 7:22 PM, Francois Marier  wrote:
>  In fact if maintainers from other distros (Gentoo perhaps?) want to help
>  out and share some of their changes, that'd be great.

we only have two:
http://sources.gentoo.org/dev-util/ccache/files/
-mike

[ccache] using ccache with a cross-compiler fails to compile preprocessed output

[Mike Frysinger]

ive been using ccache with my cross-compilers but i just came across a
situation where ccache is causing problems

$ cat test.i
typedef __blkcnt_t blkcnt_t;
$ bfin-uclinux-gcc -c test.i
bfin-uclinux-gcc: ??`: No such file or directory
bfin-uclinux-gcc: no input files
$ bfin-uclinux-gcc -c test.i --ccache-skip
test.i:1: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'blkcnt_t'


-mike

Re: [ccache] Compression on or off by default?

[Mike Frysinger]

On Tue, Mar 2, 2010 at 17:10, Joel Rosdahl wrote:
> Lars Gustäbel's compression patch (which will be incorporated in ccache 3.0)
> enables compression by default, and if you don't want compression you have to
> set CCACHE_NOCOMPRESS. I'm still a bit undecided about whether defaulting to
> compression is a good idea, though. Maybe we should be more conservative here
> and require CCACHE_COMPRESS to be set to enable compression instead? (Note 
> that
> the question only is about the default behaviour when storing files in the
> cache -- ccache will still be able to read compressed and uncompressed files
> from the cache regardless of the CCACHE_(NO)COMPRESS setting.)
>
> The main argument I see for making compression opt-in is that hard-linking
> doesn't work for compressed files (where "doesn't work" means that ccache will
> fall back to copying), so if you would like to try out hard-linking, you must
> set both CCACHE_NOCOMPRESS and CCACHE_HARDLINK, and also build up the cache
> again. Or, if you currently have enabled hard-linking with ccache 2.4, you 
> need
> to take the explicit action of disabling compression after an upgrade to get
> the previous behaviour.
>
> Another argument is maybe that disk space is cheap nowadays, and most people
> probably want to optimize for speed instead of disk space. On the other hand,
> the overhead of using compression is very small. In fact, I am unable to
> consistently measure any performance impact whatsoever. (Lars Gustäbel's own
> measurements can be found at .) And, by
> compressing the cached files, more files will fit in the cache and also in the
> OS disk cache.
>
> Does anyone have an opinion to share about this?

make the default a ./configure option that defaults to off
-mike
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] Compression on or off by default?

[Mike Frysinger]

On Thu, Mar 4, 2010 at 16:00, Joel Rosdahl wrote:
> On Wed, 3 Mar 2010 05:00:48 -0500 Mike Frysinger wrote:
>> make the default a ./configure option that defaults to off
>
> I would prefer not to make a build-time option of this, because then the
> documentation has say something in line with "whether files are compressed by
> default depends on how ccache was built", which I think would be unfortunate. 
> I
> chose to not include the --{en,dis}able-zlib option from the original patch 
> for
> the same reason. I think it's better to strive for good defaults and few
> build-time options.

i didnt mean the configure option was in place of the runtime knobs

regardless, unless the compression is very low overhead, the default
should be off
-mike
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] [patch] Massive performance degradation with direct mode due to bypassing filesystem cache with mmap (Mac/PPC)

[Mike Frysinger]

On Wed, Aug 25, 2010 at 16:24, Joel Rosdahl wrote:
> On 2010-08-23 13:35, Christian Lohmaier wrote:
>> [...] Using mmap [on Mac/PPC] to load all the include files bypasses
>> the filesystem cache [...]
>
> Ouch. That surprises me. Thanks for telling!
>
> The reason I chose mmap() instead of read() was mainly that the C
> "parser" (that basically knows about C/C++ comments and string literals)
> was easier to write under the assumption that it has access to the whole
> file as a string and I figured that it would be better to mmap() than to
> read the whole file into memory (or at least not worse). I didn't
> perform any benchmarks to back up that choice, though. Now I've done
> some tests, and it seems that on my 64-bit Linux system, mmap() is
> slightly faster for (very) large files, but for smaller files, I can't
> measure any real difference consistently. I assume that reading the
> whole file into memory instead of using mmap() isn't considerably slower
> on other systems too, so I'll make ccache do that.

perhaps abstract the file i/o away so people can switch between mmap
and stdio at build time.  as you say, i imagine mmap makes coding
easier to work with, which means the resulting code is simpler.  but
for OS's where mmap blows because their filesystem stack blows,
default to stdio.
-mike
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] PATCH: Fix version.c for older gits

[Mike Frysinger]

On Fri, Sep 24, 2010 at 14:46, Wilson Snyder wrote:
> -    $(shell (git describe --dirty 2>/dev/null || echo vunknown) \
> +    $(shell (git describe --dirty 2>/dev/null || git describe 2>/dev/null || 
> echo vunknown) \

probably better to move the stderr outside of the subshell:
   $(shell (git describe --dirty || git describe || echo vunknown)
2>/dev/null \
-mike
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] Could ccache handle the input as .o file as well as source file.

[Mike Frysinger]

On Mon, Mar 14, 2011 at 23:17, xiaoxiao wrote:
> I've been using ccache recently, in order to decline the compilation
> time for a certain module. In this module, with the help of the greatest
> ccache, the time could be shorten to 5 mins from 40 mins without any
> modification. However, even if the output of all the source files are
> cached, we have to take about the 5 mins mainly in the linking action,
> eg: a.o -> test_a(exetuable). Since I have noticed that ccache do not
> take the .o file as a input to be cached. The actions as linking would
> certainly not be ccached, and thus the time for linking would not
> significant reduced.
> Given this background, I have a few questions to talk about. Have anyone
> ever considered to build up a mapping between .o file and its output? If
> so, why ccache did not provide such feature. If not, do you think it is
> a reasonable feature for ccache to reduce the time for linking in a
> compilation?

try switching to gold
-mike
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] Could ccache handle the input as .o file as well as source file.

[Mike Frysinger]

On Mon, Mar 14, 2011 at 23:56, xiaoxiao wrote:
> 于 2011/3/15 11:33, Mike Frysinger 写道:
>> try switching to gold
>
> Sorry, but what do you mean?

please dont top post

get latest binutils and use `ld.gold` instead of just `ld`.  there is
also some gcc flag to control which one is invoked, but i forget what
it is.
-mike
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] Suggested patch to add local strtok_r for systems lacking it

[Mike Frysinger]

On Thursday 12 April 2012 02:32:39 Jürgen Buchmüller wrote:
> here's a suggested patch for config.h.in and util.c to add a local
> implementation of strtok_r for systems that don't have it (e.g. mingw32
> plus libgw32c).

sounds like we should just integrate gnulib instead of open coding all of our 
own compatibility layers
-mike


signature.asc
Description: This is a digitally signed message part.
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] Making ccache and clang compatible

[Mike Frysinger]

On Wednesday 04 July 2012 09:53:46 Max Horn wrote:
> Using ccache with clang tends to generate tons of warnings, which can range
> from simply being annoying, to causing autoconf failures. This is because
> ccache runs the compiler with "-E" on preprocessed input, but also passes
> -I, -isystem etc. flags on to the compiler. In clang, this triggers
> warnings about unused arguments.

err, -I/-isystem/-D/-U/etc... are preprocessor flags and are valid when running 
in preprocessor mode (-E).  i don't know if clang is broken, or your analysis 
is incorrect, but certainly that behavior you describe is wrong.
-mike


signature.asc
Description: This is a digitally signed message part.
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] Why not cache link commands?

[Mike Frysinger]

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 any libraries not listed with "gcc '-###' whatever".

mmm different gcc flags can implicitly expand into -l### or different crt 
objects, so you can't cache linking at the compiler driver level w/out re-
implementing much of the guts of gcc, and even then you'd break with 
moderately patched gcc versions.

> I'm also aware that it's not that interesting for many incremental
> builds, where the final link will always be different, but my use case
> is accelerating rebuilds of projects that my have many outputs, most of
> which are likely to be unaffected by small code changes. It's also worth
> noting that incremental builds are not the target use case for ccache in
> general.

gold should already support incremental linking (ala build-id), so i don't 
think that's already a fixed problem
-mike


signature.asc
Description: This is a digitally signed message part.
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] Why not cache link commands?

[Mike Frysinger]

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 mode), but those
> >> problems are surmountable, I think.
> > 
> > or just re-use build-id ...
> 
> Sorry, I'm probably being thick, but what do you mean?

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".

> >> The linker does not use any libraries not listed with "gcc '-###'
> >> whatever".
> > 
> > mmm different gcc flags can implicitly expand into -l### or different crt
> > objects, so you can't cache linking at the compiler driver level w/out
> > re- implementing much of the guts of gcc, and even then you'd break with
> > moderately patched gcc versions.
> 
> "-###" isn't meant to be a wildcard. That's an actual GCC option. I put
> quotes around it because most shells would interpret the hashes as the
> start of a comment.

hmm, gotcha.  it does seem to include all the necessary info.  whether it's 
easy for a machine to parse across gcc versions is a diff question :).  seems 
to have changed subtly over time between 3.3.6 and 4.7.1.

> >> I'm also aware that it's not that interesting for many incremental
> >> builds, where the final link will always be different, but my use case
> >> is accelerating rebuilds of projects that my have many outputs, most of
> >> which are likely to be unaffected by small code changes. It's also worth
> >> noting that incremental builds are not the target use case for ccache in
> >> general.
> > 
> > gold should already support incremental linking (ala build-id), so i
> > don't think that's already a fixed problem

err, typo here.  s/don't//.

> As I said, the interesting use case is *not* incremental links. The
> interesting use case is accelerating "clean" builds. ccache can never
> help where genuinely new inputs are involved.

right, i was just agreeing with you and providing more details as to how it 
already works today.
-mike


signature.asc
Description: This is a digitally signed message part.
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] [PATCH] Use bash for test.sh.

[Mike Frysinger]

On Tuesday 06 November 2012 11:53:12 Eitan Adler wrote:
> On 6 November 2012 04:54, Andrew Stubbs  wrote:
> > While it is true that "/usr/bin/env bash" is more portable than
> > "/bin/bash", I also don't like it as much.
> > 
> > If I run a "#!/bin/bash" script without bash installed I get:
> >   /bin/bash: bad interpreter: No such file or directory
> > 
> > If I try the same with "#!/usr/bin/env bash" I get:
> >   /bin/env: bad interpreter: No such file or directory
> 
> Perhaps you should get a better version of env?

ironic considering you're espousing a change to support crap systems that 
aren't relevant.  if the script is written in bash and is intended to be, then 
/bin/bash is the correct answer.  if the script is intended to be POSIX shell, 
then /bin/sh is the correct answer.  using env is just stupid.
-mike


signature.asc
Description: This is a digitally signed message part.
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] [PATCH] Use bash for test.sh.

[Mike Frysinger]

On Monday 05 November 2012 12:55:10 Andrew Stubbs wrote:
> The test script fails with shells other than bash. At least dash
> doesn't work.

could you post the exact errors you see ?  i see old style portable code in 
there that could easily be modernized to recent POSIX and plenty of quoting 
issues, but i don't see anything off hand that wouldn't work in a POSIX 
compliant shell.
-mike


signature.asc
Description: This is a digitally signed message part.
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] [PATCH] Use bash for test.sh.

[Mike Frysinger]

On Saturday 10 November 2012 00:41:52 Eitan Adler wrote:
> On 10 November 2012 00:41, Mike Frysinger wrote:
> > if the script is written in bash and is intended to be, then
> > /bin/bash is the correct answer.
> 
> Absolutely false. /usr/local/bin or /opt/bin might be the correct location.

if you have a crap system where bash isn't installed with /bin/bash, then you 
already have a ton of problems with existing software.  forcing stupid 
behavior on everyone to cater to broken systems is wrong.
-mike


signature.asc
Description: This is a digitally signed message part.
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] [PATCH] Use bash for test.sh.

[Mike Frysinger]

On Sunday 11 November 2012 06:31:14 Eitan Adler wrote:
> On 11 November 2012 00:46, Mike Frysinger  wrote:
> > On Saturday 10 November 2012 00:41:52 Eitan Adler wrote:
> >> On 10 November 2012 00:41, Mike Frysinger wrote:
> >> > if the script is written in bash and is intended to be, then
> >> > /bin/bash is the correct answer.
> >> 
> >> Absolutely false. /usr/local/bin or /opt/bin might be the correct
> >> location.
> > 
> > if you have a crap system where bash isn't installed with /bin/bash, then
> > you already have a ton of problems with existing software.  forcing
> > stupid behavior on everyone to cater to broken systems is wrong.
> 
> http://www.technollama.co.uk/wordpress/wp-content/uploads/2011/05/obvious-t
> roll.jpg

yes, when people tell you forcing asinine behavior is wrong, you label them 
trolls.  i guess that's how you "win" arguments.
-mike


signature.asc
Description: This is a digitally signed message part.
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] [PATCH] Use bash for test.sh.

[Mike Frysinger]

On Saturday 10 November 2012 05:08:40 Joel Rosdahl wrote:
> On 10 November 2012 06:45, Mike Frysinger  wrote:
> > i see old style portable code in there that could easily be modernized to
> > recent POSIX
> 
> Please don't strive to do that. Solaris's /bin/sh isn't POSIX.

autoconf searches well known paths to locate an up-to-date shell.  my limited 
understanding is that Solaris stores modern tools somewhere in /usr/.  would 
you be amendable to having the script re-exec itself via those so we can 
update things ?
-mike


signature.asc
Description: This is a digitally signed message part.
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] [PATCH] Use bash for test.sh.

[Mike Frysinger]

On Monday 12 November 2012 06:03:37 Andrew Stubbs wrote:
> Running "sh -x test.sh" shows that the gcc command producing the error:
> 
> + CCACHE_DISABLE=1 gcc -c test1.c -o reference_test1.o -O -O
> gcc: error trying to exec 'cc1': execvp: No such file or directory
> 
> I don't understand what's wrong with that command. gcc isn't supposed to
> rely on the PATH to find cc1, but presumably it's something environmental.

it relies on argv[0] to locate its internal tools.  if you change that command 
to `env CCACHE_DISABLE=1 ...`, does it work better ?
-mike


signature.asc
Description: This is a digitally signed message part.
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

[ccache] [PATCH] ignore config.cache files

[Mike Frysinger]

This is created when you run `./configure -C`.
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index 7bed498..cfadd23 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,6 +12,7 @@ ccache-*.tar.*
 ccache.1
 ccache.html
 ccache.xml
+config.cache
 config.h
 config.h.in
 config.log
-- 
2.0.0

___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

[ccache] [PATCH] [RFC] do not rely on pids being unique

[Mike Frysinger]

Linux supports creating pid namespaces cheaply and running processes
inside of them.  When you try to share a single cache among multiple
such runs, the fact that the code relies on pid numbers as globally
unique values quickly fails.  Instead, switch to standard mkstemp to
generate temp files for us.

Signed-off-by: Mike Frysinger 
---
Note: this patch is against ccache 3.1.9 and does not apply cleanly to
  the latest master

 ccache.c   | 12 ++--
 ccache.h   |  2 +-
 manifest.c |  2 +-
 stats.c| 10 +-
 util.c | 13 -
 5 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/ccache.c b/ccache.c
index 02dbdfa..1dc0a06 100644
--- a/ccache.c
+++ b/ccache.c
@@ -526,8 +526,11 @@ to_cache(struct args *args)
unsigned added_files = 0;
 
tmp_stdout = format("%s.tmp.stdout.%s", cached_obj, tmp_string());
+   create_empty_file(tmp_stdout);
tmp_stderr = format("%s.tmp.stderr.%s", cached_obj, tmp_string());
+   create_empty_file(tmp_stderr);
tmp_obj = format("%s.tmp.%s", cached_obj, tmp_string());
+   create_empty_file(tmp_obj);
 
args_add(args, "-o");
args_add(args, tmp_obj);
@@ -579,7 +582,7 @@ to_cache(struct args *args)
int fd_result;
char *tmp_stderr2;
 
-   tmp_stderr2 = format("%s.tmp.stderr2.%s", cached_obj, 
tmp_string());
+   tmp_stderr2 = format("%s.2", tmp_stderr);
if (x_rename(tmp_stderr, tmp_stderr2)) {
cc_log("Failed to rename %s to %s: %s", tmp_stderr, 
tmp_stderr2,
   strerror(errno));
@@ -723,7 +726,9 @@ get_object_name_from_cpp(struct args *args, struct mdfour 
*hash)
/* now the run */
path_stdout = format("%s/%s.tmp.%s.%s",
 temp_dir, input_base, tmp_string(), i_extension);
+   create_empty_file(path_stdout);
path_stderr = format("%s/tmp.cpp_stderr.%s", temp_dir, tmp_string());
+   create_empty_file(path_stderr);
 
time_of_compilation = time(NULL);
 
@@ -738,11 +743,6 @@ get_object_name_from_cpp(struct args *args, struct mdfour 
*hash)
   can skip the cpp stage and directly form the
   correct i_tmpfile */
path_stdout = input_file;
-   if (create_empty_file(path_stderr) != 0) {
-   cc_log("Failed to create %s: %s", path_stderr, 
strerror(errno));
-   stats_update(STATS_ERROR);
-   failed();
-   }
status = 0;
}
 
diff --git a/ccache.h b/ccache.h
index 2bc7c87..43ef98d 100644
--- a/ccache.h
+++ b/ccache.h
@@ -130,7 +130,7 @@ size_t file_size(struct stat *st);
 int safe_open(const char *fname);
 char *x_realpath(const char *path);
 char *gnu_getcwd(void);
-int create_empty_file(const char *fname);
+int create_empty_file(char *fname);
 const char *get_home_directory(void);
 char *get_cwd();
 bool same_executable_name(const char *s1, const char *s2);
diff --git a/manifest.c b/manifest.c
index 7f02ede..47566d5 100644
--- a/manifest.c
+++ b/manifest.c
@@ -633,7 +633,7 @@ manifest_put(const char *manifest_path, struct file_hash 
*object_hash,
}
 
tmp_file = format("%s.tmp.%s", manifest_path, tmp_string());
-   fd2 = safe_open(tmp_file);
+   fd2 = mkstemp(tmp_file);
if (fd2 == -1) {
cc_log("Failed to open %s", tmp_file);
goto out;
diff --git a/stats.c b/stats.c
index 2111b65..4ed39c2 100644
--- a/stats.c
+++ b/stats.c
@@ -126,11 +126,18 @@ stats_write(const char *path, struct counters *counters)
size_t i;
char *tmp_file;
FILE *f;
+   int fd;
 
tmp_file = format("%s.tmp.%s", path, tmp_string());
-   f = fopen(tmp_file, "wb");
+   fd = mkstemp(tmp_file);
+   if (fd == -1) {
+   cc_log("Failed to open %s", tmp_file);
+   goto end;
+   }
+   f = fdopen(fd, "wb");
if (!f) {
cc_log("Failed to open %s", tmp_file);
+   close(fd);
goto end;
}
for (i = 0; i < counters->size; i++) {
@@ -138,6 +145,7 @@ stats_write(const char *path, struct counters *counters)
fatal("Failed to write to %s", tmp_file);
}
}
+   /* This also implicitly closes the fd. */
fclose(f);
x_rename(tmp_file, path);
 
diff --git a/util.c b/util.c
index 3b472de..cc630a6 100644
--- a/util.c
+++ b/util.c
@@ -195,7 +195,7 @@ copy_file(const char *src, const char *dest, int 
compress_dest)
struct stat st;
int errnum;
 
-   tmp_name = format("%s.%s.XX", dest, tmp_string());
+   tmp_name = format("%s.%s",

Re: [ccache] [PATCH] [RFC] do not rely on pids being unique

[Mike Frysinger]

On 02 Nov 2014 22:29, Joel Rosdahl wrote:
> Sounds like a good idea to me.
> 
> The patch doesn't apply to latest maint either. Would you like to update
> the patch to latest maint and resend it, or would it be OK if I commit a
> variant based on your patch?

feel free to rebase it.  it'll most likely be much faster than if i did it 
since 
you know the code base way better than i :).
-mike


signature.asc
Description: Digital signature
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

[ccache] [PATCH] test: drop perl requirement

[Mike Frysinger]

Since perl is used in just one place and can easily be replaced by a
little bit of shell, do so.  This makes testing on limited systems
easier.

Signed-off-by: Mike Frysinger 
---
 INSTALL.txt | 1 -
 test.sh | 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/INSTALL.txt b/INSTALL.txt
index 256beab..f77cbe6 100644
--- a/INSTALL.txt
+++ b/INSTALL.txt
@@ -67,7 +67,6 @@ In addition to the prerequisites mentioned above, you also 
need:
 
 To debug and run the performance test suite you'll also need:
 
-- Perl (http://www.perl.org/)
 - Python (http://www.python.org/)
 
 Run "./autogen.sh" and then follow the steps mentioned under "Installation"
diff --git a/test.sh b/test.sh
index f14e287..1090649 100755
--- a/test.sh
+++ b/test.sh
@@ -1834,7 +1834,7 @@ prepare_cleanup_test() {
 mkdir -p $dir
 i=0
 while [ $i -lt 10 ]; do
-perl -e 'print "A" x 4017' >$dir/result$i-4017.o
+printf '%4017s' '' | tr ' ' 'A' >$dir/result$i-4017.o
 touch $dir/result$i-4017.stderr
 touch $dir/result$i-4017.d
 if [ $i -gt 5 ]; then
-- 
2.4.0

___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] ccache version 3.2.3 has been released

[Mike Frysinger]

On 16 Aug 2015 13:39, Tom Lane wrote:
> $ grep extra_libs Makefile
> extra_libs = -lz
> ccache$(EXEEXT): $(ccache_objs) $(extra_libs)
> $(CC) $(all_cflags) -o $@ $(ccache_objs) $(all_ldflags) $(extra_libs) 
> $(LIBS)
> test/main$(EXEEXT): $(base_objs) $(test_objs) $(extra_libs)
> $(CC) $(all_cflags) -o $@ $(base_objs) $(test_objs) $(all_ldflags) 
> $(extra_libs) $(LIBS)
> 
> and of course "-lz" isn't a valid dependency.

that's not really true.  make will expand it internally into paths like 
/usr/lib/libz.so.

that said, there's no value anymore in putting -l flags into the deps list
and should just omit it from builds.
-mike


signature.asc
Description: Digital signature
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] ccache version 3.2.3 has been released

[Mike Frysinger]

On 17 Aug 2015 21:06, Joel Rosdahl wrote:
> Tom Lane  wrote:
> > [...] this fails to build for me on late-model OS X:
> 
> Bummer. Here's my proposed fix:
> https://git.samba.org/?p=ccache.git;a=commitdiff;h=f74c76107933046309861680b741adc67ac2a34e.
> Perhaps you could try it out?

that might work, but i think it's incorrect and can/will lead to problems in
the future.  ldflags should not contain libs for linking ... that's what LIBS
is for.  so you probably want:

--- a/configure.ac
+++ b/configure.ac
@@ -120,7 +120,7 @@ if test x${use_bundled_zlib} = xyes; then
 extra_libs="zlib/libz.a"
 mkdir -p zlib
 else
-extra_ldflags="-lz"
+LIBS="$LIBS -lz"
 fi
 
 dnl Linking on Windows needs ws2_32

-mike


signature.asc
Description: Digital signature
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] ccache interrupt handling bug

[Mike Frysinger]

On 17 Aug 2015 21:08, Joel Rosdahl wrote:
> Nadav Har'El  wrote:
> 
> > [...] Your patch makes ccache exit as soon as it gets the SIGINT - but the
> > child compiler might still be running for a while longer. This will usually
> > be fine, but I thought the user can be surprised if he sees ccache (which
> > he considers to be the compiler) exit, but "ps" shows the compiler is still
> > running. This would be especially annoying if some hypothetical compiler
> > trapped SIGINT deliberately, and continued to run long after ccache exits.
> 
> 
> Right, I understand where you're coming from. Thanks for clarifying your
> approach.
> 
> However, letting ccache's signal handler not exit is not an option since
> that would make it impossible to cancel ccache if the signal is caught when
> ccache is not running a compiler. One noteworthy code path that can take
> lots of time is performing cache cleanup – it can easily take many minutes
> on large, cold caches. ccache's signal handler is relatively new; it was
> added only recently to delete some temporary files before exiting. The
> missing _exit(1) call was simply an oversight, so I just restored the
> behavior to what it has been for a long time: exiting almost immediately on
> a signal (i.e., not waiting for any child process to exit).
> 
> Your patch makes ccache exit as soon as it gets the SIGINT - but the child
> > compiler might still be running for a while longer. This will usually be
> > fine, but I thought the user can be surprised if he sees ccache (which he
> > considers to be the compiler) exit, but "ps" shows the compiler is still
> > running. This would be especially annoying if some hypothetical compiler
> > trapped SIGINT deliberately, and continued to run long after ccache exits.
> 
> 
> I agree that it would be preferable to wait for the compiler if it's
> running. I think that the proper way to do that would be to waitpid()
> inside the signal handler and then _exit().

this wouldn't solve things entirely.  calling _exit(1) is fundamentally wrong.
here's a pretty good page giving a rundown:
http://www.cons.org/cracauer/sigint.html
-mike


signature.asc
Description: Digital signature
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] Using ccache with memcached

[Mike Frysinger]

On 01 Dec 2015 21:59, Anders Björklund wrote:
> Pierre Tardy made a PR (https://github.com/jrosdahl/ccache/pull/30)
> to replace the filesystem ("fs") cache with memcached altogether.
> 
> We have gone with a different approach, to use memcached only as a
> secondary cache - while preserving the primary cache (on the disk).

i don't think getting rid out of the fs makes sense, but having memcache
be available dynamically as an additional layer sounds fine.
-mike


signature.asc
Description: Digital signature
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] Using ccache with memcached

[Mike Frysinger]

On 02 Dec 2015 20:16, Pierre Tardy wrote:
> > i don't think getting rid out of the fs makes sense, but having memcache
> > be available dynamically as an additional layer sounds fine.
> 
> It does make a lot of sense for me as I have a high performance network,
> which is faster than local harddrive. So I would insist on keeping an
> option for memcached only.

that isn't what i meant.  i don't care about runtime config options but
about (1) the code and (2) build time control.  fs should remain in the
source and memcache should be an additional configure flag which allows
the user to select it at runtime.
-mike


signature.asc
Description: Digital signature
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] Moving to github

[Mike Frysinger]

On 23 May 2016 20:17, Joel Rosdahl wrote:
> Ever since Tridge handed over the project to me, the main ccache Git
> repository has been hosted on git.samba.org and bugs handled in
> bugzilla.samba.org. I also have kept an unofficial mirror on github.
> 
> Since some time now, almost all activity regarding new features and bug
> reports have been circling around the github mirror repository, so I think
> that it's time to move to github officially. (It will be located under
> github.com/ccache, not under my personal github account.)
> 
> If anybody thinks this would be a bad idea, please make some noise.
> Otherwise I'll do the move in a week or so.

sounds like a good idea to me :).  nothing against samba of course!
-mike


signature.asc
Description: Digital signature
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] Migration from autotools to cmake

[Mike Frysinger]

On 19 Jul 2016 18:17, Joel Rosdahl wrote:
> On 12 July 2016 at 12:03, Иван Вайгульт  wrote:
> > In order to enable visual studio build I did full build replica using
> > cmake. [...]
> > Any feedback from you is desired.
> 
> Thanks for working on this.
> 
> After some thinking I'm positive to getting rid of autotools. Although
> I don't find cmake to be very elegant, it feels less bad than
> autotools, at least for modern systems.
> 
> Other opinions from list members are welcome!

cmake is often still broken when it comes to cross-compiling (and even
native compiles) and library searches.  many of its modules do stupid
things like check to see if libs can be found in /usr/lib and /usr/lib64
instead of doing link tests.  the FindZLIB module still exhibits these
and that branch is using that module.

conversely, autotools has no such insanity.

glancing at the branch:
 - CMakeLists.txt/*.cmake have inconsistent indentation (tab-vs-spaces)
 - CMakeLists.txt/*.cmake should have no trailing whitespace
 - DEVELOPER_BUILD should not default to "on"
 - `git describe` should not be run when DEVELOPER_BUILD is off
 - CCACHE_VERSION fallback should not be "unknown" but the release version
 - USE_OWN_LIBZ would prob be better named like "USE_SYSTEM_LIBZ"
-mike


signature.asc
Description: Digital signature
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache