Brian Gernhardt <benji@xxxxxxxxxxxxxxxxxx> writes:
> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
