git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/2] more t/perf meson/GIT-BUILD-OPTIONS fallout

From
Jeff King <peff@peff.net>
Date
Jan 16, 2026, 16:54 UTC
Message-ID
<20260116165451.GB1636797@coredump.intra.peff.net>
In-Reply-To
<1a430542-715e-4cf1-86f5-d9424951204a@ramsayjones.plus.com>
On Tue, Jan 06, 2026 at 05:07:11PM +0000, Ramsay Jones wrote:
Show 17 quoted lines
> I hesitated to send this email because I have been reduced to simply skimming
> the git mailing list (very busy with other projects/real life!), and I may
> have misunderstood what you aim to do here. ;)
> 
> In essence, I was triggered by the 'GIT-BUILD-OPTIONS fallout' phrase in the
> subject line! That reminded me of a problem/patch I was looking at earlier
> this (wait, last) year. The patch (below) was a complete 'hack' (as you can
> see) to allow the environment to override the 'GIT-BUILD-OPTIONS' file. This
> was in an old branch named 'meson-wip' which I have been meaning to look at
> again to either delete or fix-up.
> 
> One of the many reasons (apart from being a disgusting hack) that I didn't
> progress this patch is because I felt that not all 'options' in that file
> should be able to be 'overridden'. So, that implies that the file needs to
> be split into two; one file of options which can be overridden from the
> environment and one that can't. If so, then someone has to decide which is
> which.

I think you understood my goal. :) This is more or less what my patch is doing, but just for a select set of options (to un-break t/perf). I think a larger fix may look something like this, but:

  1. I agree with you that we may need to consider which options should
     be able to be overridden and which should not.
  2. This hack has to go everywhere that GIT-BUILD-OPTIONS is read. So
     in test-lib.sh where you have it, but also in perf-lib.sh (matching
     the fix by Dscho earlier) and also in t/perf/run (matching the fix
     here).

It would be nice if we could write GIT-BUILD-OPTIONS in a way that did the right thing. E.g., by writing:

  : ${GIT_FOO:=some-value}

And then the writer (which is the ultimate source of authority for which variables are included) could decide which ones can be overridden.

I _thought_ this wouldn't work because we also source the build options files from the Makefile (and so it has to support both syntaxes). But a quick grep doesn't show us including it. So maybe we used to do so, or maybe I'm mis-remembering (and confusing it with GIT-VERSION-FILE perhaps?).

-Peff
Previous: Ramsay Jones
Message 5 of 5 in “more t/perf meson/GIT-BUILD-OPTIONS fallout”
  1. 0/2 more t/perf meson/GIT-BUILD-OPTIONS falloutJeff King, Jan 6, 2026
  2. 1/2 t/perf/perf-lib: fix assignment of TEST_OUTPUT_DIRECTORYJeff King, Jan 6, 2026
  3. 2/2 t/perf/run: preserve GIT_PERF_* from environmentJeff King, Jan 6, 2026
  4. Ramsay JonesJan 6, 2026
  5. Jeff KingJan 16, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.