Re: Build Failure: GIT-GUI-VARS

Brian Gernhardt [off-list ref] writes:

On May 10, 2007, at 10:30 PM, Junio C Hamano wrote:

quoted

I do not either, and obviously does not reproduce for me.  Time
for you to try "make -d" perhaps?

Sorry for the semi-coherent message.  It started out as "we should fix
this" and I ended up going "why is it broken", all a little too  late
at night.  I'm also not used to debugging Makefiles.

And I figured it out (make -p actually was more useful than -d):  It's
another issue with doing things before including config.mak.

Ahh, config.mak.

I have not been very sympathetic to config.mak from the
beginning, although people seem to want it.  As I try to arrange
variable overrides to be passed from the command line anyway,
I've not used config.mak myself.

I think we need to be including the config.mak much earlier in the
Makefile as this is not the first time issues like this have come up
for me.

However, it needs to be able to override NO_*, NEEDS_* and
friends which means it should come after platform specific
defaults.  But one platform wants to change the default
behaviour depend on the settings of NO_*, possibly set in
config.mak.

It is a mess.  Moving it around would fix one person's problem
while breaking others.  I think the best course of action is

 (1) first for somebody more fluent in speaking Makefile than me
     to volunteer to tackle this problem, and ask help from the
     list;

 (2) have people on various "non-stock" configurations sign-up
     as testers; this does not have to cover the systems listed
     in the ifeq ($(uname_S),XXX) part of the current Makefile;
     what is of interest is to see what kind of variables are
     overridden on the real-world systems via config.mak;

 (3) The volunteer cooks up an improved Makefile, using
     config.mak "non-stock" testers have.

This would be something that "volunteer" would be deciding, but
I have a feeling that we can have two config.mak include in the
makefile, one early and one late.  But I suspect that picking
the right two places would have the same "moving would fix one
while breaking another" issue.