Re: Build Failure: GIT-GUI-VARS

From: Junio C Hamano <junkio@cox.net>
Date: May 11, 2007, 17:10 UTC
Message-ID: <7v3b23cmm5.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <5F2FFEA3-0D62-432D-98F7-8BE896937067@silverinsanity.com>

Brian Gernhardt <benji@silverinsanity.com> writes:

Show 11 quoted lines

> On May 10, 2007, at 10:30 PM, Junio C Hamano wrote:
>
>> 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.