Re: [ccache] Migration from autotools to cmake

2016-07-19 Thread 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

Re: [ccache] Moving to github

2016-05-23 Thread 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] Using ccache with memcached

2015-12-02 Thread 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] ccache version 3.2.3 has been released

2015-08-16 Thread 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

[ccache] [PATCH] ignore config.cache files

2014-09-15 Thread 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

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

2012-11-12 Thread Mike Frysinger 
On Sunday 11 November 2012 06:31:14 Eitan Adler wrote:
 On 11 November 2012 00:46, Mike Frysinger vap...@gentoo.org 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.

2012-11-12 Thread Mike Frysinger 
On Saturday 10 November 2012 05:08:40 Joel Rosdahl wrote:
 On 10 November 2012 06:45, Mike Frysinger vap...@gentoo.org 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.

2012-11-12 Thread 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

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

2012-11-10 Thread 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.

2012-11-09 Thread 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] Why not cache link commands?

2012-09-18 Thread 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?

2012-09-18 Thread 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] Making ccache and clang compatible

2012-07-05 Thread 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] Suggested patch to add local strtok_r for systems lacking it

2012-04-12 Thread 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] PATCH: Fix version.c for older gits

2010-09-24 Thread 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] Compression on or off by default?

2010-03-04 Thread 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] Compression on or off by default?

2010-03-03 Thread 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 http://gustaebel.de/lars/ccache/.) 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

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

2008-03-20 Thread Mike Frysinger 
On Wed, Mar 19, 2008 at 7:22 PM, Francois Marier franc...@debian.org 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

2007-06-14 Thread 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