On 2025-Nov-21, Peter Eisentraut wrote: > Currently, headerscheck and cpluspluscheck are very slow, and they defeat > use of ccache. I have fixed that, and now they are much faster. :-)
Yeah, I had noticed this too. Thanks for fixing it. > My solution is to create the test files in the build directory. For > example, for src/include/storage/ipc.h I generate > > headerscheck_src_include_storage_ipc_h.c (or .cpp) > > Now ccache works. Sounds reasonable. I notice that you're cleaning this file in a `rm` line in the loop, > @@ -253,10 +249,11 @@ do > if ! $COMPILER $COMPILER_FLAGS -I $builddir -I $srcdir \ > -I $builddir/src/include -I $srcdir/src/include \ > -I $builddir/src/interfaces/libpq -I > $srcdir/src/interfaces/libpq \ > - $EXTRAINCLUDES $EXTRAFLAGS -c $tmp/test.$ext -o $tmp/test.o > + $EXTRAINCLUDES $EXTRAFLAGS -c $test_file_name.$ext -o > $test_file_name.o > then > exit_status=1 > fi > + rm -f "$test_file_name.$ext" "$test_file_name.o" > done but this means that if the script is interrupted halfway through, one file or two files might remain in place. Would it be possible to have the current file name in a variable, so that the `trap` line can delete them? I've been also wondering about testing whether `parallel` is installed, and use that if so. > # Verify headerscheck / cpluspluscheck succeed > # > - # - Don't use ccache, the files are uncacheable, polluting ccache's > - # cache So how bad is the effect of the cache pollution that's now going to occur? I imagine we don't really care. (I have no idea how to measure this, and probably it's a waste of time just to try.) -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "E pur si muove" (Galileo Galilei)
