Re: [PATCH 0/2] Set Makefile variables from configure

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

Ben Walton <bwalton@artsci.utoronto.ca> writes:

> Excerpts from Junio C Hamano's message of Wed Nov 04 14:36:32 -0500 2009:
>
>> I am a bit puzzled about the "warning" logic.  Is this because you expect
>> variables we typically give YesPlease/NoThanks as their values will not be
>> handled with this new PARSE_WITH_SET_MAKE_VAR() macro?
>
> No, this is because it's perfectly acceptable, in my opinion for a
> user to say:
>
> --with-pager=no
> or
> --with-editor=yes
>
> Neither of those are smart things to do, but they're not necessarily
> wrong, either.  I'm open to bailing on error for these, but I thought
> leaving these as unvalidated, but with a warning, was more
> flexible...if say a user wanted to have a pager called 'no' or
> something.

What puzzled me was not "why is it not an error but just a warning?", which
is what you just explained, but "why should we even care what value is
being given to begin with?".

I am _not_ saying "I think it is more correct not to check the value at
all".  I just wanted to understand in what situation it may be benefitial
to give this warning in the first place.

> For the variables that are accepting YesPlease/NoThanks, I think it's
> more suitable to use the standard autoconf header/function/library
> detection as it stands now.  This macro is more for 'oddball'
> variables like DEFAULT_PAGER, DEFAULT_EDITOR, etc that aren't
> necessarily easily detectable.  In some cases, even if it were
> detectable, the detection might not be right.

I am guessing from this description of 'oddball variables' that your
answer to my question is yes.  That is, configure.ac writers are strongly
discouraged from using this new macro for variables that would usually get
YesPlease/NoThanks kind of values.

And then it makes sense to warn 'yes/no', as it is unlikely that the user
wants to set name (or path) of programs we allow to be tweaked to 'yes' or
'no'.