Re: Conditionally define vars to improve portability

From: Jacob Keller <jacob.keller@gmail.com>
Date: Sep 8, 2015, 20:09 UTC
Message-ID: <CA+P7+xopnAfmKNfL=p5wrqfLx5CENcBoFkdZ1swLe+3PchcONQ@mail.gmail.com>
In-Reply-To: <xmqqvbbk7n8r.fsf@gitster.mtv.corp.google.com>

On Tue, Sep 8, 2015 at 11:57 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 13 quoted lines

> 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.

It should be noted that a common idiom is also "VARIABLE=VALUE Make" where we set the variable in the environment before running the command. This would begin working if you allow the =? setting of variables.

That being said, since "make VARIABLE=VALUE" already works, and is really just as easy to type as above, I think I prefer your argument overall. We shouldn't encourage people to use the environment, and instead use config.mak or other methods which are far more explicit.