Gavin Smith <gavinsmith0...@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
