Re: Conditionally define vars to improve portability

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 8, 2015 at 11:57 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> 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.
--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]