This patch follows the idea of 671df48df8 (meson: precompile "git-compat-util.h", 2026-03-19) to make it faster to build Git using "make". The notable differences are the boilerplate needed to wire up the precompiled header with "make", and the selection of object files that are built using the precompiled header:
- Add a new rule to precompile "tools/precompiled.h" into
"tools/precompiled.h.gch". This rule and its dependencies are basically the same as our
existing rule and its dependencies for compiling object files from
our source files and, except that in this rule we don't use the
EXTRA_CPPFLAGS target-specific variable. This is partly because
any compiler flags in that target-specific variable can't possibly
make sense for the project-wide "git-compat-util.h", and partly
because it could run afoul of "make"'s quirks with target-specific
variables and GCC's "-Winvalid-pch" compiler option [1]. Our Makefile always writes object files next to the source files
they were compiled from. Since a precompiled header is in many
ways similar to an object file, let's follow suit and write it
next to the header file it was created from as well. 671df48df8
doesn't mention why "precompiled.h" was placed in "tools/". Use the ".gch" suffix for the precompiled header file, because
that's the only suffix GCC looks for when searching for a
precompiled header. Clang apparently looks for both ".pch" and
".gch" suffixes. If we ever encounter a compiler which only
supports a different precompiled header suffix, then we might make
the suffix configurable via a Makefile knob; but until then it
remains hard-coded for the sake of simplicity. - Declare the precompiled header's dependencies, so it gets rebuilt
when any of our header files it includes is modified. When using computed header dependencies, then the compiler can
generate the Makefile snippet containing the header files inlcuded
by the precompiled header, just like when compiling a C source
file into an object file. When not using computed header dependencies, then make the
precompiled header depend on the same header files that our object
files depend on, i.e. those listed in LIB_H and GENERATED_H. This
is not ideal, because the precompiled header will be rebuilt even
when a header file it doesn't actually depend on changes; but in
that case all object files will be rebuilt as well anyway. - List the object files that are built using the precompiled header
in the PRECOMPILED_HEADER_USERS variable: - The precompiled header should not change what actually gets
compiled. Therefore, use the precompiled header only when
compiling source files that start with including
"git-compat-util.h" (directly or indirectly, e.g. via
"builtin.h"), or its inclusion is only preceeded by #define
directives that don't influence "git-compat-util.h" between its
include guards [2] (currently DISABLE_SIGN_COMPARE_WARNINGS,
USE_THE_REPOSITORY_VARIABLE or GIT_TEST_PROGRESS_ONLY). [3] Several (but not all) object or source files listed in the
COMPAT_OBJS, REFTABLE_OBJS and THIRD_PARTY_SOURCES variables
don't include "git-compat-util.h", therefore, for the sake of
simplicity, none of the files listed in these variables are
built with the precompiled header. [4] Since 671df48df8 the Meson build uses the precompiled header
even when compiling those reftable source files that don't
include "git-compat-util.h" at all, although this change is not
mentioned in the commit message. - But other than that, use the precompiled header when compiling
all other source files, including e.g. source files for
standalone executables (e.g. "daemon.c" for "git-daemon"), or
those in the directories "t/helper/" and "t/unit-tests/" as
well. The Meson build, however, only uses the precompiled header for
compiling objects in "libgit_sources" and "builtin_sources",
despite 671df48df8 giving the impression that the precompiled
header is included in all compilation units. - In short, PRECOMPILED_HEADER_USERS contains all object files
listed in OBJECTS, except those that are listed in COMPAT_OBJS,
REFTABLE_OBJS or THIRD_PARTY_SOURCES as well. - Add a new rule to build object files listed in
PRECOMPILED_HEADER_USERS with the precompiled header. This rule and its dependencies are basically the same as our
existing rule and its dependencies compiling object files from our
source files, except: - This rule depends on the precompiled header as well, to make
sure that it's built before it is used. - Use the "-include tools/precompiled.h" option to make the
precompiled header the first header in the compilation unit,
because only then is it used to speed things up. - Use the "-Winvalid-pch" option to catch any issues when the
precompiled header is present but can't be used for whatever
reason. While being unable to use the precompiled header would
normally only result in a slower build, it is probably better
that developers are made aware that simething is not quite
right. Meson uses this option as well when compiling a source
file using the precompiled header. Note, that in case of such an issue with "-Winvalid-pch" we
would get a warning for each object file that is build using the
precompiled header, but together with "-Werror" (e.g. with
DEVELOPER=1) it would fail the build. Object files not listed in PRECOMPILED_HEADER_USERS are built with
the existing (and unchanged) rule for object files. - This way the precompiled header is compiled only once during
the whole build process. The Meson build, however, currently compiles the precompiled
header twice: once for "libgit_sources" and once for
"builtin_sources", despite 671df48df8 giving the impression that
it's compiled only once. And, by the looks of it, it would have
to be compiled once more for each new library or executable where
we declare the use of the precompiled header. - Add the Makefile knob NO_PRECOMPILED_HEADER to make it possible to
build without using the precompiled header for testing purposes,
or for any compiler that might be out there that doesn't support
the "-Winvalid-pch" option. Note, that when this knob is set then we merely leave
PRECOMPILED_HEADER_USERS empty: this way nothing is built with the
precompiled header, but "make clean NO_PRECOMPILED_HEADER=1" would
still remove a leftover precompiled header file.With this patch series on top of v2.55.0 I got the following build time improvement:
Benchmark 1: make -j12 (rev = v2.55.0)
Time (mean ± σ): 29.414 s ± 0.031 s [User: 254.786 s, System: 47.447 s]
Range (min … max): 29.370 s … 29.470 s 10 runs Benchmark 2: make -j12 (rev = precompile)
Time (mean ± σ): 21.725 s ± 0.047 s [User: 186.047 s, System: 35.109 s]
Range (min … max): 21.643 s … 21.768 s 10 runs Summary
'make -j12 (rev = precompile)' ran
1.35 ± 0.00 times faster than 'make -j12 (rev = v2.55.0)'[1] "make" applies target-specific variables to the first target's
dependencies as well. So, if the rule creating the precompiled
header included $(EXTRA_CPPFLAGS) as well, then we could get this: $ make -s clean
$ make V=1 git
gcc -o tools/precompiled.h.gch -c -MF [...] -DSHELL_PATH='"/bin/sh"' '-DGIT_HTML_PATH="share/doc/git-doc"' '-DGIT_MAN_PATH="share/man"' '-DGIT_INFO_PATH="share/info"' tools/precompiled.h
gcc -o git.o -c -include tools/precompiled.h -Winvalid-pch -MF [...] -DSHELL_PATH='"/bin/sh"' '-DGIT_HTML_PATH="share/doc/git-doc"' '-DGIT_MAN_PATH="share/man"' '-DGIT_INFO_PATH="share/info"' git.c
gcc -o builtin/add.o -c -include tools/precompiled.h -Winvalid-pch -MF [...] -DSHELL_PATH='"/bin/sh"' builtin/add.c
cc1: error: ./tools/precompiled.h.gch: not used because `GIT_MAN_PATH' not defined [-Werror=invalid-pch]
cc1: all warnings being treated as errors
make: *** [Makefile:2940: builtin/add.o] Error 1 So in this case "git.o" is the first object file to be build, and
since it has a target-specific EXTRA_CPPFLAGS and since it depends
on the precompiled header, the precompiled header is built with
the same EXTRA_CPPFLAGS as well. But then "builtin/add.o" is
built with empty EXTRA_CPPFLAGS, and GCC's sanity checks for the
-Winvalid-pch option complain. Clang apparently doesn't consider
this to be an issue, and builds "git" just fine. Note, however, that if the first object file to be built is not
"git.o" (or one of the other object files with target-specific
EXTRA_CPPFLAGS), which is usually the case with e.g. "make all",
then the precompiled header is built with empty EXTRA_CPPFLAGS,
and then all is well. Weird. We already had issues with "make"
and target-specific variables in the past, see a673cfede6
(Makefile: Fix occasional GIT-CFLAGS breakage, 2010-03-19).
The Meson build doesn't use target-specific variables, and the
whole project needs to be rebuilt when e.g. "mandir" is changed,
although this is not mentioned in 904339edbd (Introduce support
for the Meson build system, 2024-12-06).[2] See baa61e46da (git-compat-util.h: move warning infra to prepare
for PCHs, 2026-03-19).[3] This can be verified by simply scanning through the output of:
{
printf '%s\n' 'print-%:'
printf '\t%s\n' '@printf "%s\n" $($*)'
} >/tmp/printvars.mak
for f in $(make -f /tmp/printvars.mak -f Makefile print-PRECOMPILED_HEADER_USERS)
do
f="${f%o}c"
sed -n -E -e "s%# *(define|include).*%& $f%p" -e '/# *include/q' "$f"
done | sort[4] "make"'s flexibility would allow us to separately list those
object files that don't include "git-compat-util.h", but then on
my (I assume fairly typical) Linux box the number of object files
built using the precompiled header increases only by 9 (from 536
to 545), which reduces the build time by about 1% (0.2s).
Therefore, I don't think it's worth the churn.Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
.gitignore | 1 +
Makefile | 26 +++++++++++++++++++++-----
2 files changed, 22 insertions(+), 5 deletions(-)