update_web_docs_git: Add updated Texinfo to PATH

  maintainer-scripts/ChangeLog:

	* update_web_docs_git: Add updated Texinfo to PATH
---
Hi,

I'm posting this as a ping and a patch necessary to get the wwwdocs
building with the new Texinfo version that's installed on gcc.gnu.org.
It would be nice to do this ahead of the GCC 13 release.

I must ask that whoever decides to apply/update the script tests
texi2any with a simple example, like

  echo @node Top | ~/texinfo/install-git/bin/makeinfo --html -o -

... before updating; this should be a representative enough smoke test.
You should see some HTML output with little text in it.

It might also be wise to test the script directly by using a different
WWWBASE, just in case, even though it should be safe.

Thanks in advance, have a lovely day.

 maintainer-scripts/update_web_docs_git | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

On Thu, 6 Apr 2023, Arsen Arsenović wrote:
> maintainer-scripts/ChangeLog:
> 
> 	* update_web_docs_git: Add updated Texinfo to PATH

Do we really need to adjust PATH, or could we just introduce a MAKEINFO 
variable, something like

  if [ x${MAKEINFO}x = xx ]; then
    if [ -x /home/gccadmin/texinfo/install-git/bin/makeinfo ]; then
      MAKEINFO=/home/gccadmin/texinfo/install-git/bin/makeinfo;
    else
      MAKEINFO=makeinfo
    fi
  fi

?

(This also still allows overriding upon invocation.)

Gerald
  

On Thu, 6 Apr 2023, Arsen Arsenović wrote:
> I must ask that whoever decides to apply/update the script tests
> texi2any with a simple example, like
> 
>   echo @node Top | ~/texinfo/install-git/bin/makeinfo --html -o -
> 
> ... before updating; this should be a representative enough smoke test.
> You should see some HTML output with little text in it.

Yep, and one warning:

  -: warning: must specify a title with a title command or @top

The following then proceeds without warning and the output looks fine:

  printf "@title foo\n@node Top" | /home/gccadmin/texinfo/install-git/bin/makeinfo  --html -o -

Gerald
  

Gerald Pfeifer <gerald@pfeifer.com> writes:

> On Thu, 6 Apr 2023, Arsen Arsenović wrote:
>> maintainer-scripts/ChangeLog:
>> 
>> 	* update_web_docs_git: Add updated Texinfo to PATH
>
> Do we really need to adjust PATH, or could we just introduce a MAKEINFO 
> variable, something like
>
>   if [ x${MAKEINFO}x = xx ]; then
>     if [ -x /home/gccadmin/texinfo/install-git/bin/makeinfo ]; then
>       MAKEINFO=/home/gccadmin/texinfo/install-git/bin/makeinfo;
>     else
>       MAKEINFO=makeinfo
>     fi
>   fi
>
> ?
>
> (This also still allows overriding upon invocation.)
>
> Gerald

Ah!  Good idea.  What do you think of the following?
... since the other tools are siblings.

Thanks for the smoke test!
  

On Tue, 11 Apr 2023, Arsen Arsenović wrote:
> Ah!  Good idea.  What do you think of the following?

Did you intentionally not implement the following part of my suggestion

   if [ x${MAKEINFO}x = xx ]; then
   :

that is, allowing to override from the command-line (or crontab)?


And why the colons in

  +    : "${MAKEINFO:=${makeinfo_git}/makeinfo}"
  +    : "${TEXI2DVI:=${makeinfo_git}/texi2dvi}"
  +    : "${TEXI2PDF:=${makeinfo_git}/texi2pdf}"

? I don't think we use these elsewhere. Do they serve a purpose or can we 
omit them and keep things simpler?


Please let me know, and I'll see to get this (or probably an updated 
patch) in place on gcc.gnu.org.

Thanks,
Gerald
  

Gerald Pfeifer <gerald@pfeifer.com> writes:

> On Tue, 11 Apr 2023, Arsen Arsenović wrote:
>> Ah!  Good idea.  What do you think of the following?
>
> Did you intentionally not implement the following part of my suggestion
>
>    if [ x${MAKEINFO}x = xx ]; then
>    :
>
> that is, allowing to override from the command-line (or crontab)?
>
>
> And why the colons in
>
>   +    : "${MAKEINFO:=${makeinfo_git}/makeinfo}"
>   +    : "${TEXI2DVI:=${makeinfo_git}/texi2dvi}"
>   +    : "${TEXI2PDF:=${makeinfo_git}/texi2pdf}"
>
> ? I don't think we use these elsewhere. Do they serve a purpose or can we 
> omit them and keep things simpler?

(answering both the questions)

This := operator is a handy "default assign" operator.  It's a bit of an
oddity of the POSIX shell, but it works well.  The line:

  : "${foo:=bar}"

is a convenient way of spelling "if foo is unset or null, set it to
bar".  the initial ':' there serves to discard the result of this
evaluation (so that only its side effect of updating foo if necessary is
kept)

... so, the above block translates into "if makeinfo_git/makeinfo
exists, then default MAKEINFO, TEXI2DVI, TEXI2PDF to makeinfo_git/$tool,
otherwise, default them to $tool", where $tool is the respective tool
for those variables.

>
> Please let me know, and I'll see to get this (or probably an updated 
> patch) in place on gcc.gnu.org.
>
> Thanks,
> Gerald
  

Hi Arsen,

On Fri, 14 Apr 2023, Arsen Arsenović wrote:
>> Did you intentionally not implement the following part of my suggestion
>>
>>    if [ x${MAKEINFO}x = xx ]; then
>>    :
> > that is, allowing to override from the command-line (or crontab)?
> (answering both the questions)
> 
> This := operator is a handy "default assign" operator.  It's a bit of an
> oddity of the POSIX shell, but it works well.  The line:
> 
>   : "${foo:=bar}"
> 
> is a convenient way of spelling "if foo is unset or null, set it to
> bar".  the initial ':' there serves to discard the result of this
> evaluation (so that only its side effect of updating foo if necessary is
> kept)

I understand, just am wondering whether and why the : is required? I 
don't think we are using this construct anywhere else?

(I was aware of the ${foo:=bar} syntax, just caught up by you pushing
that part of the logic to the lowest level whereas I had it at the top
level. That's purely on me.)

Please go ahead and push this (or a variant without the : commands) and
I'll then pick it up from there.

Gerald
  

Gerald Pfeifer <gerald@pfeifer.com> writes:

> Hi Arsen,
>
> On Fri, 14 Apr 2023, Arsen Arsenović wrote:
>>> Did you intentionally not implement the following part of my suggestion
>>>
>>>    if [ x${MAKEINFO}x = xx ]; then
>>>    :
>> > that is, allowing to override from the command-line (or crontab)?
>> (answering both the questions)
>> 
>> This := operator is a handy "default assign" operator.  It's a bit of an
>> oddity of the POSIX shell, but it works well.  The line:
>> 
>>   : "${foo:=bar}"
>> 
>> is a convenient way of spelling "if foo is unset or null, set it to
>> bar".  the initial ':' there serves to discard the result of this
>> evaluation (so that only its side effect of updating foo if necessary is
>> kept)
>
> I understand, just am wondering whether and why the : is required? I 
> don't think we are using this construct anywhere else?

Without them, this would happen:

  ~$ "${foo:=foo}"
  bash: foo: command not found
  ~ 127 $ unset foo
  ~$ echo "${foo:=foo}"
  foo
  ~$ 

> (I was aware of the ${foo:=bar} syntax, just caught up by you pushing
> that part of the logic to the lowest level whereas I had it at the top
> level. That's purely on me.)
>
> Please go ahead and push this (or a variant without the : commands) and
> I'll then pick it up from there.

Thank you!  Hopefully we get this just in time for 13 :)

Pushed.
  

On Thu, 20 Apr 2023, Arsen Arsenović wrote:
>> I understand, just am wondering whether and why the : is required? I 
>> don't think we are using this construct anywhere else?
> Without them, this would happen:
> 
>   ~$ "${foo:=foo}"
>   bash: foo: command not found
>   ~ 127 $ unset foo
>   ~$ echo "${foo:=foo}"
>   foo
>   ~$ 

Ah, of course!

That's why I tend to use FOO=${FOO-barbar} in such cases - which is a tad 
more characters. :)

> Thank you!  Hopefully we get this just in time for 13 :)

The release is currently planned for the 26th and the udpated script is 
now live.

I just ran it and things seem to work just fine. Do you spot anything
unexpected?

Gerald
  

Gerald Pfeifer <gerald@pfeifer.com> writes:

> On Thu, 20 Apr 2023, Arsen Arsenović wrote:
>>> I understand, just am wondering whether and why the : is required? I 
>>> don't think we are using this construct anywhere else?
>> Without them, this would happen:
>> 
>>   ~$ "${foo:=foo}"
>>   bash: foo: command not found
>>   ~ 127 $ unset foo
>>   ~$ echo "${foo:=foo}"
>>   foo
>>   ~$ 
>
> Ah, of course!
>
> That's why I tend to use FOO=${FOO-barbar} in such cases - which is a tad 
> more characters. :)
>
>> Thank you!  Hopefully we get this just in time for 13 :)
>
> The release is currently planned for the 26th and the udpated script is 
> now live.

Perfect \o/

> I just ran it and things seem to work just fine. Do you spot anything
> unexpected?

Seems perfect, thank you!

Have a lovely day!  :)

> Gerald