Open kayhayen opened 6 years ago
kayhayen
commented
6 years ago For example, using a different exit code, that I could provide via environment variable, that would be used in case of cache not used, but successful, that would be easy to use, but probably very counter intuitive to others.
frerich
commented
6 years ago Two ideas come to mind:
Parsing the debug output, as you mentioned -- we could make clcache a bit more friendly and somehow offer a debug output which is easier to parse (CSV or something).
You could fetch the cache stats before the compilation, and after -- and then compute the delta.
Does either of those seem viable?
kayhayen
commented
6 years ago There are multiple compilations going on at any time. So stats do not cut it. That is how I do a manual test, while I make sure nothing else is going on.
Since I would like to always report it, a specific option that makes it output to sys.stderr something like "clcache: MISS %s" % filename would be good enough for me already. Others would probably be "DIRECT HIT" and so on.
Should Nuitka produce unstable C code, or clcache fail to be used, this would then help to do discover it sooner or at all.
Hello there,
I have successfully enabled "clcache" for my Windows CI of Nuitka, the Python compiler, where I often make it churn on the same files over and over despite no change in generated C code. Adding it to Scons was easy. One day I need to add that to your Wiki.
What I would like to improve, is that I can get a report, for the compilation of a file, if it has successfully used the cache or not, so I can include that in my Nuitka compilation report. Because there are other compilations going on, that may bump the numbers.
Enabling debug output and parsing it seems like overkill for this. Any idea how this could look like? Or should I have to use debug output parsing?
Yours, Kay