Re: [ccache] ccache on generated C++ files...

2019-06-25 Thread Malfettone, Kris via ccache
I have confirmed that a few files can be different due to our generation code.  
There are no volatile pieces such as preprocessor macros and such, just good 
non-deterministic print orders in our generation code.  I believe this should 
be the culprit but unfortunately will take a bit for me to cleanup to test 
again.  My mistake was "assuming" it was all consistent.

Thanks for all the time / info everybody.  CCache has always been a favorite 
tool of mine.

-Kris

-Original Message-
From: Joel Rosdahl [mailto:j...@rosdahl.net]
Sent: Tuesday, June 25, 2019 3:03 PM
To: Malfettone, Kris 
Cc: ccache@lists.samba.org
Subject: Re: [ccache] ccache on generated C++ files...

On Tue, 25 Jun 2019 at 00:28, Malfettone, Kris via ccache
 wrote:
> So what I seem to be observing is only when I do a ninja -t clean or make
> clean. This removes all of my generated files (.h and .cpp files) and of
> course the normal build outputs. A subsequent run is then mostly cache
> misses. If I say manually do a rm $(find -name "*.o") then I get a 100% cache
> hit rate. I had assumed it was due to the fact that the generated files would
> have a newer mtime and ctime. My assumption must be wrong.

Maybe there is a timestamp in the generated files?

> Is there an easy way to print diagnostics on why a cache miss occurred?

Yes, assuming you use ccache 3.5 or newer, you can enable the debug mode and
compare the hashed input for two different builds. See "To debug why you don’t
get an expected cache hit for an object file [...]" on
.

-- Joel



IMPORTANT: The information contained in this email and/or its attachments is 
confidential. If you are not the intended recipient, please notify the sender 
immediately by reply and immediately delete this message and all its 
attachments. Any review, use, reproduction, disclosure or dissemination of this 
message or any attachment by an unintended recipient is strictly prohibited. 
Neither this message nor any attachment is intended as or should be construed 
as an offer, solicitation or recommendation to buy or sell any security or 
other financial instrument. Neither the sender, his or her employer nor any of 
their respective affiliates makes any warranties as to the completeness or 
accuracy of any of the information contained herein or that this message or any 
of its attachments is free of viruses.
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache


Re: [ccache] ccache on generated C++ files...

2019-06-25 Thread Bernd Petrovitsch via ccache
On 25/06/2019 00:28, Malfettone, Kris via ccache wrote:
> So what I seem to be observing is only when I do a ninja -t clean or make 
> clean.  This removes all of my generated files (.h and .cpp files) and of 
> course the normal build outputs.  A subsequent run is then mostly cache 
> misses.   If I say manually do a rm $(find -name "*.o") then I get a 100% 
> cache hit rate.  I had assumed it was due to the fact that the generated 
> files would have a newer mtime and ctime.  My assumption must be wrong.

TTBOMK ccache ignores mtime/ctime/... (as make/ninja/... use that anyway
before) but only the preprocessed content matters.

IIUC, the `make clean` removes all *.o and all generated .h/.c/.hpp/.cpp
files.
The rm $(find -name "*.o") removes only *.o.

So the analysis above is at least incomplete.

Are you really sure the newly generated .h/.c/.hpp/.cpp files are
identical (enough)?
No static variables or expanded preprocessor #defines with the build
date+time or similar in there?

[ Fullquote deleted ]
MfG,
Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 LUGA : http://www.luga.at

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


Re: [ccache] ccache on generated C++ files...

2019-06-25 Thread Joel Rosdahl via ccache
On Tue, 25 Jun 2019 at 00:28, Malfettone, Kris via ccache
 wrote:
> So what I seem to be observing is only when I do a ninja -t clean or make
> clean. This removes all of my generated files (.h and .cpp files) and of
> course the normal build outputs. A subsequent run is then mostly cache
> misses. If I say manually do a rm $(find -name "*.o") then I get a 100% cache
> hit rate. I had assumed it was due to the fact that the generated files would
> have a newer mtime and ctime. My assumption must be wrong.

Maybe there is a timestamp in the generated files?

> Is there an easy way to print diagnostics on why a cache miss occurred?

Yes, assuming you use ccache 3.5 or newer, you can enable the debug mode and
compare the hashed input for two different builds. See "To debug why you don’t
get an expected cache hit for an object file [...]" on
.

-- Joel

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