Skip Menu |

This queue is for tickets about the podlators CPAN distribution.

Report information
The Basics
Id: 111156
Status: resolved
Priority: 0/
Queue: podlators

People
Owner: RRA [...] cpan.org
Requestors: ntyni [...] iki.fi
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: 4.04
Fixed in: 4.05



Subject: survive when Encode cannot be loaded
Hi Russ, it would be nice if Pod::Man didn't bail out straight away if Encode can't be loaded, so that it could be still be used when the utf8 option is not set. My use case is cross building the perl 5 distribution: the 'installman' phase (that uses Pod::Man without 'utf8') is currently the only one that requires Config.pm for the target perl, with a full perl that can load XS modules. This is an awkward combination; see http://www.nntp.perl.org/group/perl.perl5.porters/2013/01/msg197625.html for some background information. Having 'installman' work without Encode would enable running it with miniperl (which is built without dynamic loading.) The attached proposed patch defers loading Encode to the point where Encode::encode() is actually needed. YMMV; it might be useful to output a warning at load time rather than be silent up until a hard failure at runtime? I'm aware that this would create some expectations of keeping basic things working in the future without XS modules, and you may be consider that somewhat limiting for development. I'd like to point out that Pod::Simple, currently the only real dependency of Pod::Man, also degrades gracefully when Encode doesn't work (although it looks like this is done mainly to support perls built without the Encode extension.) So this isn't quite unheard of. Please let me know what you think, and thanks for your work as always. -- Niko Tyni ntyni@debian.org
Subject: 0001-Amend-Pod-Man-to-work-with-miniperl-no-dynamic-loadi.patch
From d052b97c98bea4d2cd8d745bca3e77892095f67c Mon Sep 17 00:00:00 2001 From: Niko Tyni <ntyni@debian.org> Date: Mon, 11 Jan 2016 18:44:55 +0200 Subject: [PATCH] Amend Pod::Man to work with miniperl (no dynamic loading) This is to allow cross-compilation builds of the Perl distribution to run the 'installman' target using a host miniperl instead of the built Perl binary. See http://www.nntp.perl.org/group/perl.perl5.porters/2013/01/msg197625.html for some context. --- lib/Pod/Man.pm | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/lib/Pod/Man.pm b/lib/Pod/Man.pm index 24e49a0..7f09381 100644 --- a/lib/Pod/Man.pm +++ b/lib/Pod/Man.pm @@ -31,7 +31,6 @@ use subs qw(makespace); use vars qw(@ISA %ESCAPES $PREAMBLE $VERSION); use Carp qw(croak); -use Encode qw(encode); use Pod::Simple (); @ISA = qw(Pod::Simple); @@ -775,6 +774,10 @@ sub start_document { if ($flag & PerlIO::F_UTF8 ()) { $$self{ENCODE} = 0; } + }; + if ($$self{ENCODE}) { + eval { require Encode; Encode->import("encode"); 1; } + or croak "Encode::encode() needed but could not be loaded: $@" } } -- 2.6.4
Subject: Re: [rt.cpan.org #111156] survive when Encode cannot be loaded
Date: Wed, 13 Jan 2016 11:14:52 -0800
To: "ntyni\ [...] iki.fi via RT" <bug-podlators [...] rt.cpan.org>
From: Russ Allbery <rra [...] cpan.org>
"ntyni@iki.fi via RT" <bug-podlators@rt.cpan.org> writes: Show quoted text
> it would be nice if Pod::Man didn't bail out straight away if Encode > can't be loaded, so that it could be still be used when the utf8 option > is not set.
Show quoted text
> My use case is cross building the perl 5 distribution: the 'installman' > phase (that uses Pod::Man without 'utf8') is currently the only one that > requires Config.pm for the target perl, with a full perl that can load > XS modules. This is an awkward combination; see > http://www.nntp.perl.org/group/perl.perl5.porters/2013/01/msg197625.html > for some background information. Having 'installman' work without > Encode would enable running it with miniperl (which is built without > dynamic loading.)
Show quoted text
> The attached proposed patch defers loading Encode to the point where > Encode::encode() is actually needed. YMMV; it might be useful to output > a warning at load time rather than be silent up until a hard failure at > runtime?
I can do this for as long as this stuff is all gated on the utf8 option. However, I'm not sure that I can promise that this will keep working, since in the long run we're going to want Unicode output to be the default. It seems like most *roff implementations now handle this properly. I'm happy to fix this for right now, but I'm worried about the long-term sustainability of this approach. Maybe in the future I can just degrade the same way Pod::Simple does? My recollection is that this code is relevant for Perl core and generating core man pages, since some of them do contain non-ASCII characters for people's names. I'm not sure how this is handled now. Are they regenerated later with a full Perl to get the correct output? -- #!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker $^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD, 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{ rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
Subject: Re: [rt.cpan.org #111156] survive when Encode cannot be loaded
Date: Wed, 13 Jan 2016 23:25:40 +0200
To: Russ Allbery via RT <bug-podlators [...] rt.cpan.org>
From: Niko Tyni <ntyni [...] iki.fi>
On Wed, Jan 13, 2016 at 02:15:13PM -0500, Russ Allbery via RT wrote: Show quoted text
> "ntyni@iki.fi via RT" <bug-podlators@rt.cpan.org> writes: >
> > it would be nice if Pod::Man didn't bail out straight away if Encode > > can't be loaded, so that it could be still be used when the utf8 option > > is not set.
Show quoted text
> I can do this for as long as this stuff is all gated on the utf8 option. > > However, I'm not sure that I can promise that this will keep working, > since in the long run we're going to want Unicode output to be the > default. It seems like most *roff implementations now handle this > properly. I'm happy to fix this for right now, but I'm worried about the > long-term sustainability of this approach. Maybe in the future I can just > degrade the same way Pod::Simple does?
Yeah, I suppose that would make sense. So when asked for utf8 but Encode unavailable, it would just warn and then carry on as if utf8 was unset? See the attached patch. Show quoted text
> My recollection is that this code is relevant for Perl core and generating > core man pages, since some of them do contain non-ASCII characters for > people's names. I'm not sure how this is handled now. Are they > regenerated later with a full Perl to get the correct output?
I believe some things are currently just broken. See for instance perltw.1, where the POD source is presumably Chinese utf8 characters, which mostly end up as the infamous 'X' characters in the man page. The man pages certainly don't get regenerated with the 'utf8' option at the moment. To clarify, "normal" (native) Perl builds currently do run 'installman' with a full perl and Encode available - the one that was just built. This problem only comes up because that perl can't be executed when it's cross compiled for a different architecture. And using a full perl from the build system needs other sorts of fiddling, to avoid it trying to load non-compatible XS extensions and so forth. So, as 'installman' doesn't use the Pod::Man utf8 option, Encode currently gets loaded but not used, making the proposed shortcut attractive. I can see now that this is indeed only a short term approach, and I should probably come up with something better straight away rather than waiting for it to break when 'utf8' is made the default. So I guess simply rejecting this ticket would be OK by me, but I wonder if graceful degradation to non-utf8 output if Encode is not available would be a worthy change on its own, even without these cross build considerations? -- Niko Tyni ntyni@debian.org

Message body is not shown because sender requested not to inline it.

Subject: Re: [rt.cpan.org #111156] survive when Encode cannot be loaded
Date: Thu, 14 Jan 2016 22:34:41 +0200
To: Russ Allbery via RT <bug-podlators [...] rt.cpan.org>
From: Niko Tyni <ntyni [...] iki.fi>
On Wed, Jan 13, 2016 at 11:25:40PM +0200, Niko Tyni wrote: Show quoted text
> On Wed, Jan 13, 2016 at 02:15:13PM -0500, Russ Allbery via RT wrote:
> > "ntyni@iki.fi via RT" <bug-podlators@rt.cpan.org> writes: > >
> > > it would be nice if Pod::Man didn't bail out straight away if Encode > > > can't be loaded, so that it could be still be used when the utf8 option > > > is not set.
>
> > I can do this for as long as this stuff is all gated on the utf8 option.
Show quoted text
> I can see now that this is indeed only a short term approach, and I > should probably come up with something better straight away rather than > waiting for it to break when 'utf8' is made the default. > > So I guess simply rejecting this ticket would be OK by me, but I wonder > if graceful degradation to non-utf8 output if Encode is not available > would be a worthy change on its own, even without these cross build > considerations?
Thinking about this some more, the 'graceful degradation' approach would make cross building perl work now, and still keep it working when Pod::Man starts to default to utf8 mode (just without benefits from better man pages.) This means it would definitely be an improvement to the current situation, where cross building perl is broken at the 'make install' phase, and still leave room for a better solutions in the future. So I'd still like to see one of these patches applied :) Let me know if you'd like me to amend the patch somehow; some improvements I can think of are making the full test suite work when Encode can't be loaded, and limiting the number of warnings if Pod::Man->new(utf8=>1) gets called repeatedly. -- Niko
Subject: Re: [rt.cpan.org #111156] survive when Encode cannot be loaded
Date: Sat, 16 Jan 2016 09:58:24 -0800
To: "ntyni\ [...] iki.fi via RT" <bug-podlators [...] rt.cpan.org>
From: Russ Allbery <rra [...] cpan.org>
"ntyni@iki.fi via RT" <bug-podlators@rt.cpan.org> writes: Show quoted text
> Thinking about this some more, the 'graceful degradation' approach would > make cross building perl work now, and still keep it working when > Pod::Man starts to default to utf8 mode (just without benefits from > better man pages.)
Show quoted text
> This means it would definitely be an improvement to the current > situation, where cross building perl is broken at the 'make install' > phase, and still leave room for a better solutions in the future.
Show quoted text
> So I'd still like to see one of these patches applied :)
Yup, I'm totally on board! I'll take a look at the patches today. Sorry about the delays -- nothing related to the patch, just not having lots of time to look at this during the work week. -- #!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker $^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD, 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{ rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
Merged in 4.05, now released.