Skip Menu |

This queue is for tickets about the Module-Build CPAN distribution.

Report information
The Basics
Id: 53478
Status: resolved
Priority: 0/
Queue: Module-Build

People
Owner: Nobody in particular
Requestors: KEICHNER [...] cpan.org
Cc: JDB [...] cpan.org
klaus03 [...] gmail.com
AdminCc:

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)



CC: klaus03 [...] gmail.com
Subject: ExtUtils::Command::MM - resolving problems with ActiveState
As described in http://groups.google.com/group/perl.module-authors/msg/2f6db1f9dee97858 ,
 
There are problems in the way that Module::Build interacts with ActiveState Perl, those problems are:

- HTML generated with Module::Build is not conform
  with the way HTML is generated by ActiveState /
  ExtUtils::MakeMaker 

- with Module::Build, ActiveState's Table of Contents
  (html\index.html) is not updated (with
  ExtUtils::MakeMaker it is updated) 

- with Module::Build, the file 'lib/perllocal.pod' is not
  updated, which leaves ActiveState's PPM-utility in
  the dark about the newly installed distribution. (with
  ExtUtils::MakeMaker the file 'lib/perllocal.pod' is
  correctly updated) 

I have a patch that fixes those problems. 3 modules are to be patched:
"ActivePerl::DocTools::Pod", "ExtUtils::Command::MM" and "Module::Build::Base".

The main patch is in "Module::Build::Base", but before this can be done, "ExtUtils::Command::MM" needs to be patched as described in the attached file "ExtUtils-Command-MM.txt". (I will also talk to ActiveState about patching "ActivePerl::DocTools::Pod")

Functionally nothing changes in "ExtUtils::Command::MM", only a new subroutine perllocal_instd() will be exposed (to be called later by "Module::Build::Base") that allows to extract the textual representation of what the existing subroutine perllocal_install() does.
Subject: ExtUtils-Command-MM.txt
--- lib/ExtUtils/Command/MM.pm.bak 2010-01-06 15:17:20.201000000 +0100 +++ lib/ExtUtils/Command/MM.pm 2010-01-06 15:17:20.201000000 +0100 @@ -206,6 +206,13 @@ my @mod_info = $Is_VMS ? split /\|/, <STDIN> : @ARGV; + print perllocal_instd($type, $name, @mod_info); +} + +sub perllocal_instd { + my($type, $name) = splice(@_, 0, 2); + my @mod_info = @_; + my $pod; $pod = sprintf <<POD, scalar localtime; =head2 %s: C<$type> L<$name|$name> @@ -228,9 +235,8 @@ $pod .= "=back\n\n"; $pod =~ s/^ //mg; - print $pod; - return 1; + return $pod; } =item B<uninstall>
CC: yves [...] cpan.org, Ken Williams <kwilliams [...] cpan.org>
Subject: Re: [rt.cpan.org #53478] ExtUtils::Command::MM - resolving problems with ActiveState
Date: Thu, 07 Jan 2010 14:03:08 -0800
To: bug-ExtUtils-MakeMaker [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Thanks for noticing all this and working up some patches. Unfortunately I can't accept them quite so quickly, there's some things to discuss. Klaus Eichner via RT wrote: Show quoted text
> There are problems in the way that Module::Build interacts with > ActiveState Perl, those problems are: > > - HTML generated with Module::Build is not conform > with the way HTML is generated by ActiveState / > ExtUtils::MakeMaker
Should MB be conforming to ActiveState or ActiveState to MB? What's the difference between the two? I think that needs to be discussed rather than just blindly doing what ActiveState does. The amount of ActiveState specific code the patch puts into MB also makes me unhappy. I would rather see them harmonize than have a "if we're on ActiveState do X, else do Y". Having an HTML TOC available everywhere might not be a bad idea. Show quoted text
> - with Module::Build, ActiveState's Table of Contents > (html\index.html) is not updated (with > ExtUtils::MakeMaker it is updated)
MakeMaker has no built in HTML generation support, so this is an ActiveState patch. Upgrading MakeMaker from a non-ActiveState source will make it go away. Putting HTML building back into MakeMaker stalled out last year. You can see where this left off. http://github.com/schwern/extutils-makemaker/tree/installhtml https://rt.cpan.org/Ticket/Display.html?id=37806 Show quoted text
> - with Module::Build, the file 'lib/perllocal.pod' is not > updated, which leaves ActiveState's PPM-utility in > the dark about the newly installed distribution. (with > ExtUtils::MakeMaker the file 'lib/perllocal.pod' is > correctly updated)
What is PPM using perllocal for? Show quoted text
> I have a patch that fixes those problems. 3 modules are to be patched: > "ActivePerl::DocTools::Pod", "ExtUtils::Command::MM" and > "Module::Build::Base". > > The main patch is in "Module::Build::Base", but before this can be done, > "ExtUtils::Command::MM" needs to be patched as described in the attached > file "ExtUtils-Command-MM.txt". (I will also talk to ActiveState about > patching "ActivePerl::DocTools::Pod") > > Functionally nothing changes in "ExtUtils::Command::MM", only a new > subroutine perllocal_instd() will be exposed (to be called later by > "Module::Build::Base") that allows to extract the textual representation > of what the existing subroutine perllocal_install() does.
Module::Build shouldn't be depending on MakeMaker, particularly new versions of MakeMaker, so the patch is right out. Sorry. perllocal.pod is pretty much a dead end, its not particularly useful or accurate information and not in a particularly useful format. If you want to pursue having MB update it, it should probably be done inside ExtUtils::Install which both MakeMaker and MB use. -- 151. The proper way to report to my Commander is "Specialist Schwarz, reporting as ordered, Sir" not "You can't prove a thing!" -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
RT-Send-CC: schwern [...] pobox.com, klaus03 [...] gmail.com, yves [...] cpan.org, kwilliams [...] cpan.org
Le Jeu 07 Jan 2010 17:03:31, schwern@pobox.com a écrit :
Show quoted text
> Thanks for noticing all this and working up some patches.

Thanks for your quick response.

Show quoted text
> Unfortunately I
> can't accept them quite so quickly, there's some things to discuss.
>
> Klaus Eichner via RT wrote:
> > There are problems in the way that Module::Build interacts with
> > ActiveState Perl, those problems are:
> >
> > - HTML generated with Module::Build is not conform
> > with the way HTML is generated by ActiveState /
> > ExtUtils::MakeMaker
>
> Should MB be conforming to ActiveState or ActiveState to MB?
>  What's the difference between the two? I think that needs to
> be discussed rather than just blindly doing what ActiveState
> does.

I agree.

There are 3 differences in the way that MB and AS (=ActiveState/ExtUtils::MakeMaker) use Pod::Html::pod2html():

(Diff 1) In case of $self->installdir = 'site'
   * MB uses option "--htmlroot =../../../site" in Pod::Html::pod2html()
   * AS uses option "--htmlroot=../../.." in Pod::Html::pod2html()

(Diff 2) other options in Pod::Html::pod2html()
  * MB uses option "--flush" and "--title", but has no option "--quiet", "--index" or "--libpods=perlfunc:..."
  * AS has no option "--flush" or "--title", but uses option "--quiet", "--index" and "--libpods=perlfunc:..."

(Diff 3) The way the output of Pod::Html::pod2html() is treated:
  * MB accepts the HTML that is generated by Pod::Html::pod2html() as is
  * AS manipulates the HTML that is generated by Pod::Html::pod2html()
 
As a consequence of point (Diff 3) AS performs the following manipulations in ActivePerl::DocTools::Pod, subroutine pod2html:

The following manipulations, performed by AS but not by MB, are *not* AS-specific:
  * (Diff 3-a1) Comment found in in ActivePerl::DocTools::Pod
     # Despite what Pod::Html says, this is not XHTML.
     # IE6 doesn't display things correctly with the wrong DOCTYPE.
  * (Diff 3-a2) Modify <!DOCTYPE>
      before: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
      after: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
  * (Diff 3-a3) Modify <html xmlns="http://www.w3.org/1999/xhtml"> into a simple <html>
  * (Diff 3-a4) if  "--index" was requested, then extract /<TITLE>(.*?)<\/TITLE>/i from the HTML and write <h1><a>$1</a></h1>

The following manipulations, again performed by AS but not by MB, *are* AS-specific:
  * (Diff 3-b1) Add the following lines directly after <head>
      <!-- saved from url=(0017)http://localhost/ -->
      <script language="JavaScript" src="$html_root/displayToc.js"></script>
      <script language="JavaScript" src="$html_root/tocParas.js"></script>
      <script language="JavaScript" src="$html_root/tocTab.js"></script>
      <link rel="stylesheet" type="text/css" href="$html_root/scineplex.css">
  * (Diff 3-b2) Add the following line before <p><a name="__index__"></a></p>,... or before <h1>...</h1>
     <script>writelinks('__top__',$depth);</script>

> The amount of ActiveState specific code the patch puts into MB also
> makes me unhappy. I would rather see them harmonize than
> have a "if we're on ActiveState do X, else do Y".

I agree, and I think that, with regards to points (Diff 1) and (Diff 2), AS should move this functionality (which is currently used only in ExtUtils::MakeMaker) to MB, wrapped into an ActiveState Module.

With regards to point (Diff 3 a), the non-AS specific part: I think that MB should investigate the comments (Diff 3-a1) --> ("...IE6 doesn't display things correctly...") and the manipulation (Diff 3-a4) --> ("write <h1><a>$1</a></h1>") and decide whether or not to conform with AS.

With regards to point (Diff 3 b), the AS specific part: I think that AS, again, should move this functionality (which is currently used only in ExtUtils::MakeMaker) to MB, wrapped into an ActiveState Module.

> Having an HTML TOC available everywhere
> might  not be a bad idea. 

I currently have some free time, I could write some code. Do you have any suggestions as to where the code should be placed (an existing module ?, or a new module ? in the Module::Build namespace ?)

> > - with Module::Build, ActiveState's Table of Contents
> > (html\index.html) is not updated (with
> > ExtUtils::MakeMaker it is updated)
>
> MakeMaker has no built in HTML generation support, so this is an
> ActiveState
> patch. Upgrading MakeMaker from a non-ActiveState source will make it
> go away.
>
> Putting HTML building back into MakeMaker stalled out last year. You
> can see
> where this left off.
> http://github.com/schwern/extutils-makemaker/tree/installhtml
> https://rt.cpan.org/Ticket/Display.html?id=37806&nbsp;

Another good reason to use Module::Build

> > - with Module::Build, the file 'lib/perllocal.pod' is not
> > updated, which leaves ActiveState's PPM-utility in
> > the dark about the newly installed distribution. (with
> > ExtUtils::MakeMaker the file 'lib/perllocal.pod' is
> > correctly updated) 

[re-arranged from the bottom]:
> perllocal.pod is pretty much a dead end, its not particularly
> useful or accurate information and not in a particularly
> useful format. If you want to pursue having MB update it,
> it should probably be done inside ExtUtils::Install which
> both MakeMaker and MB use.

> What is PPM using perllocal for?

PPM maintains its own SQLite DB (in "etc/ppm-perl-area.db") as a copy of the usual ".packlist" files under "lib/auto/...". In order to keep "etc/ppm-perl-area.db" synchronised with the ".packlist" files, the PPM utility needs to know the date-stamp of the most recent ".packlist" and compare it with the date-stamp of "etc/ppm-perl-area.db".
 
I don't know, but it seems that someone decided that the number of ".packlist" files is simply too big to be scanned each time just to find out whether or not to synchronise (there could be hundreds or even thousands of ".packlist" files) and they may have simply (mis-)used the date-stamp of "perllocal.pod" as an approximation of the date-stamp of the most recent ".packlist" file.

It seems to me that ActiveState is not using Module::Build, otherwise they would have noticed that "perllocal.pod" is not used anymore.

> > I have a patch that fixes those problems. 3 modules are to be
> patched:
> > "ActivePerl::DocTools::Pod", "ExtUtils::Command::MM" and
> > "Module::Build::Base".
> >
> > The main patch is in "Module::Build::Base", but before this can be
> done,
> > "ExtUtils::Command::MM" needs to be patched as described in the
> attached
> > file "ExtUtils-Command-MM.txt". (I will also talk to ActiveState
> about
> > patching "ActivePerl::DocTools::Pod")
> >
> > Functionally nothing changes in "ExtUtils::Command::MM", only a new
> > subroutine perllocal_instd() will be exposed (to be called later by
> > "Module::Build::Base") that allows to extract the textual
> representation
> > of what the existing subroutine perllocal_install() does.
>
> Module::Build shouldn't be depending on MakeMaker,
> particularly new versions of MakeMaker, so the patch is
> right out. Sorry.

OK
 
RT-Send-CC: schwern [...] pobox.com, klaus03 [...] gmail.com, yves [...] cpan.org, kwilliams [...] cpan.org
Le Ven 08 Jan 2010 10:14:28, KEICHNER a écrit :
Show quoted text
> There are 3 differences in the way that MB and AS
> (=ActiveState/ExtUtils::MakeMaker) use Pod::Html::pod2html():
>
> (Diff 1) In case of $self->installdir = 'site'
> * MB uses option "--htmlroot =../../../site" in Pod::Html::pod2html()
> * AS uses option "--htmlroot=../../.." in Pod::Html::pod2html()
>
> (Diff 2) other options in Pod::Html::pod2html()
> * MB uses option "--flush" and "--title", but has no option "--quiet",
> "--index" or "--libpods=perlfunc:..."
> * AS has no option "--flush" or "--title", but uses option "--quiet",
> "--index"
> and "--libpods=perlfunc:..."
>
> (Diff 3) The way the output of Pod::Html::pod2html() is treated:
> * MB accepts the HTML that is generated by Pod::Html::pod2html() as is
> * AS manipulates the HTML that is generated by Pod::Html::pod2html()

I have forgotten about (Diff 4):

 (Diff 4) more options in Pod::Html::pod2html()
    * MB has no option "--css", "--header" or "--backlink"
    * AS uses option "--css=../../../Active.css", "--header" and "--backlink=Back to Top".

(Diff 4) is AS specific, AS should move this functionality (which is currently used only in ExtUtils::MakeMaker) to MB, wrapped into an ActiveState Module.
RT-Send-CC: schwern [...] pobox.com, klaus03 [...] gmail.com, yves [...] cpan.org, kwilliams [...] cpan.org
Show quoted text
> Le Ven 08 Jan 2010 10:14:28, KEICHNER a écrit :
> (Diff 4) more options in Pod::Html::pod2html()
> * MB has no option "--css", "--header" or "--backlink"
> * AS uses option "--css=../../../Active.css", "--header" and "--
> backlink=Back
> to Top". 

Sorry, I've got my logic wrong, (Diff 4) should read:

  * MB has option "--header" and "--backlink=Back to Top"
  * AS has no option "--header" or "--backlink" 

Show quoted text
# option "--css=../../../Active.css" is correctly
# handled by both MB *and* AS, and therefore
# not an issue.

(Diff 4) still remains AS specific, AS should move this functionality (which is currently used only in ExtUtils::MakeMaker) to MB, wrapped into an ActiveState Module.
I've moved this over into Module::Build's queue as MakeMaker doesn't even generate HTML.
So, not being an HTML expert, it sounds to me like there's some concrete work which can be done if you want it. The non-AS changes to the HTML output can be applied definitely at the Pod::Html level (since they just seem like invalid or overcomplicated HTML) and perhaps at the Module::Build level. Ken will have to decide how much responsibility MB wants to have over the HTML it produces or whether to leave it in Pod::Html's hands. Generating and updating a table of contents would be handy. I can't really say where it should go, but the code should be fairly mobile so pick an option and do it. As for PPM depending on perllocal AND packlists... both of those are dead end tech so I'm not sure what's to be done about that. Patching ExtUtils::Install to have an option to update perllocal sounds like the way to go. I can't really speak sensibly to the other stuff.
RT-Send-CC: klaus03 [...] gmail.com, bug-ExtUtils-MakeMaker [...] rt.cpan.org
I have created a ticket to change ActivePerl::DocTools::Pod at http://bugs.activestate.com/show_bug.cgi?id=85755 I haven't had any reply from Activestate yet, I fear that this ticket is not picked up. I really would like to discuss this with ActiveState. Does anybody have an e-mail address at Activestate where I can bring http://bugs.activestate.com/show_bug.cgi?id=85755 to their attention ?
CC: Jan Dubois <jand [...] activestate.com>
Subject: Re: [rt.cpan.org #53478] Diffs with ActiveState HTML generation and PPM compatibility
Date: Sun, 10 Jan 2010 00:35:28 -0800
To: bug-Module-Build [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Klaus Eichner via RT wrote: Show quoted text
> Queue: Module-Build > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=53478 > > > I have created a ticket to change ActivePerl::DocTools::Pod at > http://bugs.activestate.com/show_bug.cgi?id=85755 > > I haven't had any reply from Activestate yet, I fear that this ticket > is not picked up. > > I really would like to discuss this with ActiveState. Does anybody have > an e-mail address at Activestate where I can bring > http://bugs.activestate.com/show_bug.cgi?id=85755 to their attention ?
I usually poke Jan Dubois whom I've CC'd. -- You know what the chain of command is? It's the chain I go get and beat you with 'til you understand who's in ruttin' command here. -- Jayne Cobb, "Firefly"
RT-Send-CC: bug-ExtUtils-MakeMaker [...] rt.cpan.org, schwern [...] pobox.com, klaus03 [...] gmail.com, jand [...] activestate.com
Le Dim 10 Jan 2010 03:35:50, schwern@pobox.com a écrit : Show quoted text
> Klaus Eichner via RT wrote:
> > Queue: Module-Build > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=53478 > > > > > I have created a ticket to change ActivePerl::DocTools::Pod at > > http://bugs.activestate.com/show_bug.cgi?id=85755 > > > > I haven't had any reply from Activestate yet, I fear that this
ticket Show quoted text
> > is not picked up. > > > > I really would like to discuss this with ActiveState. Does anybody
have Show quoted text
> > an e-mail address at Activestate where I can bring > > http://bugs.activestate.com/show_bug.cgi?id=85755 to their
attention ? Show quoted text
> > I usually poke Jan Dubois whom I've CC'd.
Thanks, I now have a reply on http://bugs.activestate.com/show_bug.cgi? id=85755 from ActiveState.
Subject: RE: [rt.cpan.org #53478] Diffs with ActiveState HTML generation and PPM compatibility
Date: Thu, 14 Jan 2010 16:24:05 -0800
To: "'Michael G Schwern'" <schwern [...] pobox.com>, <bug-Module-Build [...] rt.cpan.org>
From: "Jan Dubois" <jand [...] activestate.com>
Schwern wrote: Show quoted text
> Thanks for noticing all this and working up some patches.
Thank you for this from me as well! Show quoted text
> Unfortunately I can't accept them quite so quickly, there's some > things to discuss.
Indeed. I don't think putting the HTML generation code into EU::MM and M::B is the right approach. Ideally we could figure out some kind of hook into EU::Install to update the HTML docs during installation and get rid of any ActivePerl specific code in EU::MM and M::B instead. Unfortunately I cannot promise when anyone on the ActivePerl team will have time to do it. I'll try to bring it back on our agenda, but it always seems to be prioritized down so that we don't actually get around to do something about it. :( Note that as a workaround you can always run `ap-update-html` from the perl/bin directory. It will re-generate HTML docs for all *.pm and *.pod files in the Perl directories that are either non-existent or out-of-date (according to their respective mtimes). It will also update the TOC. Show quoted text
> Klaus Eichner via RT wrote:
> > - with Module::Build, the file 'lib/perllocal.pod' is not updated, > > which leaves ActiveState's PPM-utility in the dark about the newly > > installed distribution. (with ExtUtils::MakeMaker the file > > 'lib/perllocal.pod' is correctly updated)
> > What is PPM using perllocal for?
It actually doesn't. PPM uses the .packlist files to locate packages that have been installed manually or via the CPAN shell. This allows it to both warn before installing older versions via PPM, and also to offer upgrades if a newer version is available from any PPM repository. It is not clear to me why M::B doesn't write .packlist files though; I though EU::Install would be taking care of that. I guess I need to take another look. Cheers, -Jan
Subject: Re: [rt.cpan.org #53478] Diffs with ActiveState HTML generation and PPM compatibility
Date: Thu, 14 Jan 2010 19:55:18 -0500
To: bug-Module-Build [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
On Thu, Jan 14, 2010 at 7:24 PM, jand@ActiveState.com via RT <bug-Module-Build@rt.cpan.org> wrote: Show quoted text
> It is not clear to me why M::B doesn't write .packlist files though; > I though EU::Install would be taking care of that.  I guess I need to > take another look.
It does -- or at least, has since 0.2609 (from 2005). Prior to 0.36, it would not write them if module_name was not set. Now it tries to guess a module name the same way that EU::MM does. -- David
Subject: RE: [rt.cpan.org #53478] Diffs with ActiveState HTML generation and PPM compatibility
Date: Thu, 14 Jan 2010 17:30:24 -0800
To: <bug-Module-Build [...] rt.cpan.org>
From: "Jan Dubois" <jand [...] activestate.com>
Klaus Eichner wrote: Show quoted text
> I don't know, but it seems that someone decided that the number of > ".packlist" files is simply too big to be scanned each time just to > find out whether or not to synchronise (there could be hundreds or > even thousands of ".packlist" files) and they may have simply (mis- > )used the date-stamp of "perllocal.pod" as an approximation of the > date-stamp of the most recent ".packlist" file.
Ah, so it does use perllocal.pod. Seems like you know the code better than I do. :) So I guess I wouldn't mind seeing perllocal.pod at least being "touched" by a M::B install, even if it doesn't write to it. Again, updating perllocal.pod should be done by EU::Install and not by EU::MM and M::B though. Show quoted text
> It seems to me that ActiveState is not using Module::Build, otherwise > they would have noticed that "perllocal.pod" is not used anymore.
That is correct. Almost all modules that use M::B still provide a compatible Makefile.PL, so there has been little reason to use M::B in the past. Cheers, -Jan
RT-Send-CC: bug-ExtUtils-MakeMaker [...] rt.cpan.org, dagolden [...] cpan.org, klaus03 [...] gmail.com, jand [...] activestate.com
Le Jeu 14 Jan 2010 19:24:22, jand@ActiveState.com a écrit : Show quoted text
> Schwern wrote:
> > Thanks for noticing all this and working up some patches.
> > Thank you for this from me as well! >
> > Unfortunately I can't accept them quite so quickly, there's some > > things to discuss.
> > Indeed. I don't think putting the HTML generation code into EU::MM and > M::B is the right approach. Ideally we could figure out some kind of > hook into EU::Install to update the HTML docs during installation and > get rid of any ActivePerl specific code in EU::MM and M::B instead.
I perfectly agree with your policy, my initial patch was just a first attempt to tackle the problem. Show quoted text
> Unfortunately I cannot promise when anyone on the ActivePerl team > will have time to do it. I'll try to bring it back on our agenda, > but it always seems to be prioritized down so that we don't actually > get around to do something about it. :( > > Note that as a workaround you can always run `ap-update-html` from the > perl/bin directory. It will re-generate HTML docs for all *.pm and > *.pod files in the Perl directories that are either non-existent or > out-of-date (according to their respective mtimes). It will also > update the TOC.
Thanks for your workaround, I will use that for the time being. Speaking as a user, I have been using ActiveState Perl and ExtUtils::MakeMaker successfully for years, I was particularly happy with the way that HTML was generated automatically from POD and how it integrated seamlessly with the "index.html" file. Now I am in the process of migrating to Module::Build, and it would be nice if the same HTML would be generated and automatically integrated with "index.html", without workaround (element of least surprise). -- Klaus
RT-Send-CC: bug-ExtUtils-MakeMaker [...] rt.cpan.org, dagolden [...] cpan.org, klaus03 [...] gmail.com, jand [...] activestate.com
Le Jeu 14 Jan 2010 20:30:42, jand@ActiveState.com a écrit : Show quoted text
> Klaus Eichner wrote:
> > I don't know, but it seems that someone decided that the number of > > ".packlist" files is simply too big to be scanned each time just to > > find out whether or not to synchronise (there could be hundreds or > > even thousands of ".packlist" files) and they may have simply (mis- > > )used the date-stamp of "perllocal.pod" as an approximation of the > > date-stamp of the most recent ".packlist" file.
> > Ah, so it does use perllocal.pod. Seems like you know the code better > than I do. :) > > So I guess I wouldn't mind seeing perllocal.pod at least
being "touched" Show quoted text
> by a M::B install, even if it doesn't write to it. Again, updating > perllocal.pod should be done by EU::Install and not by EU::MM and > M::B though.
The attached "patch-perllocal.txt" touches 'perllocal.pod' (without writing to it). The principle is that: 'perllocal.pod' is touched whenever a ".packlist" file is updated. 'perllocal.pod' is not touched if no ".packlist" file is updated. The patch is mainly in EU::Install, but I had to include a one-line addition in M::B::Base to pass the information $self->{config}->get ('installprivlib') into EU::Install as a parameter (I could not find that information anywhere in EU::Install -- or I didn't look hard enough ?). -- Klaus
Subject: patch-perllocal.txt
--- lib/ExtUtils/Install.pm.bak 2009-08-04 13:31:32.000000000 +0200 +++ lib/ExtUtils/Install.pm 2010-01-15 16:48:25.467000000 +0100 @@ -850,6 +850,44 @@ return $result; } +sub touch_perllocal { + my ($corelib, $verbose, $dry_run, $uninstall_shadows) = @_; + + # Touch "lib/perllocal.pod" to get a new timestamp for that file. + # The new timestamp is used by ActiveState's ppm-utility to decide + # whether or not to synchronize with the SQLite database + # at "etc/ppm-perl-area.db". + # See also 'ActivePerl/PPM/InstallArea.pm', subroutine _init_db(), + # ==> expression ((stat $perllocal)[9] || 0)) + + unless (defined $corelib) { + print "Can't touch perllocal.pod, \$corelib is undefined\n" if $verbose; + return; + } + + my $perllocal = File::Spec->catfile($corelib, 'perllocal.pod'); + + my $t = time; + my $stamp = localtime($t); + + if ($dry_run) { + print "DRY-RUN: file $perllocal would have been touched, ", + "timestamp would have been $stamp\n" if $verbose; + return; + } + + open(PERLLOCAL, ">>$perllocal") or do { + print "Can't open >> file $perllocal because $!\n" if $verbose; + return; + }; + + close(PERLLOCAL); + + utime($t, $t, $perllocal); + + print "Touching file $perllocal, timestamp $stamp\n" if $verbose; +} + =begin _private =item _do_cleanup --- lib/Module/Build/Base.pm.bak 2009-08-10 01:47:06.000000000 +0200 +++ lib/Module/Build/Base.pm 2010-01-15 17:16:25.358000000 +0100 @@ -2983,6 +2983,7 @@ require ExtUtils::Install; $self->depends_on('build'); ExtUtils::Install::install($self->install_map, !$self->quiet, 0, $self->{args}{uninst}||0); + ExtUtils::Install::touch_perllocal($self->{config}->get('installprivlib'), !$self->quiet, 0, $self->{args}{uninst}||0); } sub ACTION_fakeinstall {
Subject: RE: [rt.cpan.org #53478] Diffs with ActiveState HTML generation and PPM compatibility
Date: Fri, 15 Jan 2010 13:20:45 -0800
To: <bug-Module-Build [...] rt.cpan.org>
From: "Jan Dubois" <jand [...] activestate.com>
On Fri, 15 Jan 2010, Klaus Eichner via RT wrote: Show quoted text
> Le Jeu 14 Jan 2010 20:30:42, jand@ActiveState.com a écrit :
> > So I guess I wouldn't mind seeing perllocal.pod at least being > > "touched" by a M::B install, even if it doesn't write to it. Again, > > updating perllocal.pod should be done by EU::Install and not by > > EU::MM and M::B though.
> > The attached "patch-perllocal.txt" touches 'perllocal.pod' (without > writing to it).
Hey, you are really quick with coming up with patches. :) Show quoted text
> The principle is that: > 'perllocal.pod' is touched whenever a ".packlist" file is updated. > 'perllocal.pod' is not touched if no ".packlist" file is updated. > > The patch is mainly in EU::Install, but I had to include a one-line > addition in M::B::Base to pass the information $self->{config}->get > ('installprivlib') into EU::Install as a parameter (I could not find > that information anywhere in EU::Install -- or I didn't look hard > enough ?).
After thinking about this some more I don't think this is the best approach yet. Assuming we get a hook into EU::Install that ActivePerl would use to update the HTML docs, then it could use the same hook to update a file that is specific to the install area, e.g. perl/etc/ppm- dirty for perl/lib and perl/site/etc/ppm-dirty for perl/site/lib. It could even record the exact path to the .packlist file, making it much more efficient for PPM to detect and process any new packages that have been installed outside its control. This way the mechanism would no longer depend on perllocal.pod at all, and since the control files are specific to each install area we wouldn't need the change to M::B to pass the installprivlib either. Please note that no changes to EU::Install can be made until Perl 5.12 is released (there is a code freeze right now), so we have some time to hash this out... Cheers, -Jan
RT-Send-CC: bug-ExtUtils-MakeMaker [...] rt.cpan.org, dagolden [...] cpan.org, klaus03 [...] gmail.com, jand [...] activestate.com
Le Ven 15 Jan 2010 16:21:00, jand@ActiveState.com a écrit : Show quoted text
> > The attached "patch-perllocal.txt" touches 'perllocal.pod' (without > > writing to it).
> > Hey, you are really quick with coming up with patches. :)
I like coming up with patches :) Show quoted text
> After thinking about this some more I don't think this is the best > approach yet. Assuming we get a hook into EU::Install that ActivePerl > would use to update the HTML docs, then it could use the same hook to > update a file that is specific to the install area, e.g. perl/etc/ppm- > dirty for perl/lib and perl/site/etc/ppm-dirty for perl/site/lib. It > could even record the exact path to the .packlist file, making it much > more efficient for PPM to detect and process any new packages that
have Show quoted text
> been installed outside its control. > > This way the mechanism would no longer depend on perllocal.pod at all, > and since the control files are specific to each install area we > wouldn't need the change to M::B to pass the installprivlib either.
Sounds good to me. Show quoted text
> Please note that no changes to EU::Install can be made until Perl 5.12 > is released (there is a code freeze right now), so we have some time
to Show quoted text
> hash this out...
Perfect, I will work on a patch during the next week. Cheers, -Klaus
RT-Send-CC: klaus03 [...] gmail.com, jand [...] activestate.com
Le Dim 17 Jan 2010 07:03:50, KEICHNER a écrit : Show quoted text
> Le Ven 15 Jan 2010 16:21:00, jand@ActiveState.com a écrit :
> > Please note that no changes to EU::Install can be made until Perl 5.12 > > is released (there is a code freeze right now), so we have some time > > to hash this out...
> > Perfect, I will work on a patch during the next week.
Unfortunately I have been busy this week, but I will have more time to spend on this problem in the weeks ahead. -Klaus
Subject: Re: [rt.cpan.org #53478] Diffs with ActiveState HTML generation and PPM compatibility
Date: Fri, 22 Jan 2010 08:23:13 -0500
To: bug-Module-Build [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
On Fri, Jan 22, 2010 at 7:36 AM, Klaus Eichner via RT <bug-Module-Build@rt.cpan.org> wrote: Show quoted text
>       Queue: Module-Build >  Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=53478 > > > Le Dim 17 Jan 2010 07:03:50, KEICHNER a écrit :
>> Le Ven 15 Jan 2010 16:21:00, jand@ActiveState.com a écrit :
>> > Please note that no changes to EU::Install can be made until Perl 5.12 >> > is released (there is a code freeze right now), so we have some time >> > to hash this out...
>> >> Perfect, I will work on a patch during the next week.
> > Unfortunately I have been busy this week, but I will have more time to > spend on this problem in the weeks ahead.
No problem. I have plenty of other things I'm working on right now, so my ability to integrate big feature patches is a bit limited. (http://www.dagolden.com/index.php/642/etoomanyprojects/)
RT-Send-CC: dagolden [...] cpan.org, klaus03 [...] gmail.com, jand [...] activestate.com
Le Ven 22 Jan 2010 08:23:56, DAGOLDEN a écrit : Show quoted text
> On Fri, Jan 22, 2010 at 7:36 AM, Klaus Eichner via RT
> > Unfortunately I have been busy this week, but I will have more > > time to spend on this problem in the weeks ahead.
> > No problem. I have plenty of other things I'm working on right now, > so my ability to integrate big feature patches is a bit limited. > (http://www.dagolden.com/index.php/642/etoomanyprojects/)
Here is a proposal for a patch with (what I believe to be) minimal changes to Module::Build::Base, ExtUtils::Install and a new module ExtUtils::HtmlFix. - Updating perllocal.pod is done by ExtUtils::Install. - Manipulating HTML is done in the new module ExtUtils::FixHtml (please let me know if that should better be incorporated into the existing Pod::Html) - The patch MB-Base-opt1 proposes changes to Module::Build::Base for Activestate HTML such that the original non-Activestate HTML generation is not changed. - The patch MB-Base-opt2 proposes alternative changes to Module::Build::Base such that the non-Activestate HTML is very similar to the Activestate HTML. To Jan: Sorry, I didn't have time yet to work on updating a file specific to the install area (perl/etc/ppm-dirty, perl/site/etc/ppm-dirty), I will start working on it next week.
Subject: patch-MB-Base-opt2.txt
--- lib/Module/Build/Base.pm.bak 2009-08-10 01:47:06.000000000 +0200 +++ lib/Module/Build/Base.pm 2010-01-29 17:20:38.549000000 +0100 @@ -861,10 +861,11 @@ }, ); -{ - my $Is_ActivePerl = eval {require ActivePerl::DocTools}; - __PACKAGE__->add_property(html_css => $Is_ActivePerl ? 'Active.css' : ''); -} +my $Is_Active_Perl = eval { require ActivePerl::DocTools }; +my $Is_Active_PPM = eval { require ActivePerl::PPM::InstallArea }; +my $Is_Active_Scineplex = eval { require ActiveState::Scineplex }; + +__PACKAGE__->add_property(html_css => $Is_Active_Perl ? 'Active.css' : ''); { my @prereq_action_types = qw(requires build_requires conflicts recommends); @@ -2829,6 +2830,7 @@ require Module::Build::PodParser; require Pod::Html; + require ExtUtils::HtmlFix; $self->add_to_cleanup('pod2htm*'); @@ -2844,11 +2846,18 @@ my @rootdirs = ($type eq 'bin') ? qw(bin) : $self->installdirs eq 'core' ? qw(lib) : qw(site lib); + my $pcore = $self->original_prefix->{core}; + my $pdir = $self->base_dir; $pdir =~ s/:/|/g; + + my $podroot = join('/', File::Spec->splitdir($pcore)); my $podpath = join ':', - map $_->[1], - grep -e $_->[0], - map [File::Spec->catdir($self->blib, $_), $_], - qw( script lib ); + map $_->[1], + grep -e $_->[0], + map [File::Spec->rel2abs(File::Spec->catdir(split '/', do{ my $t = $_; $t =~ s/\|/:/g; $t; }), $pcore), $_], + $pdir.'/blib', + 'lib', + 'site/lib', + 'bin'; foreach my $pod ( keys %$pods ) { @@ -2869,9 +2878,7 @@ } my $path2root = join( '/', ('..') x (@rootdirs+@dirs) ); - my $htmlroot = join( '/', - ($path2root, - $self->installdirs eq 'core' ? () : qw(site) ) ); + my $htmlroot = $path2root; my $fh = IO::File->new($infile) or die "Can't read $infile: $!"; my $abstract = Module::Build::PodParser->new(fh => $fh)->get_abstract(); @@ -2880,23 +2887,35 @@ $title .= " - $abstract" if $abstract; my @opts = ( - '--flush', - "--title=$title", "--podpath=$podpath", "--infile=$infile", "--outfile=$outfile", - '--podroot=' . $self->blib, + "--podroot=$podroot", "--htmlroot=$htmlroot", + "--quiet", + "--index", + "--libpods=perlfunc:perlguts:perlvar:perlrun:perlopt", ); + push( @opts, "--title=$title") unless $Is_Active_Perl; + if ( eval{Pod::Html->VERSION(1.03)} ) { - push( @opts, ('--header', '--backlink=Back to Top') ); + push( @opts, ('--header', '--backlink=Back to Top') ) unless $Is_Active_Perl; push( @opts, "--css=$path2root/" . $self->html_css) if $self->html_css; } $self->log_info("HTMLifying $infile -> $outfile\n"); $self->log_verbose("pod2html @opts\n"); - eval { Pod::Html::pod2html(@opts); 1 } + eval { Pod::Html::pod2html(@opts); + ExtUtils::HtmlFix::manipulate_html($outfile, { + index => $Is_Active_Perl, + script => $Is_Active_Perl, + title => $title, + is_sp => $Is_Active_Scineplex, + root => $htmlroot, + dp => scalar(@rootdirs + @dirs), + }); + 1; } or $self->log_warn("pod2html @opts failed: $@"); } @@ -2983,6 +3002,19 @@ require ExtUtils::Install; $self->depends_on('build'); ExtUtils::Install::install($self->install_map, !$self->quiet, 0, $self->{args}{uninst}||0); + + if ($Is_Active_PPM) { + $self->log_info("Touching 'perllocal.pod' for Activestate PPM\n"); + ExtUtils::Install::touch_perllocal(); + } + + if ($Is_Active_Perl) { + $self->log_info("Update Html TOC for Activestate\n"); + eval { + ActivePerl::DocTools::WriteTOC(); + } + or $self->log_warn("ActivePerl::DocTools::WriteTOC() failed: $@"); + } } sub ACTION_fakeinstall {
Subject: patch-EU-HtmlFix.txt
--- lib/ExtUtils/HtmlFix.pm.bak 2010-01-29 17:15:40.308000000 +0100 +++ lib/ExtUtils/HtmlFix.pm 2010-01-29 17:19:06.162000000 +0100 @@ -0,0 +1,78 @@ +package ExtUtils::HtmlFix; + +sub manipulate_html { + my $outfile = $_[0]; + my $index = $_[1]{index}; + my $title = $_[1]{title}; + my $script = $_[1]{script}; + my $Is_Active_Scineplex = $_[1]{is_sp}; + my $html_root = $_[1]{root}; + my $depth = $_[1]{dp}; + + # the code for this subroutine has been copied from "ActivePerl/DocTools/Pod.pm" + + open HTMLFILE, "<$outfile" or die "Couldn't open $outfile: $!"; + open TMPFILE, ">$outfile.tmp" or die "Couldn't open $outfile.tmp: $!"; + + my $first_header = 1; + + while (my $content = <HTMLFILE>) { + # Despite what Pod::Html says, this is not XHTML. + # IE6 doesn't display things correctly with the wrong DOCTYPE. + $content =~ s#^<!DOCTYPE .*?>#<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">#i; + $content =~ s#<html xmlns="http://www.w3.org/1999/xhtml">#<html>#i; + + if ($content =~ s/^(\s*)<HEAD>\s*//i) { + print TMPFILE <<EOT; +$1<head> +EOT + if ($script) { + print TMPFILE <<EOT; +$1<!-- saved from url=(0017)http://localhost/ --> +$1<script language="JavaScript" src="$html_root/displayToc.js"></script> +$1<script language="JavaScript" src="$html_root/tocParas.js"></script> +$1<script language="JavaScript" src="$html_root/tocTab.js"></script> +EOT + } + if ($Is_Active_Scineplex) { + print TMPFILE qq($1<link rel="stylesheet" type="text/css" href="$html_root/scineplex.css">\n); + } + } + + if ($index and $content =~ /^<p><a name="__index__"><\/a><\/p>$/i) { + $content = <<EOT; +<h1><a>$title</a></h1> +$content +EOT + if ($script) { + $content = <<EOT; +<script>writelinks('__top__',$depth);</script> +$content +EOT + } + } + + # Don't duplicate the title if we don't have an index. + # Instead put the TOC buttons on the first header in the document. + # This is being used for release notes and changelogs. + if ($first_header and !$index and $content =~ /^<H\d>/i) { + $first_header = 0; + if ($script) { + $content = <<EOT; +<script>writelinks('__top__',$depth);</script> +$content +EOT + } + } + + print TMPFILE $content; + } + + close TMPFILE or die "Couldn't write all of $outfile.tmp: $!"; + close HTMLFILE; + + unlink $outfile; + rename "$outfile.tmp", $outfile or die "Couldn't rename $outfile.tmp back to $outfile: $!"; +} + +1;
Subject: patch-EU-Install.txt
--- lib/ExtUtils/Install.pm.bak 2009-08-04 13:31:32.000000000 +0200 +++ lib/ExtUtils/Install.pm 2010-01-29 17:21:37.942000000 +0100 @@ -1241,6 +1241,24 @@ return $retval; } +sub touch_perllocal { + # Touch "lib/perllocal.pod" to get a new timestamp for that file. + # The new timestamp is used by ActiveState's ppm-utility to decide + # whether or not to synchronize with the two SQLite databases: + # 1. "etc/ppm-perl-area.db" + # 2. "site/etc/ppm-site-area.db" + # See also 'ActivePerl/PPM/InstallArea.pm', subroutine _init_db(), + # ==> expression ((stat $perllocal)[9] || 0)) + + my $perllocal = File::Spec->catfile($Config{'prefix'}, 'lib', 'perllocal.pod'); + + my $t = time; + + open TFILE, ">>$perllocal"; + close TFILE; + + utime($t, $t, $perllocal); +} package ExtUtils::Install::Warn;
Subject: patch-MB-Base-opt1.txt
--- lib/Module/Build/Base.pm.bak 2009-08-10 01:47:06.000000000 +0200 +++ lib/Module/Build/Base.pm 2010-01-29 17:28:53.641000000 +0100 @@ -861,10 +861,11 @@ }, ); -{ - my $Is_ActivePerl = eval {require ActivePerl::DocTools}; - __PACKAGE__->add_property(html_css => $Is_ActivePerl ? 'Active.css' : ''); -} +my $Is_Active_Perl = eval { require ActivePerl::DocTools }; +my $Is_Active_PPM = eval { require ActivePerl::PPM::InstallArea }; +my $Is_Active_Scineplex = eval { require ActiveState::Scineplex }; + +__PACKAGE__->add_property(html_css => $Is_Active_Perl ? 'Active.css' : ''); { my @prereq_action_types = qw(requires build_requires conflicts recommends); @@ -2829,6 +2830,7 @@ require Module::Build::PodParser; require Pod::Html; + require ExtUtils::HtmlFix; $self->add_to_cleanup('pod2htm*'); @@ -2844,11 +2846,31 @@ my @rootdirs = ($type eq 'bin') ? qw(bin) : $self->installdirs eq 'core' ? qw(lib) : qw(site lib); - my $podpath = join ':', - map $_->[1], - grep -e $_->[0], - map [File::Spec->catdir($self->blib, $_), $_], - qw( script lib ); + my $podroot; + my $podpath; + + if ($Is_Active_Perl) { + my $pcore = $self->original_prefix->{core}; + my $pdir = $self->base_dir; $pdir =~ s/:/|/g; + + $podroot = join('/', File::Spec->splitdir($pcore)); + $podpath = join ':', + map $_->[1], + grep -e $_->[0], + map [File::Spec->rel2abs(File::Spec->catdir(split '/', do{ my $t = $_; $t =~ s/\|/:/g; $t; }), $pcore), $_], + $pdir.'/blib', + 'lib', + 'site/lib', + 'bin'; + } + else { + $podroot = $self->blib; + $podpath = join ':', + map $_->[1], + grep -e $_->[0], + map [File::Spec->catdir($self->blib, $_), $_], + qw( script lib ); + } foreach my $pod ( keys %$pods ) { @@ -2870,8 +2892,7 @@ my $path2root = join( '/', ('..') x (@rootdirs+@dirs) ); my $htmlroot = join( '/', - ($path2root, - $self->installdirs eq 'core' ? () : qw(site) ) ); + ($path2root, ($self->installdirs eq 'core' or $Is_Active_Perl) ? () : qw(site) ) ); my $fh = IO::File->new($infile) or die "Can't read $infile: $!"; my $abstract = Module::Build::PodParser->new(fh => $fh)->get_abstract(); @@ -2880,23 +2901,46 @@ $title .= " - $abstract" if $abstract; my @opts = ( - '--flush', - "--title=$title", "--podpath=$podpath", "--infile=$infile", "--outfile=$outfile", - '--podroot=' . $self->blib, + "--podroot=$podroot", "--htmlroot=$htmlroot", ); + if ($Is_Active_Perl) { + push( @opts, + "--quiet", + "--index", + "--libpods=perlfunc:perlguts:perlvar:perlrun:perlopt", + ); + } + else { + push( @opts, + "--flush", + "--title=$title", + ); + } + if ( eval{Pod::Html->VERSION(1.03)} ) { - push( @opts, ('--header', '--backlink=Back to Top') ); + push( @opts, ('--header', '--backlink=Back to Top') ) unless $Is_Active_Perl; push( @opts, "--css=$path2root/" . $self->html_css) if $self->html_css; } $self->log_info("HTMLifying $infile -> $outfile\n"); $self->log_verbose("pod2html @opts\n"); - eval { Pod::Html::pod2html(@opts); 1 } + eval { Pod::Html::pod2html(@opts); + if ($Is_Active_Perl) { + ExtUtils::HtmlFix::manipulate_html($outfile, { + index => 1, + script => 1, + title => $title, + is_sp => $Is_Active_Scineplex, + root => $htmlroot, + dp => scalar(@rootdirs + @dirs), + }); + } + 1; } or $self->log_warn("pod2html @opts failed: $@"); } @@ -2983,6 +3027,19 @@ require ExtUtils::Install; $self->depends_on('build'); ExtUtils::Install::install($self->install_map, !$self->quiet, 0, $self->{args}{uninst}||0); + + if ($Is_Active_PPM) { + $self->log_info("Touching 'perllocal.pod' for Activestate PPM\n"); + ExtUtils::Install::touch_perllocal(); + } + + if ($Is_Active_Perl) { + $self->log_info("Update Html TOC for Activestate\n"); + eval { + ActivePerl::DocTools::WriteTOC(); + } + or $self->log_warn("ActivePerl::DocTools::WriteTOC() failed: $@"); + } } sub ACTION_fakeinstall {
RT-Send-CC: dagolden [...] cpan.org, klaus03 [...] gmail.com, jand [...] activestate.com
Le Ven 29 Jan 2010 12:08:11, KEICHNER a écrit : Show quoted text
> - Manipulating HTML is done in the new module > ExtUtils::FixHtml (please let me know if that should > better be incorporated into the existing > Pod::Html)
The code for subroutine ExtUtils::HtmlFix::manipulate_html() has been copied from "ActivePerl/DocTools/Pod.pm". Are there any licensing issues with that ? -- Klaus
RT-Send-CC: bug-ExtUtils-MakeMaker [...] rt.cpan.org, dagolden [...] cpan.org, schwern [...] pobox.com, klaus03 [...] gmail.com, jand [...] activestate.com, yves [...] cpan.org, kwilliams [...] cpan.org
I saw this ticket and came up with fixes for Module::Build that will address all of the HTML generation issues, including the generation of the Table of Contents on ActivePerl installations. I sent a e-mail to the 'module-build' email address with these changes and Dave Golden asked me post the changes and e-mail here. Not sure how these changes will fit in with the updates from Klaus.... The fixes are pretty simple and I’ve attached Module::Build::Base.pm with my the changes. The changes are based on build 0.3603, with a new version of 0.36031. I’ve tested quite a bit (doing a variety builds, install, ppminstall, dist, ppmdist, etc.) and everything works as it should, but I am limited to Windows for testing. I’ve tested on Perl 5.8 and 5.10 (both AS and standard). With these updates, there is no need to make changes to EU:Install to get the html documentation working properly on any type of installation. Here is a summary of the changes…. In the section setting default properties… (line 929) Deleted the property “html_css”, it is no longer needed or used. sub _is_ActivePerl (line 3034) New method that returns true if running on an ActivePerl installation. Is set using the same eval (require ActivePerl::DocTools) that was used to set the property “html_css”. This is not a property because its value needs to be determined when the installation is run, not the value on the system that built the package. sub ACTION_manpages (line 3039) I removed the check to see if there are any files to process, because this is performed in both the ‘manify’ subs. No point in doing the check twice. sub ACTION_html (line 3133) I also optimized this sub as well. ‘htmlify_pods’ checks if there are no files to process, so there really isn’t any point in doing the check here too. Sub htmlify_pods (line 3172) I saw the comment that says “Links to other modules are not being generated” and saw the problem. The original code uses “$self->blib” as the “podroot” and “podpath” only points to directories in “blib”. “podroot” must be the absolute path to the directory where the installed pod files are stored, and “podpath” can be relative directories off of podroot, plus an absolute path to the “blib” directory. With this code, all links are generated properly. If $self->_is_ActivePerl is true, we use ActivePerl::DocTools::Pod::pod2html to generate the HTML documentation, otherwise we use Pod::Html:pod2html to create it. The ActivePerl version also uses Pod::Html::pod2html, but then does some post processing on the HTML files to format them in the ActivePerl style. I also added code to do some cleanup on the html files after they are generated by pod2html. The generated HTML is NOT XHMTL, so the DOCTYPE is wrong. IE6+ will not display the page if it does not pass validation based on the DOCTYPE. Local pages also need this statement in the <HEAD> “<!-- saved from url=(0017)http://localhost/ -->” for IE6+ to load local html pages (file://) if certain security settings on the user’s PC are strict. Lastly anchor references to html pages within the package point to the “blib” directory. These are fixed up so they point to where they will be after they are installed. sub ACTION_install (line 3357) Added logic to check if ‘$self->is_ActivePerl’ is true, and run ActivePerl::DocTools::WriteTOC(). WriteTOC() is the ActivePerl routine that updates the ActivePerl Table of Contents page and must be run AFTER the all the html files have been installed. sub ACTION_ppmdist (line 3515) You don’t need to generate HTML documentation when creating a PPM distribution, because it is generated automatically by the ppm client at install. This is noted in the fact that “libdoc” and “bindoc” are set to “undef”. I commented out the lines that generate the HTML. sub install_map (line 4830) Added some logic so that man pages are not installed unless you are running on a Unix like operating system. Feel free to use these changes and to contact me if you have any questions or comments. I’m glad to help in any way I can. Scott Renner
Subject: Base.36031.pm

Message body is not shown because it is too large.

RT-Send-CC: dagolden [...] cpan.org, klaus03 [...] gmail.com, jand [...] activestate.com
Le Lun 01 Fév 2010 19:23:39, SARENNER a écrit : Show quoted text
> I saw this ticket and came up with fixes for Module::Build that will > address all of the HTML generation issues, including the generation of > the Table of Contents on ActivePerl installations. > > I sent a e-mail to the 'module-build' email address with these changes > and Dave Golden asked me post the changes and e-mail here. Not sure > how these changes will fit in with the updates from Klaus....
Hi Scott, Thanks for your suggested changes, I will review them in detail during the next days. Show quoted text
> I’ve tested quite a bit (doing a variety builds, install, ppminstall, > dist, ppmdist, etc.) and everything works as it should, but I am > limited to Windows for testing. I’ve tested on Perl 5.8 and 5.10 > (both AS and standard).
Also thanks for your testing. Show quoted text
> Feel free to use these changes and to contact me if you have any > questions or comments. I’m glad to help in any way I can. > > Scott Renner
I will contact you when I have reviewed your changes in detail. -- Klaus
RT-Send-CC: dagolden [...] cpan.org, klaus03 [...] gmail.com, jand [...] activestate.com
Le Mar 02 Fév 2010 09:41:41, KEICHNER a écrit : Show quoted text
> Thanks for your suggested changes, I will review them in detail during > the next days.
Hi Scott, Many of your changes are almost identical to my idea of how this problem should be resolved, so I will certainly take advantage of most of your code. I am still working on a detailed and complete patch, I guess that next week I can come up with a solution. -- Klaus
RT-Send-CC: dagolden [...] cpan.org, klaus03 [...] gmail.com, jand [...] activestate.com
On Fri Feb 05 11:57:21 2010, KEICHNER wrote: Show quoted text
> Le Mar 02 Fév 2010 09:41:41, KEICHNER a écrit :
> > Thanks for your suggested changes, I will review them in detail during > > the next days.
> > Hi Scott, > > Many of your changes are almost identical to my idea of how this problem > should be resolved, so I will certainly take advantage of most of your
code. Show quoted text
> > I am still working on a detailed and complete patch, I guess that next > week I can come up with a solution.
Hi Scott, I have reviewed your changes and I agree with all of them (and I learned a lot by doing so, thanks again). On top of your changes (ver 36031), I have added changes to handle 'lib/perllocal.pod' (ver 36032) - I have created a new module ActivePerl::PPM::InstallHist, subroutine add_info() to handle the file date of 'lib/perllocal.pod' (and I have added some comments where I suggest a replacement procedure) - I have cloned your subroutine _is_ActivePerl() to create a new subroutine _is_ActivePPM() (to check for the new module ActivePerl::PPM::InstallHist) - In subroutine ACTION_install, I allowed myself to wrap your call ActivePerl::DocTools::WriteTOC() into an eval{...} and I have added my own call eval{ ActivePerl::PPM::InstallHist::add_info() }. I have tested with and without ActiveState under Ubuntu Linux, perl 5.10.1 Please find the two files 'Base.36032.pm' and 'InstallHist.00100.pm' attached (I hope the line endings are ok, as I now work under Linux) -- Klaus
Subject: Base.36032.pm

Message body is not shown because it is too large.

Subject: InstallHist.00100.pm
package ActivePerl::PPM::InstallHist; $VERSION = '0.001'; use strict; use warnings; # The code for subroutine add_info() is designed to be consistent with # 'ActivePerl/PPM/InstallArea.pm', subroutine _init_db(). use Config qw(%Config); use File::Spec; my $prefix = $Config{prefix}; sub add_info { my $P_target = $_[0]{target}; my $P_instdir = $_[0]{instdir}; my $P_buildtool = $_[0]{buildtool}; my $dt_stamp = time; my $dt_yyyymmdd = do{ my ($sec, $min, $hour, $day, $month, $year) = localtime($dt_stamp); sprintf '%04d-%02d-%02d %02d:%02d:%02d', $year + 1900, $month + 1, $day, $hour, $min, $sec; }; # possible values for $P_instdir are: 'core', 'site' or 'vendor'. # (we actually don't know what to do with 'vendor', so let's assume 'site' when $P_instdir is 'vendor') my $name = $P_instdir eq 'core' ? 'perl' : 'site'; my @tdir = $P_instdir eq 'core' ? () : ('site'); # in the following line, 'perllocal.pod' this is *always* 'lib/perllocal.pod', never 'site/lib/perllocal.pod' my $F_perllocal = File::Spec->catfile($prefix, 'lib', "perllocal.pod"); my $F_PPM_db = File::Spec->catfile($prefix, @tdir, 'etc', "ppm-$name-area.db"); my $F_Text = File::Spec->catfile($prefix, @tdir, 'etc', "ppm-$name-dirty.txt"); my $F_lib_dir = File::Spec->catdir($prefix, @tdir, 'lib'); # We touch 'lib/perllocal.pod'. There is an existing logic in subroutine _init_db() # of 'ActivePerl/PPM/InstallArea.pm' that says that if 'lib/perllocal.pod' has a 'date-last-touched' # greater than that of the PPM SQLite databases ('etc/ppm-perl-area.db' and/or # 'site/etc/ppm-site-area.db') then the PPM SQLite databases are rebuilt from scratch. open PERLLOCAL, ">>$F_perllocal"; close PERLLOCAL; utime($dt_stamp, $dt_stamp, $F_perllocal); # What follows here is a proposal to replace the procedure with 'lib/perllocal.pod' by something more # flexible. The idea is to write our install details to one of two new text files ('etc/ppm-perl-dirty.txt' or # 'site/etc/ppm-site-dirty.txt'). Currently, those text files are not exploited, but we hope, in the future, # to be able to replace the existing logic (in subroutine _init_db() of 'ActivePerl/PPM/InstallArea.pm') # by a new logic that relies on the information in those two text files. This should allow us to refresh # individual modules within the PPM SQLite databases, rather than rebuilding the whole set of installed # modules each time we update a single module. # The question arises: why don't we just add a single record (see "$P_target") to the PPM SQLite databases # ('etc/ppm-perl-area.db' and/or 'site/etc/ppm-site-area.db') directly here in this subroutine ? - Well, the # answer is: We could, but it turns out that this is not a good idea, because if we did, we would # inevitably set a new date/time stamp for the PPM SQLite database, and as a consequence, we would miss # all module installs that have been made by ExtUtils::MakeMaker. # An open question (about housekeeping): when do records in the text files get deleted ? - or do they grow # indefinitely ? - Should the text file be cleared each time a PPM SQLite database is re-built from scratch ? # Anyway, the following 3 lines need to be uncommented to write to the text file: # open TXTFILE, ">>$F_Text"; # printf TXTFILE "%s, %-40s, %-25s, %s\n", $dt_yyyymmdd, $P_target, $P_buildtool, $F_lib_dir; # close TXTFILE; } 1;
RT-Send-CC: dagolden [...] cpan.org, klaus03 [...] gmail.com, jand [...] activestate.com
Hi David, Jan, With reference to "ActiveState HTML generation and PPM compatibility", Now that Perl 5.12 is out, can we discuss the changes to Module::Build::Base (and a new module ActivePerl::PPM::InstallHist) ? as per the attachment -- two files 'Base.36032.pm' and 'InstallHist.00100.pm' -- in my message from 10 Feb 2010. -- Klaus Le Mer 10 Fév 2010 14:08:19, KEICHNER a écrit : Show quoted text
> On Fri Feb 05 11:57:21 2010, KEICHNER wrote:
> > Le Mar 02 Fév 2010 09:41:41, KEICHNER a écrit :
> > > Thanks for your suggested changes, I will review them in detail during > > > the next days.
> > > > Hi Scott, > > > > Many of your changes are almost identical to my idea of how this problem > > should be resolved, so I will certainly take advantage of most of your
> code.
> > > > I am still working on a detailed and complete patch, I guess that next > > week I can come up with a solution.
> > Hi Scott, > > I have reviewed your changes and I agree with all of them (and I learned > a lot by doing so, thanks again). > > On top of your changes (ver 36031), I have added changes to handle > 'lib/perllocal.pod' (ver 36032) > > - I have created a new module ActivePerl::PPM::InstallHist, subroutine > add_info() to handle the file date of 'lib/perllocal.pod' (and I have > added some comments where I suggest a replacement procedure) > > - I have cloned your subroutine _is_ActivePerl() to create a new > subroutine _is_ActivePPM() (to check for the new module > ActivePerl::PPM::InstallHist) > > - In subroutine ACTION_install, I allowed myself to wrap your call > ActivePerl::DocTools::WriteTOC() into an eval{...} and I have added my > own call eval{ ActivePerl::PPM::InstallHist::add_info() }. > > I have tested with and without ActiveState under Ubuntu Linux, > perl 5.10.1 > > Please find the two files 'Base.36032.pm' and 'InstallHist.00100.pm' > attached (I hope the line endings are ok, as I now work under Linux) > > -- Klaus
CC: klaus03 [...] gmail.com, jand [...] activestate.com, Module-Build <module-build [...] perl.org>
Subject: Re: [rt.cpan.org #53478] Diffs with ActiveState HTML generation and PPM compatibility
Date: Wed, 14 Apr 2010 13:21:08 -0400
To: bug-Module-Build [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
On Wed, Apr 14, 2010 at 2:25 AM, Klaus Eichner via RT <bug-Module-Build@rt.cpan.org> wrote: Show quoted text
> Now that Perl 5.12 is out, > can we discuss the changes to Module::Build::Base (and a new module > ActivePerl::PPM::InstallHist) ? as per the attachment -- two files > 'Base.36032.pm' and 'InstallHist.00100.pm' -- in my message from 10 Feb > 2010.
We can try. Since your patch, Module::Build has migrated to git and is being hosted at github. http://github.com/dagolden/module-build/ I have created a branch 'rt/53478' with your patch: http://github.com/dagolden/module-build/tree/rt/53478 It fails t/ppm.t because that test expects HTML files and the patch stops them from being produced. (Intentionally). I'm not sure if that is the right thing, since it may impact non-ActiveState users of PPM. Now that we have git for easy branching, I encourage more refinements for that branch including getting all tests to a passing state. If no one on the M::B mailing list objects to PPM no longer having HTML generated for them, or has an alternate solution that gets consensus, I'd be happy to merge the branch into the main line. Regards, David
RT-Send-CC: dagolden [...] cpan.org, klaus03 [...] gmail.com, jand [...] activestate.com
Le Mer 14 Avr 2010 13:21:46, DAGOLDEN a écrit : Show quoted text
> On Wed, Apr 14, 2010 at 2:25 AM, Klaus Eichner via RT > <bug-Module-Build@rt.cpan.org> wrote:
> > Now that Perl 5.12 is out, > > can we discuss the changes to Module::Build::Base (and a new module > > ActivePerl::PPM::InstallHist) ? as per the attachment -- two files > > 'Base.36032.pm' and 'InstallHist.00100.pm' -- in my message from 10 Feb > > 2010.
> > We can try. Since your patch, Module::Build has migrated to git and > is being hosted at github. > > http://github.com/dagolden/module-build/ > > I have created a branch 'rt/53478' with your patch: > > http://github.com/dagolden/module-build/tree/rt/53478
Thanks for that. I guess I will now need to learn now how to create my own github :) Show quoted text
> It fails t/ppm.t because that test expects HTML files and the patch > stops them from being produced. (Intentionally). I'm not sure if > that is the right thing, since it may impact non-ActiveState users of > PPM.
The stop to writing of HTML for PPM was an addition by Scott Renner which is not essential for the original problem, that is to say: personally I don't mind either way if HTML for PPM is generated or not. Show quoted text
> Now that we have git for easy branching, I encourage more refinements > for that branch including getting all tests to a passing state. > > If no one on the M::B mailing list objects to PPM no longer having > HTML generated for them, or has an alternate solution that gets > consensus, I'd be happy to merge the branch into the main line.
To Jan: I would like to bring to the attention that a new module ("ActivePerl::PPM::InstallHist") is created by this patch. Is that OK with you ? Cheers, Klaus
RT-Send-CC: dagolden [...] cpan.org, klaus03 [...] gmail.com, jand [...] activestate.com
Le Mer 14 Avr 2010 15:41:12, KEICHNER a écrit : Show quoted text
> Le Mer 14 Avr 2010 13:21:46, DAGOLDEN a écrit :
> > Now that we have git for easy branching, I encourage more refinements > > for that branch including getting all tests to a passing state. > > > > If no one on the M::B mailing list objects to PPM no longer having > > HTML generated for them, or has an alternate solution that gets > > consensus, I'd be happy to merge the branch into the main line.
I have refined Module/Build/Base.pm, you can pull from my branch at http://github.com/klaus03/module-build/tree/my53478 ( You can see the details of the changes in http://github.com/klaus03/module-build/commit/192f42229955b99d19782c5c7fabe018ec891dc2 ) In that refinement, I have replaced the use of ActivePerl::PPM::InstallHist by a simple touch perllocal.pod. I have also removed the stop to writing HTML for PPM. Show quoted text
> To Jan: > I would like to bring to the attention that a new module > ("ActivePerl::PPM::InstallHist") is created by this patch. Is that OK > with you ?
I would like to get some directions from ActiveState: is the introduction of ActivePerl::PPM::InstallHist a good idea (as it was in branch rt/53478), or is it better to use a simple touch perllocal.pod (as it is now in branch my53478) ? Cheers, Klaus
RT-Send-CC: dagolden [...] cpan.org, klaus03 [...] gmail.com, jand [...] activestate.com
On Wed Apr 21 06:30:45 2010, KEICHNER wrote: Show quoted text
> Le Mer 14 Avr 2010 15:41:12, KEICHNER a écrit :
> > Le Mer 14 Avr 2010 13:21:46, DAGOLDEN a écrit :
> > > Now that we have git for easy branching, I encourage more
> refinements
> > > for that branch including getting all tests to a passing state. > > > > > > If no one on the M::B mailing list objects to PPM no longer having > > > HTML generated for them, or has an alternate solution that gets > > > consensus, I'd be happy to merge the branch into the main line.
> > I have refined Module/Build/Base.pm, you can pull from my branch at > http://github.com/klaus03/module-build/tree/my53478 > > ( You can see the details of the changes in > http://github.com/klaus03/module- > build/commit/192f42229955b99d19782c5c7fabe018ec891dc2 > ) > > In that refinement, I have replaced the use of > ActivePerl::PPM::InstallHist by a simple touch perllocal.pod. > > I have also removed the stop to writing HTML for PPM.
I have merged Module::Build version 0.36.09 into my branch "my53478" You can find my branch (with the merged version 0.36.09) at http://github.com/klaus03/module-build/tree/my53478 The tests (under Linux) look OK (even t/ppm.t works ok) Any chance that my changes get pulled into the main development branch for Module::Build ? Here is the test log: [$] ~/PerlModules/Module-Build/Module-Build-0.36.09> sudo make test /usr/local/bin/perl Build --makefile_env_macros 1 test t/00-compile.t ................. ok t/PL_files.t ................... ok t/actions/installdeps.t ........ ok t/actions/manifest_skip.t ...... ok t/add_property.t ............... ok t/basic.t ...................... ok t/bundle_inc.t ................. skipped: $ENV{MB_TEST_EXPERIMENTAL} is not set t/compat.t ..................... ok t/compat/exit.t ................ ok t/debug.t ...................... ok t/destinations.t ............... ok t/ext.t ........................ ok t/extend.t ..................... ok t/files.t ...................... ok t/help.t ....................... ok t/install.t .................... ok t/install_extra_target.t ....... ok t/manifypods.t ................. ok t/metadata.t ................... ok t/metadata2.t .................. ok t/moduleinfo.t ................. ok t/mymeta.t ..................... ok t/new_from_context.t ........... ok t/notes.t ...................... ok t/par.t ........................ skipped: PAR::Dist 0.17 or up not installed to check .par's. t/parents.t .................... ok t/perl_mb_opt.t ................ ok t/pod_parser.t ................. ok t/ppm.t ........................ ok t/properties/module_name.t ..... ok t/properties/needs_compiler.t .. ok t/properties/share_dir.t ....... ok t/resume.t ..................... ok t/runthrough.t ................. ok t/sample.t ..................... ok t/script_dist.t ................ ok t/signature.t .................. skipped: $ENV{TEST_SIGNATURE} is not set t/test_file_exts.t ............. ok t/test_type.t .................. ok t/test_types.t ................. ok t/tilde.t ...................... ok t/use_tap_harness.t ............ ok t/versions.t ................... ok t/write_default_maniskip.t ..... ok t/xs.t ......................... ok All tests successful. Files=45, Tests=1168, 121 wallclock secs ( 0.27 usr 0.53 sys + 68.04 cusr 46.45 csys = 115.29 CPU) Result: PASS -- Klaus
CC: klaus03 [...] gmail.com, jand [...] activestate.com
Subject: Re: [rt.cpan.org #53478] Diffs with ActiveState HTML generation and PPM compatibility
Date: Mon, 10 May 2010 22:53:58 -0400
To: bug-Module-Build [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
On Mon, May 10, 2010 at 2:23 PM, Klaus Eichner via RT <bug-Module-Build@rt.cpan.org> wrote: Show quoted text
> I have merged Module::Build version 0.36.09 into my branch "my53478" > > You can find my branch (with the merged version 0.36.09) at > http://github.com/klaus03/module-build/tree/my53478 > > The tests (under Linux) look OK (even t/ppm.t works ok) > > Any chance that my changes get pulled into the main development branch > for Module::Build ?
I'll try to find some time in the next couple weeks to review it. Assuming it looks good, I'll merge it in and do a development release against it to test it in the wild. -- David
CC: klaus03 [...] gmail.com, jand [...] activestate.com
Subject: Re: [rt.cpan.org #53478] Diffs with ActiveState HTML generation and PPM compatibility
Date: Tue, 11 May 2010 08:39:42 -0400
To: bug-Module-Build [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
On Mon, May 10, 2010 at 10:53 PM, David Golden <dagolden@cpan.org> wrote: Show quoted text
>> Any chance that my changes get pulled into the main development branch >> for Module::Build ?
> > I'll try to find some time in the next couple weeks to review it. > Assuming it looks good, I'll merge it in and do a development release > against it to test it in the wild.
Actually, the changes looked minor so I went ahead and rebased your branch into the master branch. I'll look to do a development release 'soonish'. -- David
Now that there has been a stable Module::Build release, I'm marking this "patched" issue as "resolved".