[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-wget] pod2man --utf8 -> wget build failure

From: Karl Berry
Subject: [Bug-wget] pod2man --utf8 -> wget build failure
Date: Mon, 23 May 2016 20:56:19 GMT

Hi Giuseppe (and anyone),

wget's doc/Makefile.am assumes that --utf8 is supported:

$(MAN): wget.pod
        $(POD2MAN) --center [...] --utf8 $? > $@

(It's also assuming GNU make with the $? and $@, I believe, but never
mind, that's a different issue.)

Unfortunately, not all pod2man's have --utf8.  It was introduced in a
somewhat recent version of Perl.  Exactly which version does not matter.

Thus, the main bug: as far as I can see, the standard build process
(configure && make install) should not invoke pod2man at all, any more
than it should invoke makeinfo, and for all the same reasons.  That is,
the tarball should ship with the pod2man-generated file, just as it
ships with the makeinfo-generated file.


- configure could check if pod2man supports --utf8 and avoid using it if

- not that I expect you to change it, but the conversion of the Texinfo
manual to POD seems baroque and unnecessary to me.  You could have a
minimal man page created with help2man instead, like most GNU programs.

- I have even less expectation of you changing this, but the usage of
@documentencoding UTF-8 (when unnecessary) in Texinfo is unfriendly to
non-UTF-8 programmers.  UTF-8 quotes appear as binary
garbage in the C locale, thus the manual becomes unusable, since quotes
are so pervasive in Texinfo output.  (I'll spare you the reasons why I
use LC_ALL=C, but will ask you to believe me, I don't do it lightly.)

At any rate, I don't see that UTF-8 actually gains anything here
As far as I can see, the names can be represented perfectly well using
Texinfo -- a 7-bit ASCII input file using Texinfo commands and no
@documentencoding command should work fine.  (If there are some
diacritics unsupported by Texinfo, we can change that.)  The HTML/PDF
output will be correct and have the accents, and the plain text output
will do as well as it can.

What's unnecessary, indeed undesirable, are the @iftex conditionals that
you removed.  If the @iftex branches were restored over the direct
UTF-8 input, all the problems would go away ... --best, karl.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]