Ben Walton <bwalton@xxxxxxxxxxxxxxxxxx> 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'. -- 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