Re: [PATCH] Makefile: read configuration earlier

On Wed, Jul 29, 2026 at 09:10:15PM -0700, Junio C Hamano wrote:

> This is a scary patch because its correctness depends on what is
> between lines 780-1050.  It turns out that this now lets config.mak*
> to set quite a lot of symbols to affect the outcome:
> 
>  * PROGRAM_OBJS, BUILT_INS, TEST_BUILTIN_OBJS
>  * WITH_BREAKING_CHANGES
>  * SHELL_PATH
>  * PERL_PATH
>  * PYTHON_PATH
>  * NO_RUST
>  * DEBUG
>  * uname_S?????
>  * SPARSE_FLAGS
>  * SPATCH_INCLUDE_FLAGS

Yes, though to some degree config.mak can already manipulate those after
the fact. There are other breakages, though (see the CFLAGS one I showed
elsewhere in the thread).

> Especially curious is that currently there is this bit:
> 
> 	ifeq ($(uname_S),Windows)
> 	RUST_LIB_NAME = gitcore.lib
> 	else
> 	RUST_LIB_NAME = libgitcore.a
> 	endif
> 
> that comes WAY BEFORE config.mak.uname is included.  If the location
> to include these files matter, then how could this bit have been
> working?  I have no idea and since I have no access to Windows
> development box so I wouldn't know.

Yeah, that seems totally wrong to me. Likewise this bit right above it:

  ifndef NO_RUST
  ifdef DEBUG
  RUST_BUILD_CONFIG = debug
  else
  RUST_BUILD_CONFIG = release
  endif

has the same problem brian is fixing for BREAKING_CHANGES. It will work
for "make NO_RUST=1", but not if you put NO_RUST into config.mak. That
said, I don't know why that NO_RUST check is there at all. It is not a
problem to set a flag that nobody looks at. So it may be a bug without a
visible effect. ;)

-Peff