aengelke wrote: > Should I pass `-DCMAKE_DISABLE_PRECOMPILE_HEADERS=ON` on the compile time > tracker so that we still become aware of expensive includes being added to > core headers?
I'm unsure, but would be inclined not to do so for the reason you mentioned. Ideally, of course, we would track both, but increasing iteration times from ~15 to ~21 minutes is probably unacceptable (and I'd personally see them much rather at 11 minutes). Maybe we can use data from stage1 somehow? *In principle*, this should be possible: for every ccache miss, track time+max-rss, and aggregate with data from ccache hits. Unfortunately, I don't think this is implementable without ccache changes. Alternatively, collect data not for every commit? That would probably be an architectural change. > sccache is a common CI configuration, and nobody is going to notice those > warnings. I guess this depends somewhat on what the failure mode for sccache > + pch is. Build failures? Silent miscompiles? Silent failures to use the > cache? As with ccache: miscompiles with GCC, ok with Clang (in my limited testing): - sccache will incorrectly identify the PCH as cache hit even if a macro definition changed, due to identical preprocessor output. I filed https://github.com/mozilla/sccache/issues/2562. - This causes miscompiles for GCC. - But the results for Clang appear to be correct and there is the expected number of cache hits from source files. It appears that Clang doesn't include macro definitions in the PCH? At least in my tests, the PCH ended up being identical (same hash sum)? (@ChuanqiXu9 @Bigcheese is this correct?) Inside CMake, we cannot reliably whether ccache or sccache is actually used (e.g., clang could actually be /usr/lib/ccache/clang), so any automation here is going to be brittle to some degree. https://github.com/llvm/llvm-project/pull/176420 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
