bug#29188: [PATCH] texi2dvi usage doesn't work with <texinfo-4.9

[Bogdan]

Gavin Smith <gavinsmith0123@gmail.com>, Sun Mar 19 2023 11:17:31 
GMT+0100 (Central European Standard Time)
> On Sat, Mar 18, 2023 at 10:10:05PM +0100, Bogdan wrote:
> >   The problem was with "--build-dir=": the old texi2dvi (which is a shell
> > script) splits "--build-dir=xxx" into "--build-dir" and "xxx", interprets
> > the "--build-dir" switch as "--batch" (checks just the first letter, great)
> > and the "xxx" stays on the command line and is being treated as another
> > input file, causing the error.
> >
> >   Fortunately, since texinfo-4.9, one can set the build directory with an
> > environment variable "TEXI2DVI_BUILD_DIRECTORY". Unfortunately, texinfo has
> > a bug there, too. When setting "--build-dir=" on the command line, the build
> > mode is set to "tidy" (which cleans some log files, etc.). Fine. The problem
> > is that if you set the build directory using an environment variable, the
> > mode is NOT set to "tidy", leaving the logs files and failing tests.
> > Luckily, you can also set the build mode from an environment variable,
> > "TEXI2DVI_BUILD_MODE".
>
> It may fix the bug for <= texinfo 4.8 but can I suggest that having
> lengthy comments in code explaining why it is done one way and not
> another is pretty distracting for anybody trying to understand or
> modify the code in the future.


 I was thinking about that, but even with versioning I still believe 
it's worth to leave explanatory comments or even commented-out code 
just to show "don't do this".
 I kind of mimicked the existing behavior with my comments. There 
already are 4 lines explaining why we must set MAKEINFO and further 9 
lines explaining why we need /dev/null, -q (%TEXIQUIET%) and 
'--build-dir'.
 You can always merge with the comment and remove them immediately 
after, just to have them in the history.


>  Also note that texinfo 4.8 was released
> in 2004, nearly 20 years ago, so I question whether it is worth fixing
> this in a complicated way


 Yes, I noticed that too and was thinking about ignoring the bug. 
But, since I could make a fix that would work for both pre-4.9 (well, 
maybe not all the way to the very first version) and post-4.9, I gave 
it a try.


> for the benefit of the proprietary macOS
> operating system (I believe they use old versions of GNU programs to
> avoid using GPLv3-licensed code).


 This I didn't realize up till now. I read the bug, maybe just except 
the original subject... Anyway, always more compatibility, and that's 
something good, I guess.
 Should I skip fixing reported Automake problems on Solaris 
(proprietary) or OpenSolaris (discontinued/forked) for the same 
reason? Not that I have access to one, but maybe some VMs one day...

 Anyway, I just provide code the way I'd do it. It's up to "someone 
higher up", like you, to make the decision if the patch is to be 
merged, modified first, or to be simply left out for some reason. 
There surely are things I don't know about so my patches can be wrong 
or unacceptable for variety of reasons.

[Snip patch]

--
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org