git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Nov 4, 2009, 19:56 UTC
Message-ID
<7vy6mmf4hi.fsf@alter.siamese.dyndns.org>
In-Reply-To
<1257363937-sup-5123@ntdws12.chass.utoronto.ca>
Ben Walton <bwalton@artsci.utoronto.ca> writes:
Show 18 quoted lines
> 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.

Show 6 quoted lines
> 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'.

Previous: Ben WaltonNext: Ben Walton
Message 12 of 15 in “Set Makefile variables from configure”
  1. 0/2 Set Makefile variables from configureBen Walton, Oct 31, 2009
  2. 1/2 configure: add function to directly set Makefile variablesBen Walton, Oct 31, 2009
  3. 2/2 configure: allow user to set gitconfig, pager and editorBen Walton, Oct 31, 2009
  4. Ben WaltonNov 3, 2009
  5. Jonathan NiederNov 3, 2009
  6. Jonathan NiederNov 3, 2009
  7. 0/2 Set Makefile variables from configureBen Walton, Nov 4, 2009
  8. 1/2 configure: add macro to set arbitrary make variablesBen Walton, Nov 4, 2009
  9. 2/2 configure: add settings for gitconfig, editor and pagerBen Walton, Nov 4, 2009
  10. Junio C HamanoNov 4, 2009
  11. Ben WaltonNov 4, 2009
  12. Junio C HamanoNov 4, 2009
  13. Ben WaltonNov 4, 2009
  14. Jonathan NiederNov 4, 2009
  15. Ben WaltonNov 4, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.