Git development
 help / color / mirror / Atom feed
From: Ben Knoble <ben.knoble@gmail.com>
To: Harald Nordgren via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Harald Nordgren <haraldnordgren@gmail.com>
Subject: Re: [PATCH] Makefile: let ccache cache objects built with the precompiled header
Date: Tue, 27 Oct 2026 11:58:50 -0400	[thread overview]
Message-ID: <579C36BA-1418-4E15-9CA7-70C752A69FCE@gmail.com> (raw)
In-Reply-To: <pull.2464.git.git.1793104847288.gitgitgadget@gmail.com>


> Le 27 oct. 2026 à 08:49, Harald Nordgren via GitGitGadget <gitgitgadget@gmail.com> a écrit :
> 
> From: Harald Nordgren <haraldnordgren@gmail.com>
> 
> Since 8d3a673147 (Makefile: precompile "git-compat-util.h",
> 2026-09-15), rebuilding Git with ccache is almost as slow as building
> it without. ccache refuses to cache a compilation that uses a
> precompiled header unless its "pch_defines" and "time_macros"
> sloppiness is enabled, so it runs the compiler for nearly every object
> file, even after a "make clean" in a tree it has already built.
> 
> Both settings are safe for our build. The precompiled header is only
> pulled in with "-include" ahead of the source file, so no "#define" in
> a source file can come before it, and none of our sources use
> __DATE__, __TIME__ or __TIMESTAMP__.
> 
> Enable them for the precompiled header and the objects built with it.
> On my machine, "make clean && make -j8" with a warm cache goes from
> about 100 seconds to under 30.
> 
> With Clang, switching to a branch that changes one of the headers the
> precompiled header includes and back again still misses the cache,
> because Clang records the modification times of those headers in the
> precompiled header.
> 
> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
> ---
>    Makefile: let ccache cache objects built with the precompiled header
> 
>    With ccache, building after switching between two feature branches gets
>    about 6 times faster. The first build of each branch gets about 25%
>    slower while ccache fills its cache.
> 
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2464%2FHaraldNordgren%2Fmakefile-ccache-pch-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2464/HaraldNordgren/makefile-ccache-pch-v1
> Pull-Request: https://github.com/git/git/pull/2464

I can’t comment on the above, not being a ccache user myself.

> Makefile | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/Makefile b/Makefile
> index a96be506b5..43ea5e0c40 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2946,6 +2946,8 @@ $(PRECOMPILED_HEADER_GCH): %.gch: % GIT-CFLAGS $(missing_dep_dirs) $(missing_com
> $(PRECOMPILED_HEADER_USERS): %.o: %.c $(PRECOMPILED_HEADER_GCH) GIT-CFLAGS $(missing_dep_dirs) $(missing_compdb_dir)
>    $(QUIET_CC)$(CC) -o $*.o -c -include $(PRECOMPILED_HEADER) -Winvalid-pch $(dep_args) $(compdb_args) $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) $<
> 
> +$(PRECOMPILED_HEADER_GCH) $(PRECOMPILED_HEADER_USERS): export CCACHE_SLOPPINESS += pch_defines,time_macros
> +

This is a little curious to me. I’m familiar with the GNU Make-ism 
to set variables for particular targets; how does the export work?
Is it the same but with a propagation to the recipe processes?

Would it be better (for some definition…) to put the export in the 2
pre-compiled header recipes directly?

And, what about Meson?

  reply	other threads:[~2026-10-27 15:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-27 12:40 [PATCH] Makefile: let ccache cache objects built with the precompiled header Harald Nordgren via GitGitGadget
2026-10-27 15:58 ` Ben Knoble [this message]
2026-10-27 20:00   ` Harald Nordgren
2026-10-27 21:57     ` D. Ben Knoble
2026-10-28  7:34       ` Patrick Steinhardt
2026-10-28  9:58         ` Harald Nordgren
2026-10-29  8:33 ` [PATCH v2] " Harald Nordgren via GitGitGadget

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=579C36BA-1418-4E15-9CA7-70C752A69FCE@gmail.com \
    --to=ben.knoble@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=haraldnordgren@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox