Bug #37806 for ExtUtils-MakeMaker: Adding support for generating HTML manpages [PATCH]

Sun Jul 20 05:48:41 2008 GAAS [...] cpan.org - Ticket created

Subject:

Adding support for generating HTML manpages [PATCH]

The attached patch relative to 6.44 is derived from ActivePerl's support for generating HTML manpages. It's reworked to use the $Config{installhtml{1,3}dir} variables that is set up by the standard perl. If this patch is adopted then I'll make ActivePerl migrate to it as well, removing the bulk of the diffs we have against MakeMaker. BTW, any advice on how to write tests for this stuff?

Subject:

htmlify.patch

Message body is not shown because it is too large.

Thu Oct 16 10:57:35 2008 GAAS [...] cpan.org - Correspondence added

Do want this patch reworked in some way in order to include it?

Thu Oct 16 10:57:46 2008 GAAS [...] cpan.org - Status changed from 'new' to 'open'

Wed Apr 08 19:25:07 2009 mschwern [...] cpan.org - Correspondence added

Sorry for taking so long to look at this. Thanks for the work, I've patched this in. I'd intended to put it in a separate branch, so it can be poked at a bit, but git-svn decided otherwise. :/ I removed one bit of the patch. It snuck in a change to manifypods_target() that caused nothing to be output if INSTALLMAN*DIR aren't set. That would be a separate change. It interferes with the Cygwin tests (which arguably are broken because they don't do full initialization to get all the INSTALL* stuff set). Its not a show-stopper, but it would be nice if pod2html were reworked so that the interface doesn't suck balls. There's no need to mimic the real pod2html, pod2man only does that for backwards compat. Preferably so that we can generate multiple HTML pages from a single call to improve performance, like pod2man does. The extra switches that pod2html takes might be problematic, but perhaps pod2html can figure them out for itself rather than having them passed in.

Wed Apr 08 19:34:15 2009 mschwern [...] cpan.org - Correspondence added

I'm suspicious of the way that the htmlify code reuses MAN*PODS. This code in init_MANPODS() causes a problem: if ( $self->{"${man}PODS"} or ($self->{"INSTALL${man}DIR"} =~ /^(none|\s*)$/ and $self->{"INSTALLHTML${num}DIR"} =~ /^(none|\s*)$/) ) { $self->{"${man}PODS"} ||= {}; } Setting INSTALLMAN*DIR to "none" is no longer enough to cause MAN*PODS not to be built, as in the build_man.t tests. That's a regression. I'm not sure if its consequential, but it's a regression. Later in htmlifypods_target() it does voodoo on the MAN*PODS value to turn it into HTML. for my $name (sort keys %$pods) { my $html = $pods->{$name}; $html =~ s/\$$INST_MAN(\d)DIR$/\$(INST_HTML$1DIR)/g; $html =~ s/\$$MAN\dEXT$/html/g; That strikes me as being brittle. There's no need for it, those are our own values. Unless there's a compelling reason to reuse MAN*PODS, I think it would work out better if there were separate HTML*PODS.

Wed Apr 08 20:32:52 2009 mschwern [...] cpan.org - Severity Wishlist added

Wed Apr 08 23:38:07 2009 GAAS [...] cpan.org - Correspondence added

Thanks for picking this up. I'm off for a vacation now and will not be able to follow up on this for another 2 weeks or so.

Wed Dec 31 12:55:33 2014 ETJ [...] cpan.org - Correspondence added

HTML generation support was removed some time ago. Further to the discussion in https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/issues/111, I am extracting the points from the four HTML*DIR RT tickets onto the GH issue, then closing the tickets. The points disclosed in this ticket (must respect INSTALL* and PREFIX) are already covered by schwern's comment on a design for a doc plugin system. I am marking this ticket as resolved.

Wed Dec 31 12:55:39 2014 ETJ [...] cpan.org - Status changed from 'open' to 'resolved'