On Wed, 2006-11-01 at 17:58 +0000, Thorsten Glaser wrote: > Lothar Gesslein dixit: > > >Theese bugs are caused by gcc, not ccache. > > Sure, but: more tools, more code, more bugs.
Yeah of course, but as said, simply disable it to see if the bug comes from ccache. This will take you less time than you have saved by using it. And you will save energy and slow down global warming with ccache ;) Or, if you are a mobile user, your laptop might be able to run longer. I see far more advantages than disadvantages... > >exact same thing with the exact same compiler. > > Unless that is proven, I don't believe it. Quote from the manpage: ------ The basic idea is to detect when you are compiling exactly the same code a 2nd time and use the previously compiled output. You detect that it is the same code by forming a hash of: the pre-processor output from running the compiler with -E the command line options the real compilers size and modification time any stderr output generated by the compiler These are hashed using md4 (a strong hash) and a cache file is formed based on that hash result. When the same compilation is done a second time ccache is able to supply the correct compiler output (including all warnings etc) from the cache. ccache has been carefully written to always produce exactly the same compiler output that you would get without the cache. If you ever discover a case where ccache changes the output of your compiler then please let me know. ------ While this is no prove, it makes me quite sure it does only use the cache when compiling the exact same thing with the exact same compiler. In science, things are often considered true unless they are proven wrong. I belive in it, will you prove me wrong? ;) In the end, it's a quite theoretical discussion which is a bit misplaced here. I will do my best in implementing it, and the default will be not to use it, so you don't enable it, but i do. Regards -- Lothar Gesslein <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ freewrt-developers mailing list [email protected] https://www.freewrt.org/lists/listinfo/freewrt-developers
