GNU bug report logs - #29188
texi2dvi usage doesn't work with <texinfo-4.9

Previous Next

To reply to this bug, email your comments to 29188 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Barry Anderson <z3ndrag0n <at> me.com>
To: bug-automake <at> gnu.org
Subject: Test suite failures on macOS High Sierra 10.13
Date: Tue, 7 Nov 2017 16:40:43 +1100

[test-suite.log (application/octet-stream, attachment)]

Message #8 received at 29188 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: Barry Anderson <z3ndrag0n <at> me.com>
Cc: 29188 <at> debbugs.gnu.org
Subject: Re: bug#29188: Test suite failures on macOS High Sierra 10.13
Date: Fri, 05 Jan 2018 03:36:36 +0100

Hello,

Barry Anderson <z3ndrag0n <at> me.com> writes:

> FAIL: t/distcheck-override-infodir
> ==================================
>
> distcheck-override-infodir: running makeinfo --version
> makeinfo (GNU texinfo) 4.8

All the build failures are related to the same issue caused by some
command line handling from this old 'texi2dvi' script (released in 2005)

> make[1]: Nothing to be done for `all'.
> TEXINPUTS="../..:$TEXINPUTS" \
> 	MAKEINFO='/bin/sh /Users/bwa/Downloads/automake-1.15.1/t/distcheck-override-infodir.dir/distcheck-override-infodir-1.0/missing makeinfo   -I ../..' \
> 	texi2dvi  --build-dir=main.t2d -o main.dvi  \
> 	../../main.texi
> /usr/bin/texi2dvi: Can't use option `--output' with more than one argument.

Since the behavior has been fixed in more recent texinfo releases, I am
not sure how to properly handle this for now.  More investigation would
be needed. 

Thanks for the report.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bogdan <bogdro_rep <at> gmx.us>
To: automake-patches <at> gnu.org, 29188 <at> debbugs.gnu.org
Subject: [bug#29188][PATCH] texi2dvi usage doesn't work with <texinfo-4.9
Date: Sat, 18 Mar 2023 22:10:05 +0100

[Message part 1 (text/plain, inline)]

Hello.

 The attached patch fixes bug#29188.

 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".

 That's why the new invocation of $(TEXI2DVI) and $(TEXI2PDF) has 2 
additional environment variables prepended.

 Testing:
- verified - the failing test doesn't work with old texinfo
- verified - the failing test works after the fix with old texinfo
- verified - the failing test works after the fix with new texinfo
- verified - all 84 texi+txi+info tests work after the fix with new 
texinfo (make check TESTS="`ls t/*texi*.sh t/*txi*.sh t/*info*.sh`")
- verified - all 84 texi+txi+info tests work after the fix with old 
texinfo

 Yes, I downloaded texinfo 4.8 just for this purpose.

 So, the old texinfo, which doesn't support "--build-dir=" or the 
environment variables, should work without change, and the new texinfo 
got switched from command-line switches to environment variables and 
should work as well, the same way it used to be.

-- 
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

[automake-old-texinfo-mail.diff (text/x-patch, attachment)]

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gavin Smith <gavinsmith0123 <at> gmail.com>
To: Bogdan <bogdro_rep <at> gmx.us>
Cc: 29188 <at> debbugs.gnu.org, automake-patches <at> gnu.org
Subject: Re: bug#29188: [PATCH] texi2dvi usage doesn't work with <texinfo-4.9
Date: Sun, 19 Mar 2023 10:17:31 +0000

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


> From 05cb873bec12638b0218afcb0a42076f571c7836 Mon Sep 17 00:00:00 2001
> From: Bogdan Drozdowski <>
> Date: Sat, 18 Mar 2023 21:46:36 +0100
> Subject: [PATCH] Support for texinfo<4.9
> 
> ---
>  lib/am/texibuild.am | 24 ++++++++++++++++++++++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/am/texibuild.am b/lib/am/texibuild.am
> index 6f6099c8d..b83dbfa44 100644
> --- a/lib/am/texibuild.am
> +++ b/lib/am/texibuild.am
> @@ -76,7 +76,17 @@ INFO_DEPS += %DEST_INFO_PREFIX%%DEST_SUFFIX%
>  ## avoid hitting a Texinfo bug that could cause low-probability racy
>  ## failure when doing parallel builds; see:
>  ## https://lists.gnu.org/archive/html/automake-patches/2012-06/msg00073.html
> -	$(TEXI2DVI) $(AM_TEXI2FLAGS) %MAKEINFOFLAGS% %TEXIQUIET% --build-dir=$(@:.dvi=.t2d) -o $@ %TEXIDEVNULL% \
> +## See bug#29188 for why we are not using "--build-dir=": the old texi2dvi
> +## splits "--build-dir=xxx" into "--build-dir" and "xxx", interprets the
> +## "--build-dir" as "--batch" (checks just 1 letter, great!) and the "xxx"
> +## stays on the command line as another input file, causing the error.
> +	TEXI2DVI_BUILD_DIRECTORY=$(@:.dvi=.t2d) \
> +## We need TEXI2DVI_BUILD_MODE=tidy due to another bug in texi2dvi:
> +## when "--build-dir" is passed on the command line, the build mode is
> +## automatically set to 'tidy' by default, but when the build directory
> +## is set using an environment variable, the build mode stays default.
> +	TEXI2DVI_BUILD_MODE=tidy \
> +	$(TEXI2DVI) $(AM_TEXI2FLAGS) %MAKEINFOFLAGS% %TEXIQUIET% -o $@ %TEXIDEVNULL% \
>  ?GENERIC?	%SOURCE%
>  ?!GENERIC?	`test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE%
>  
> @@ -97,7 +107,17 @@ INFO_DEPS += %DEST_INFO_PREFIX%%DEST_SUFFIX%
>  ## avoid hitting a Texinfo bug that could cause low-probability racy
>  ## failure when doing parallel builds; see:
>  ## https://lists.gnu.org/archive/html/automake-patches/2012-06/msg00073.html
> -	$(TEXI2PDF) $(AM_TEXI2FLAGS) %MAKEINFOFLAGS% %TEXIQUIET% --build-dir=$(@:.pdf=.t2p) -o $@ %TEXIDEVNULL% \
> +## See bug#29188 for why we are not using "--build-dir=": the old texi2dvi
> +## splits "--build-dir=xxx" into "--build-dir" and "xxx", interprets the
> +## "--build-dir" as "--batch" (checks just 1 letter, great!) and the "xxx"
> +## stays on the command line as another input file, causing the error.
> +	TEXI2DVI_BUILD_DIRECTORY=$(@:.pdf=.t2p) \
> +## We need TEXI2DVI_BUILD_MODE=tidy due to another bug in texi2dvi:
> +## when "--build-dir" is passed on the command line, the build mode is
> +## automatically set to 'tidy' by default, but when the build directory
> +## is set using an environment variable, the build mode stays default.
> +	TEXI2DVI_BUILD_MODE=tidy \
> +	$(TEXI2PDF) $(AM_TEXI2FLAGS) %MAKEINFOFLAGS% %TEXIQUIET% -o $@ %TEXIDEVNULL% \
>  ?GENERIC?	%SOURCE%
>  ?!GENERIC?	`test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE%
>  
> -- 
> 2.35.1
> 

Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bogdan <bogdro_rep <at> gmx.us>
To: Gavin Smith <gavinsmith0123 <at> gmail.com>
Cc: 29188 <at> debbugs.gnu.org, automake-patches <at> gnu.org
Subject: Re: bug#29188: [PATCH] texi2dvi usage doesn't work with <texinfo-4.9
Date: Sun, 19 Mar 2023 17:57:19 +0100

Gavin Smith <gavinsmith0123 <at> 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

Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gavin Smith <gavinsmith0123 <at> gmail.com>
To: Bogdan <bogdro_rep <at> gmx.us>
Cc: 29188 <at> debbugs.gnu.org, automake-patches <at> gnu.org
Subject: Re: bug#29188: [PATCH] texi2dvi usage doesn't work with <texinfo-4.9
Date: Sun, 19 Mar 2023 18:52:15 +0000

On Sun, Mar 19, 2023 at 05:57:19PM +0100, Bogdan wrote:
>  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.

Note that it's not up to me at all; I'm just an interested bystander when
it comes to Automake development.

If there is still a bug in texi2dvi could you please write to
bug-texinfo <at> gnu.org with the details?  Many thanks for your time spent
on this issue.

Message #41 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: bogdro_rep <at> gmx.us
Cc: gavinsmith0123 <at> gmail.com, automake-patches <at> gnu.org, 29188 <at> debbugs.gnu.org
Subject: Re: bug#29188: [PATCH] texi2dvi usage doesn't work with <texinfo-4.9
Date: Mon, 20 Mar 2023 08:36:11 -0600

Gavin, thanks for your comments. Always appreciated.

Bogdan, thanks for the patch. I (or the mythical Someone Else) will look
into it. My gut reaction is that it's good to make things work with old
versions in principle, although admittedly Apple's no-GPLv3 policy is
not something we care about supporting, particularly.

Regarding Solaris, proprietary operating systems have always been a
secondary target for GNU programs, which is why I have not felt bad
about ignoring the various Solaris bugs. However, it's fine to install
fixes for them. (I doubt the fixes are hard, either.) For what rms has
to say about platform support, see the end of
https://www.gnu.org/prep/maintain/html_node/Platforms.html.

Regarding verbose commentary, although it's true that in general they
can make understanding/modifying unnecessarily difficult, in the
particular case of Automake, they've proven to be very helpful. In
Automake, it's common for a given piece of code to be written in a
specific way for a specific reason (usually due to some old shell X,
some strange platform Y, etc.), and writing it in another way (usually
more "natural") doesn't work. So it's good to describe what's going on.

Certainly it would have been much harder for me to contribute anything
to automake without all the careful comments by Ralf, Stefano, Tom, and
all the other past maintainers. So I have no hesitation for giving a +1
for your detailed comments here, and in general. --thanks, karl.

Message #47 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bogdan <bogdro_rep <at> gmx.us>
To: Gavin Smith <gavinsmith0123 <at> gmail.com>
Cc: 29188 <at> debbugs.gnu.org, automake-patches <at> gnu.org
Subject: Re: bug#29188: [PATCH] texi2dvi usage doesn't work with <texinfo-4.9
Date: Mon, 20 Mar 2023 17:44:57 +0100

Gavin Smith <gavinsmith0123 <at> gmail.com>, Sun Mar 19 2023 19:52:15 
GMT+0100 (Central European Standard Time)
> On Sun, Mar 19, 2023 at 05:57:19PM +0100, Bogdan wrote:
>>   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.
> 
> Note that it's not up to me at all; I'm just an interested bystander when
> it comes to Automake development.


 Okay, for me as a beginner, anyone subscribed to automake-patches is 
someone who analyses the fixes people send, so someone "higher up" :).


> If there is still a bug in texi2dvi could you please write to
> bug-texinfo <at> gnu.org with the details?  Many thanks for your time spent
> on this issue.


 You're welcome, glad to help.
 The bug (or at least a surprising inconsistency) is still present in 
my texinfo-6.7, that's why I made the patch the way I made it. I'll 
check the newest version (7.0.2 as of this writing) or the repository 
a bit later. If still there, maybe I'll even send a 3-line patch for 
it :).


-- 
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

Message #50 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bogdan <bogdro_rep <at> gmx.us>
To: Karl Berry <karl <at> freefriends.org>
Cc: gavinsmith0123 <at> gmail.com, automake-patches <at> gnu.org, 29188 <at> debbugs.gnu.org
Subject: Re: bug#29188: [PATCH] texi2dvi usage doesn't work with <texinfo-4.9
Date: Mon, 20 Mar 2023 17:45:18 +0100

Karl Berry <karl <at> freefriends.org>, Mon Mar 20 2023 15:36:11 GMT+0100 
(Central European Standard Time)
> Gavin, thanks for your comments. Always appreciated.
> 
> Bogdan, thanks for the patch. I (or the mythical Someone Else) will look
> into it. My gut reaction is that it's good to make things work with old
> versions in principle, although admittedly Apple's no-GPLv3 policy is
> not something we care about supporting, particularly.


 Neither do I care for it so much. But if someone reports an actual 
problem that something doesn't work on another system and I can make 
it work, I can do the fix if it's important or not such a great amount 
of work. Not only here, also in my programs.
 It increases the potential user range, not only to systems taking 
software with licenses they like and patching them indefinitely to 
move them forward (OpenBSD? macOS?), but simply also to older Linux 
systems.


> Regarding Solaris, proprietary operating systems have always been a
> secondary target for GNU programs, which is why I have not felt bad
> about ignoring the various Solaris bugs. However, it's fine to install
> fixes for them. (I doubt the fixes are hard, either.) For what rms has
> to say about platform support, see the end of
> https://www.gnu.org/prep/maintain/html_node/Platforms.html.


 Got it. Do it if you can, because it widens the potential set of 
users. Don't do it if it creates a serious mess in the code.


> Regarding verbose commentary, although it's true that in general they
> can make understanding/modifying unnecessarily difficult, in the
> particular case of Automake, they've proven to be very helpful. In
> Automake, it's common for a given piece of code to be written in a
> specific way for a specific reason (usually due to some old shell X,
> some strange platform Y, etc.), and writing it in another way (usually
> more "natural") doesn't work. So it's good to describe what's going on.
> 
> Certainly it would have been much harder for me to contribute anything
> to automake without all the careful comments by Ralf, Stefano, Tom, and
> all the other past maintainers. So I have no hesitation for giving a +1
> for your detailed comments here, and in general. --thanks, karl.


 Thanks :)

-- 
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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.