Re: Conditionally define vars to improve portability

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> On Mon, Sep 07, 2015 at 02:51:42PM -0300, Renato Botelho wrote:
>
>> Default variables used to build are set using = on Makefile, (e.g. CC,
>> INSTALL, CFLAGS, …). GNU make overwrite these values if it’s passed as
>> an argument (make CC=clang) and it works as expected.
>> 
>> Default method of passing arguments for make operations on FreeBSD
>> ports tree is using environment variables instead of make arguments,
>> then we have CC set on env before call gmake. Today these values are
>> ignored by git Makefile, and we ended up patching Makefile replacing =
>> by ?= on variable assignments [1].
>
> Hmm. I can't really think of a downside to doing so, unless we expect
> users to have things like CC set in the environment and _not_ want them
> to bleed through to our build.

I do think that is the reason behind the choice.  I am not saying I
necessarily personally agree with it, though.

Common things like CC are not so problematic, but more problematic
are various Git build customization in our Makefile that can be left
behind from a previous build.  It is easier for users to forget, as
a "GIT_FOO=NoThanks; export GIT_FOO" that was run previously in the
same shell does not leave trace once the shell exits, compared to
other avenues of customization including config.mak and explicit
command line settings given to the 'make' utility (i.e. can be seen
in 'history' as a single entry, without having to trace the sequence
of 'GIT_FOO=NoThanks', 'export GIT_FOO' and possible 'unset GIT_FOO'
to find what was in effect when 'make' was run).  So from that point
of view, if you encourage users to be less explicit by keeping them
in the environment, you are making it easier for the users to hurt
themselves.

In an environment to build with a "make world" style propagation of
settings from top-level to down below, "environment bleeding" is a
non-issue.  It is merely a convention in that build environment how
the settings are passed to submakes in a whole system and everybody
in that environment understands the ramifications.  I agree that
your suggestion of using "gmake -e" may be a good workaround for
handling cases like that.