module-build-general — General discussion about Module::Build project

Re: [Module::Build] any pod2html action?

[Randy K. <ra...@th...>]

On Thu, 15 Jan 2004, Uri Guttman wrote:

> i was looking for an action that would do pod2html on all
> the pm files and i can't seem to find one. would this be a
> good thing to have? if none exists i will probably write
> my own and post it here.

Coincidentally, this was just being discussed - here's a
diff that adds an 'html' target that runs pod2html on the
pods under blib/, and puts the results also under blib/
(which will be included in the 'ppm_dist' archive). There's
also an 'htmlinstall' target that would install the html
files locally to $Config{installhtmldir}, if that exists.
I tried to make it not assume too much about the
ActiveState html directory structure, but some things
may need tweaking to function outside of an ActiveState
distribution.

Note that a couple of new requirements - Pod::Find and
Pod::Html - are added.

In case you were wondering, the gymnastics concerning file
paths within the html action (using File::Spec->Unix and the
like) are mainly due to getting a '/' to be used as the
directory separator in a url when building things on
non-Unix (Win32 in particular).
==============================================================
Index: lib/Module/Build/Base.pm
===================================================================
RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v
retrieving revision 1.240
diff -u -r1.240 Base.pm
--- lib/Module/Build/Base.pm	15 Jan 2004 04:18:46 -0000	1.240
+++ lib/Module/Build/Base.pm	15 Jan 2004 16:57:55 -0000
@@ -1360,6 +1360,73 @@
   return '';
 }

+sub ACTION_html {
+  require Pod::Find;
+  require Pod::Html;
+  my $self = shift;
+  $self->depends_on('build');
+  my $cwd = $self->cwd;
+  $cwd =~ s!^\w:!!;
+  $cwd =~ s!(\\|:)!/!g;
+  my $html_base = $Config{installhtmldir} ?
+    File::Basename::basename($Config{installhtmldir}) : 'html';
+  my $blib = File::Spec::Unix->catdir($cwd, 'blib');
+  my $html = File::Spec::Unix->catdir($blib, $html_base);
+  my $script = File::Spec::Unix->catdir($blib, 'script');
+  unless (-d $html) {
+    File::Path::mkpath($html, 1, 0755) or die "Couldn't mkdir $html: $!";
+  }
+  my %pods = Pod::Find::pod_find({-verbose => 1}, $blib);
+  if (-d $script) {
+    File::Find::finddepth( sub
+                           {$pods{$File::Find::name} =
+                              "script::" . basename($File::Find::name)
+                                if (-f $_ and not /\.bat$/ and $self->contains_pod($_));
+                          }, $script);
+  }
+
+  my $backlink = '__top';
+  my $css = ($^O =~ /Win32/) ? 'Active.css' : '';
+  foreach my $pod (keys %pods){
+    my @dirs = split /::/, $pods{$pod};
+    my $isbin = shift @dirs eq 'script';
+    my $infile = File::Spec::Unix->abs2rel($pod);
+    my $outfile = (pop @dirs) . '.html';
+
+    my @rootdirs  = $isbin? ('bin') : ('site', 'lib');
+    my $path2root = "../" x (@rootdirs+@dirs);
+    $path2root =~ s!/$!!;
+
+    my $fulldir = File::Spec::Unix->catfile($html, @rootdirs, @dirs);
+    unless (-d $fulldir){
+      File::Path::mkpath($fulldir, 1, 0755)
+          or die "Couldn't mkdir $fulldir: $!";
+    }
+    $outfile = File::Spec::Unix->catfile($fulldir, $outfile);
+
+    my $htmlroot = File::Spec::Unix->catdir($path2root, 'site', 'lib');
+    my $podpath = join ":" => map { File::Spec::Unix->catdir($blib, $_) }
+      ($isbin ? qw(bin lib) : qw(lib));
+    (my $package = $pods{$pod}) =~ s!^(lib|script)::!!;
+    my $abstract = $self->dist_abstract($infile);
+    my $title =  $abstract ? "$package - $abstract" : $package;
+    my @opts = (
+		'--header',
+                '--flush',
+                "--backlink=$backlink",
+		"--title=$title",
+                "--podpath=$podpath",
+		"--infile=$infile",
+		"--outfile=$outfile",
+		"--podroot=$blib",
+		"--htmlroot=$htmlroot",
+	       );
+    push @opts, "--css=$path2root/$css" if $css;
+    print "pod2html @opts\n";
+    Pod::Html::pod2html(@opts);# or warn "pod2html @opts failed: $!";
+  }
+}
+
 # Adapted from ExtUtils::MM_Unix
 sub man1page_name {
   my $self = shift;
@@ -1452,6 +1519,33 @@
   my %onlyargs = map {exists($self->{args}{$_}) ? ($_ => $self->{args}{$_}) : ()}
     qw(version versionlib);
   only::install::install(%onlyargs);
+}
+
+sub ACTION_htmlinstall {
+  return unless my $destdir = $Config{installhtmldir};
+  my $self = shift;
+  $self->depends_on('html');
+  my $cwd = $self->cwd;
+  my $blib = File::Spec->catdir($cwd, 'blib');
+  my $html_base = File::Spec->catdir($blib,
+                                     File::Basename::basename($destdir));
+  my @files;
+  File::Find::finddepth(sub
+                        {push @files, $File::Find::name
+                           if $File::Find::name =~ /\.html$/
+                         }, $html_base);
+  foreach my $file (@files) {
+    (my $relative_to = $file) =~ s!\Q$html_base!!;
+    $relative_to =~ s!^/!!;
+    my $to = File::Spec->catfile($destdir, $relative_to);
+    my $base_dir = File::Basename::dirname($to);
+    unless (-d $base_dir) {
+      File::Path::mkpath($base_dir, 1, 0755)
+          or die "Cannot mkpath $base_dir: $!";
+    }
+    File::Copy::copy($file, $to)
+        or warn "Cannot copy '$file' to '$to': $!";
+  }
 }

 sub ACTION_clean {

================================================================

-- 
best regards,
randy kobes

[Module::Build] how about shared data

[Jaap K. <j.g...@st...>]

Sory to bother you again, but what happens if I need to install stuff
into "/usr/share/$program_name" ? I know perl has no config value for
this but it seems rather essential for packages that contain a complete
program.

-- 
   )   (     Jaap Karssenberg || Pardus [Larus]                | |0| |
   :   :     http://pardus-larus.student.utwente.nl/~pardus    | | |0|
 )  \ /  (                                                     |0|0|0|
 ",.*'*.,"   Proud owner of "Perl6 Essentials" 1st edition :)  wannabe

[Module::Build] .PL files && Module::Build

[Jaap K. <j.g...@st...>]

Greetings,

I'm trying to move a rather large package to Module::Build. It has lot's
of custom built-time config so I moved away from MM a while ago and have
used a hack for a while.

I have to rely on .PL files a lot now to do config stuff and I was
wondering whether there is an interface in Module::Build to get build
variables. Basicly I want to know the run-time equivalent of the
contents of _build/build_params. The hack would be to read build_params
myself, but this won't be portable I guess; also if the user supplies
commandline arguments to ./Build they get ignored. 
If Module::Build does not provide this (yet) I will write a patch that
ads an option to dumps the run-time variables to a tmp file.

Do you plan to have the 'checkdeps' (check dependenies) and
'installdeps' (install dependencies from CPAN) actions ?
Would you include these if I send you a patch ?

Nice work so far, like it better then MM allready :)

	Jaap Karssenberg <pa...@cp...>

PS. sorry for not directly using the list - didn't see it at first

P.P.S. And another question, where do I leave extra manpages for section
1, could there be a equivalent for 'pod_files', 'pod1_files' or
something similar ?

-- 
   )   (     Jaap Karssenberg || Pardus [Larus]                | |0| |
   :   :     http://pardus-larus.student.utwente.nl/~pardus    | | |0|
 )  \ /  (                                                     |0|0|0|
 ",.*'*.,"   Proud owner of "Perl6 Essentials" 1st edition :)  wannabe

Re: [Module::Build] [PATCH] ppm_dist action

[Ken W. <ke...@ma...>]

On Wednesday, January 14, 2004, at 11:58  PM, Randy W. Sims wrote:
>
> I've just about convinced my self to write (HA!) a rough HOW-TO to 
> cover some of the most common scenarios of writing a 'Build.PL' script 
> and how to invoke M::B. Although you would rather I didn't (trust me).

The Module::Build::Cookbook would be a great place for this.

  -Ken

Re: [Module::Build] [PATCH] ppm_dist action

[Ken W. <ke...@ma...>]

On Wednesday, January 14, 2004, at 11:19  PM, Randy W. Sims wrote:

> On 1/14/2004 11:18 PM, Ken Williams wrote:
>
>> Here's the patch I'm applying, based on Randy Sims' - let me know if 
>> it needs modification.
>
> Uhm, can we change the action name? After looking at the names used in 
> MakeMaker and M::B, I see I'm the only wierdo that used an underscore. 
> 'ppmdist' would be just fine. And...
>
> =item ppmdist
>
> Generates a PPM binary distribution and a PPD description file.
>
> This action also invokes the 'ppd' action, so it can accept the same 
> C<codebase> argument described under that action.
>

Thanks, both patches applied.

  -Ken

Re: [Module::Build] [PATCH] ppm_dist action

[Ken W. <ke...@ma...>]

On Wednesday, January 14, 2004, at 11:01  PM, Glenn Linderman wrote:

> On approximately 1/14/2004 3:39 PM, came the following characters from
> the keyboard of Randy W. Sims:
>
>> The contents of the 'MANIFEST.SKIP' file are a series of regular 
>> expressions, one per line, that if matched to a file /path/ while 
>> scanning the distribution directory, will be omitted from the 
>> 'MANIFEST' file. (Maybe the above list should automatically be added 
>> to the skip list?)
>
> Yes, particularly if MANIFEST.SKIP doesn't exist, I think using that 
> list would be an excellant option.  Many simple modules wouldn't even 
> need a MANIFEST.SKIP in that case.

Yeah, MakeMaker does something like that, maybe we should too.


> dist - seemed like it should work for PPD on Windows platform.  Now 
> that ppm_dist exists this might not be so confusing.

I'm actually not quite sure where you got this impression - the 
documentation for the "dist" action says this:

  This action is helpful for module authors who want to package up their
  module for distribution through a medium like CPAN.  It will create a
  tarball of the files listed in F<MANIFEST> and compress the tarball 
using
  GZIP compression.

  -Ken

Re: [Module::Build] Ready for 0.22?

[<mod...@tm...>]

On Wed, Jan 14, 2004 at 07:57:58PM -0600, Ken Williams wrote:
> >As I'm using Test::Class, and my test are all in 
> >lib/My/Project/Test/*.pm,
> >the normal t/*.t approach doesn't really work for me...
> Ah - I guess the only reason this isn't documented is that it never 
> occurred to me to use 'test_files' the way you're using it.  I always 
> use it as just a way to pick a certain t/*.t file for spot testing.  
> But I can see how it's useful the way you're using it too.
> I'll add it to the docs for the next release, you can consider it 
> stable.

Great.

Thanks,

Tony

[Module::Build] any pod2html action?

[Uri G. <ur...@st...>]

i was looking for an action that would do pod2html on all the pm files
and i can't seem to find one. would this be a good thing to have? if
none exists i will probably write my own and post it here.

uri

-- 
Uri Guttman  ------  ur...@st...  -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org

Re: [Module::Build] [PATCH] ppm_dist action

[Randy W. S. <Ra...@Th...>]

On 1/15/2004 12:01 AM, Glenn Linderman wrote:

> On approximately 1/14/2004 3:39 PM, came the following characters from
> the keyboard of Randy W. Sims:
> 
>> On 1/14/2004 11:09 AM, Glenn Linderman wrote:
>>
>> So, ppm install <your-module> does work ???
> 
> Yes that is correct.  At least on my machine, with A::T 1.08_01.

YeeHah!! Yipee!! Woohoo!

> I still think A::T needs some work, such that archives with paths less 
> than 100 characters, and no paths greater than 100 characters, can be 
> compatible with older tools.  Either than, or only older versions of 
> A::T should be used to build modules, so that the older tools work.

blah! You had to mention that...

>>> But why do I get errors during "perl build.pl" telling me that the 
>>> files built by the build step are not present at the "perl build.pl" 
>>> step?  As far as I can determine, they shouldn't be.  A similar 
>>> warning for META.yml and README showed up when I did "perl build.pl" 
>>> for the Module-Build.zip above.  Such warnings do not engender 
>>> confidence in the module, or in the M::B process.
>>
>> Module::Build works the same in this regard as MakeMaker; in fact, 
>> they both use the same module, ExtUtils::Manifest. You probably know 
>> that every module on CPAN contains a MANIFEST file. This file contains 
>> a list of every file included in the CPAN distribution, and it is used 
>> as a sanity check to detect corrupted distributions (and absent-minded 
>> authors). One of the first things that happen when you type 'perl 
>> Build.PL' or 'perl Makefile.PL' is that the contents of the MANIFEST 
>> is compared to the contents of the directory where the distribution is 
>> unpacked. If there is a mismatch, you will see the warnings you noted 
>> above.
> 
> Well, I don't know anything about MANIFEST except what M::B taught me by 
> reading its documentation and playing with it.  And what you've told me 
> here.

I've just about convinced my self to write (HA!) a rough HOW-TO to cover 
some of the most common scenarios of writing a 'Build.PL' script and how 
to invoke M::B. Although you would rather I didn't (trust me).

>> As a module author you must keep the MANIFEST up to date. For 
>> Module::Build users, you need to create a 'MANIFEST.SKIP' file with at 
>> least the following contents:
>>
>> ^_build
>> ^Build$
>> ^blib
>> ^MANIFEST\.SKIP$
>>
>> (Others are suggested in the Module::Build and the ExtUtils::Manifest 
>> pods.)
> 
> 
> OK, so here I specifically added things from blib, because stuff wasn't 
> showing up in the "build dist" archive... lacking "build ppm_dist", I 
> was confused.  I think now that you are saying that I should take them 
> out.  I'll try that.... yep, it still works.  And the warnings are gone.

Great!

>> The contents of the 'MANIFEST.SKIP' file are a series of regular 
>> expressions, one per line, that if matched to a file /path/ while 
>> scanning the distribution directory, will be omitted from the 
>> 'MANIFEST' file. (Maybe the above list should automatically be added 
>> to the skip list?)
> 
> Yes, particularly if MANIFEST.SKIP doesn't exist, I think using that 
> list would be an excellant option.  Many simple modules wouldn't even 
> need a MANIFEST.SKIP in that case.

Can we? Can we? Please? huh? Can we?

>>> I'm assuming that for distribution for PPM users, that I will never 
>>> need to use  "perl build dist"... so the "differing content" in the 
>>> .tar.gz file build by "dist" vs "ppm_dist" won't annoy me... but will 
>>> it annoy others, that want to do both types of distributions?
>>
>> To be honest, I don't have an opinion about this issue. It would seem 
>> like authors should just know and should test each dist before 
>> release, so it shouldn't be an issue. I don't see any obvious 
>> alternative that I like.
> 
> Well, I'm not educated enough in this area to suggest an alternative 
> either, at least with any assurance that it makes sense.  I made one 
> suggestion about adding _CPAN and _PPD to the name of the file, and I 
> think I myself would be annoyed if all the distributoins had that tag. 
> But maybe...  maybe this idea would have some merit...

Well, I don't really like anything that's been suggested so far, nor do 
I like the current behaviour. I just don't see an elegant solution that 
doesn't involve some degree of confusion or inconvenience. May be it 
should be left up to the user by providing for arguments to the 'dist' 
and 'ppmdist' action that specify the location and name to use, but then 
you have to provide a default which brings us back to having no good 
solution. That's basically why I said I have no opinion--because all the 
alternatives seem rather yuckee to me. :-)

Randy.

Re: [Module::Build] [PATCH] ppm_dist action

[Randy W. S. <Ra...@Th...>]

On 1/14/2004 9:55 PM, Randy Kobes wrote:

> etc. As well, if one wanted to include html documentation,
> it should go under
>   blib/html/site/lib/
> If ppm finds such html docs, it will install them in the
> user's Perl/html/ tree, and update the main index.html
> accordingly. If there's interest, I have some code around
> that could generate such docs from the pod/pm files in the
> distribution - it wouldn't be too hard to supply a M::B
> patch to do so.

I think html docs would be nice to have in general, not just the 
ActiveState version. There was some discussion of this before, but I 
don't think anything came of it... Ok, yeah, back on Oct 15, Kevin 
Ruscoe brought it up (in the thread "PROPOSAL: M::B should install HTML 
documentation")... Uhm, Chris Dolan said he had written a 
Module::Build::Html package for "internal company use only", but was 
willing to integrate it into M::B... nothing. It looks like it might 
possibly have been inadvertently discouraged by some @$$ who posted in 
that thread:

> There is another issue here in that the list of actions is growing quite large, and M::B is (IMHO) turning into a large monolithic module. Would it be worth the effort to re-architect actions, so that they are plug-ins (M::B::ACTION::html, M::B::ACTION::dist). This would keep M::B from becoming monolithic and would allow others to develop plug-ins to expand functionality without requiring invasive code changes. 

hmm, all this ActiveState specific stuff (ppmdist, ppd, htmldocs) 
_would_ make a nice set of plugins... ;-)

Regards,
some @$$

Re: [Module::Build] [PATCH] ppm_dist action

[Randy W. S. <Ra...@Th...>]

On 1/14/2004 11:18 PM, Ken Williams wrote:

> Here's the patch I'm applying, based on Randy Sims' - let me know if it 
> needs modification.

Uhm, can we change the action name? After looking at the names used in 
MakeMaker and M::B, I see I'm the only wierdo that used an underscore. 
'ppmdist' would be just fine. And...

=item ppmdist

Generates a PPM binary distribution and a PPD description file.

This action also invokes the 'ppd' action, so it can accept the same 
C<codebase> argument described under that action.

Re: [Module::Build] [PATCH] ppm_dist action

[Glenn L. <pe...@ne...>]

On approximately 1/14/2004 3:39 PM, came the following characters from
the keyboard of Randy W. Sims:
> On 1/14/2004 11:09 AM, Glenn Linderman wrote:
> 
>> The decompress and build and install all worked lots better this time.
>>
>> Now to try building my GFfP module...
>>
>> Yes, that seems to work too.  Hurray!
> 
> 
> So, ppm install <your-module> does work ???

Yes that is correct.  At least on my machine, with A::T 1.08_01.

I still think A::T needs some work, such that archives with paths less 
than 100 characters, and no paths greater than 100 characters, can be 
compatible with older tools.  Either than, or only older versions of 
A::T should be used to build modules, so that the older tools work.


>> As expected, though, the paths are not visible.
>>
>>
>> Now what about the organization of my module?
>>
>> I misspoke when I mentioned needing to put my .pm file in blib 
>> manually, it is required to be in lib, which is much less likely to 
>> get deleted.
>>
>> But why do I get errors during "perl build.pl" telling me that the 
>> files built by the build step are not present at the "perl build.pl" 
>> step?  As far as I can determine, they shouldn't be.  A similar 
>> warning for META.yml and README showed up when I did "perl build.pl" 
>> for the Module-Build.zip above.  Such warnings do not engender 
>> confidence in the module, or in the M::B process.
> 
> 
> Module::Build works the same in this regard as MakeMaker; in fact, they 
> both use the same module, ExtUtils::Manifest. You probably know that 
> every module on CPAN contains a MANIFEST file. This file contains a list 
> of every file included in the CPAN distribution, and it is used as a 
> sanity check to detect corrupted distributions (and absent-minded 
> authors). One of the first things that happen when you type 'perl 
> Build.PL' or 'perl Makefile.PL' is that the contents of the MANIFEST is 
> compared to the contents of the directory where the distribution is 
> unpacked. If there is a mismatch, you will see the warnings you noted 
> above.

Well, I don't know anything about MANIFEST except what M::B taught me by 
reading its documentation and playing with it.  And what you've told me 
here.

> As a module author you must keep the MANIFEST up to date. For 
> Module::Build users, you need to create a 'MANIFEST.SKIP' file with at 
> least the following contents:
> 
> ^_build
> ^Build$
> ^blib
> ^MANIFEST\.SKIP$
> 
> (Others are suggested in the Module::Build and the ExtUtils::Manifest 
> pods.)

OK, so here I specifically added things from blib, because stuff wasn't 
showing up in the "build dist" archive... lacking "build ppm_dist", I 
was confused.  I think now that you are saying that I should take them 
out.  I'll try that.... yep, it still works.  And the warnings are gone.


> The contents of the 'MANIFEST.SKIP' file are a series of regular 
> expressions, one per line, that if matched to a file /path/ while 
> scanning the distribution directory, will be omitted from the 'MANIFEST' 
> file. (Maybe the above list should automatically be added to the skip 
> list?)

Yes, particularly if MANIFEST.SKIP doesn't exist, I think using that 
list would be an excellant option.  Many simple modules wouldn't even 
need a MANIFEST.SKIP in that case.


> Once you have that setup all you need to do is run 'perl Build manifest' 
> anytime you add or remove a file from your distribution. Although it 
> might initially seem complex, in practice, it is a very simple procedure 
> that helps make sure distributions are 'sane'.
> 
> The reason you got the errors in the zip file I posted is that I didn't 
> prepare it as a distribution--It was just for testing.
> 
>> But at least it works now, it is much more fun to talk about the 
>> "little" problems when the basic functionality works!
>>
>> I'm assuming that for distribution for PPM users, that I will never 
>> need to use  "perl build dist"... so the "differing content" in the 
>> .tar.gz file build by "dist" vs "ppm_dist" won't annoy me... but will 
>> it annoy others, that want to do both types of distributions?
> 
> 
> To be honest, I don't have an opinion about this issue. It would seem 
> like authors should just know and should test each dist before release, 
> so it shouldn't be an issue. I don't see any obvious alternative that I 
> like.

Well, I'm not educated enough in this area to suggest an alternative 
either, at least with any assurance that it makes sense.  I made one 
suggestion about adding _CPAN and _PPD to the name of the file, and I 
think I myself would be annoyed if all the distributoins had that tag. 
But maybe...  maybe this idea would have some merit...

Maybe a build area should have 2 more directories, CPAN and PPM (and 
those should be added to the MANIFEST.SKIP and the default skip list 
mentioned above).

The command  build dist  should put its .tar.gz file in the CPAN 
directory, and the commands  build ppm_dist  and  build ppd  should put 
their output in the PPM directory (creating the directories if they 
don't exist).

One thing for sure... assuming that "authors should just know" is a 
great way to perpetuate the confusion.  Now that it seems that Randy, 
you, and I have pooled our knowledge and my stumblings around with this 
simple module, it might be nice to add documentation and/or pointers to 
such documentation to the M::B help files.  The following things were 
very confusing to me:

MANIFEST - where should I look for documentation

dist - seemed like it should work for PPD on Windows platform.  Now that 
ppm_dist exists this might not be so confusing.

ppd - I think all my confusion with this has gone away with the numerous 
fixes that have been made.


> Regards,
> Randy.

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [Module::Build] [PATCH] ppm_dist action

[Glenn L. <pe...@ne...>]

On approximately 1/14/2004 6:55 PM, came the following characters from
the keyboard of Randy Kobes:

> On Wed, 14 Jan 2004, Ken Williams wrote:
> 
> 
>>On Tuesday, January 13, 2004, at 08:46  PM, Randy W. Sims wrote:
>>
>>
>>>>* For backwards compatibility (not really sure it's
>>>>neccessary at this point, but...) I'd suggest leaving
>>>>the 'ppd' action as is, and create a new 'ppm_dist'
>>>>action that runs the 'ppd' action and creates an
>>>>archive of the blib directory, running the 'build'
>>>>action if neccessary. Ken?
>>>
>>>Attached is a patch that adds a new 'ppm_dist' action.
>>>It accepts a 'codebase' argument just like the 'ppd'
>>>action. This action runs the 'ppd' action and then
>>>builds an archive of the blib directory. Glenn, this
>>>should allow you to "install on the same machine it is
>>>built on".  The 'ppd' action remains unchanged. Please
>>>let me know if this patch is correct.
>>
>>It changes the semantics of the make_tarball() method a
>>bit - I think we probably also want to make the tarball
>>unpack to a name matching the filename people download.
>>So I think maybe we should copy blib/ to a new directory
>>(once the naming issue is solved) and then tarball it up,
>>using the same old make_tarball() method.
> 
> 
> Unfortunately, the ppm utility is pretty picky about
> about the structure of the associated codebase archive -
> it can have any name one wants (as long as it's specified
> as such in the ppd file), but it should unpack into a
> top-level blib/ directory, so as to have the structure
>    blib/arch/
>    blib/bin/
>    blib/lib/
> etc. As well, if one wanted to include html documentation,
> it should go under
>   blib/html/site/lib/
> If ppm finds such html docs, it will install them in the
> user's Perl/html/ tree, and update the main index.html
> accordingly. If there's interest, I have some code around
> that could generate such docs from the pod/pm files in the
> distribution - it wouldn't be too hard to supply a M::B
> patch to do so.

I think it would be a nice addition to M::B to generate the HTML docs 
for ppm_dist, since that seems to be the model promulgated by 
ActiveState.  And that reminds me, I need to figure out how to use POD 
someday, now that I've written a [trivial] module :)

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [Module::Build] [PATCH] ppm_dist action

[Ken W. <ke...@ma...>]

Here's the patch I'm applying, based on Randy Sims' - let me know if it 
needs modification.

  -Ken

Index: lib/Module/Build/Base.pm
===================================================================
RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v
retrieving revision 1.239
diff -u -r1.239 Base.pm
--- lib/Module/Build/Base.pm	15 Jan 2004 02:48:43 -0000	1.239
+++ lib/Module/Build/Base.pm	15 Jan 2004 04:16:35 -0000
@@ -1475,6 +1475,14 @@
    $self->add_to_cleanup($file);
  }

+sub ACTION_ppm_dist {
+  my ($self) = @_;
+
+  $self->depends_on('build', 'ppd');
+  $self->add_to_cleanup($self->ppm_name);
+  $self->make_tarball($self->{properties}{blib}, $self->ppm_name);
+}
+
  sub ACTION_dist {
    my ($self) = @_;

@@ -1616,6 +1624,11 @@
    return 
"$self->{properties}{dist_name}-$self->{properties}{dist_version}";
  }

+sub ppm_name {
+  my $self = shift;
+  return 'PPM-' . $self->dist_dir;
+}
+
  sub script_files {
    my $self = shift;
    if (@_) {
@@ -1743,18 +1756,22 @@
  }

  sub make_tarball {
-  my ($self, $dir) = @_;
-
-  print "Creating $dir.tar.gz\n";
+  my ($self, $dir, $file) = @_;
+  $file ||= $dir;
+
+  print "Creating $file.tar.gz\n";

    if ($self->{args}{tar}) {
      my $tar_flags = $self->{properties}{verbose} ? 'cvf' : 'cf';
-    $self->do_system($self->{args}{tar}, $tar_flags, "$dir.tar", $dir);
-    $self->do_system($self->{args}{gzip}, "$dir.tar") if 
$self->{args}{gzip};
+    $self->do_system($self->{args}{tar}, $tar_flags, "$file.tar", 
$dir);
+    $self->do_system($self->{args}{gzip}, "$file.tar") if 
$self->{args}{gzip};
    } else {
      require Archive::Tar;
+    # Archive::Tar versions >= 1.09 use the following to enable a 
compatibility
+    # hack so that the resulting archive is compatible with older 
clients.
+    $Archive::Tar::DO_NOT_USE_PREFIX = 0;
      my $files = $self->rscan_dir($dir);
-    Archive::Tar->create_archive("$dir.tar.gz", 1, @$files);
+    Archive::Tar->create_archive("$file.tar.gz", 1, @$files);
    }
  }

Index: lib/Module/Build/PPMMaker.pm
===================================================================
RCS file: 
/cvsroot/module-build/Module-Build/lib/Module/Build/PPMMaker.pm,v
retrieving revision 1.6
diff -u -r1.6 PPMMaker.pm
--- lib/Module/Build/PPMMaker.pm	9 Jan 2004 17:06:21 -0000	1.6
+++ lib/Module/Build/PPMMaker.pm	15 Jan 2004 04:16:36 -0000
@@ -21,7 +21,7 @@
    if (exists $args{codebase}) {
      @codebase = ref $args{codebase} ? @{$args{codebase}} : 
($args{codebase});
    } else {
-    my $distfile = $build->dist_dir . ".tar.gz";
+    my $distfile = $build->ppm_name . '.tar.gz';
      print "Using default codebase '$distfile'\n";
      @codebase = ($distfile);
    }

Re: [Module::Build] [PATCH] ppm_dist action

[Ken W. <ke...@ma...>]

On Wednesday, January 14, 2004, at 08:55  PM, Randy Kobes wrote:
> Unfortunately, the ppm utility is pretty picky about
> about the structure of the associated codebase archive -
> it can have any name one wants (as long as it's specified
> as such in the ppd file), but it should unpack into a
> top-level blib/ directory, so as to have the structure
>    blib/arch/
>    blib/bin/
>    blib/lib/
> etc. As well, if one wanted to include html documentation,
> it should go under
>   blib/html/site/lib/
> If ppm finds such html docs, it will install them in the
> user's Perl/html/ tree, and update the main index.html
> accordingly. If there's interest, I have some code around
> that could generate such docs from the pod/pm files in the
> distribution - it wouldn't be too hard to supply a M::B
> patch to do so.

Oh, I see - I guess people don't actually manually unpack these PPMs, 
do they.  Then I guess I don't care *what* it unpacks to. ;=)

I'm not jumping up & down for the HTML docs, but I'll apply a patch if 
you give me one.

In the meantime I think I'll apply your PPM patch, with a little mod to 
change the generated filename.

  -Ken

Re: [Module::Build] [PATCH] ppm_dist action

[Randy K. <ra...@th...>]

On Wed, 14 Jan 2004, Ken Williams wrote:

> On Tuesday, January 13, 2004, at 08:46  PM, Randy W. Sims wrote:
>
> >> * For backwards compatibility (not really sure it's
> >> neccessary at this point, but...) I'd suggest leaving
> >> the 'ppd' action as is, and create a new 'ppm_dist'
> >> action that runs the 'ppd' action and creates an
> >> archive of the blib directory, running the 'build'
> >> action if neccessary. Ken?
> >
> > Attached is a patch that adds a new 'ppm_dist' action.
> > It accepts a 'codebase' argument just like the 'ppd'
> > action. This action runs the 'ppd' action and then
> > builds an archive of the blib directory. Glenn, this
> > should allow you to "install on the same machine it is
> > built on".  The 'ppd' action remains unchanged. Please
> > let me know if this patch is correct.
>
> It changes the semantics of the make_tarball() method a
> bit - I think we probably also want to make the tarball
> unpack to a name matching the filename people download.
> So I think maybe we should copy blib/ to a new directory
> (once the naming issue is solved) and then tarball it up,
> using the same old make_tarball() method.

Unfortunately, the ppm utility is pretty picky about
about the structure of the associated codebase archive -
it can have any name one wants (as long as it's specified
as such in the ppd file), but it should unpack into a
top-level blib/ directory, so as to have the structure
   blib/arch/
   blib/bin/
   blib/lib/
etc. As well, if one wanted to include html documentation,
it should go under
  blib/html/site/lib/
If ppm finds such html docs, it will install them in the
user's Perl/html/ tree, and update the main index.html
accordingly. If there's interest, I have some code around
that could generate such docs from the pod/pm files in the
distribution - it wouldn't be too hard to supply a M::B
patch to do so.

-- 
best regards,
randy

Re: [Module::Build] [PATCH] ppm_dist action

[Ken W. <ke...@ma...>]

On Tuesday, January 13, 2004, at 08:46  PM, Randy W. Sims wrote:

>> * For backwards compatibility (not really sure it's neccessary at 
>> this point, but...) I'd suggest leaving the 'ppd' action as is, and 
>> create a new 'ppm_dist' action that runs the 'ppd' action and creates 
>> an archive of the blib directory, running the 'build' action if 
>> neccessary. Ken?
>
> Attached is a patch that adds a new 'ppm_dist' action. It accepts a 
> 'codebase' argument just like the 'ppd' action. This action runs the 
> 'ppd' action and then builds an archive of the blib directory. Glenn, 
> this should allow you to "install on the same machine it is built on". 
> The 'ppd' action remains unchanged. Please let me know if this patch 
> is correct.

It changes the semantics of the make_tarball() method a bit - I think 
we probably also want to make the tarball unpack to a name matching the 
filename people download.  So I think maybe we should copy blib/ to a 
new directory (once the naming issue is solved) and then tarball it up, 
using the same old make_tarball() method.

  -Ken

Re: [Module::Build] [PATCH] ppm_dist action

[Ken W. <ke...@ma...>]

On Wednesday, January 14, 2004, at 08:08  PM, Randy Kobes wrote:
>
> There would be a problem with using the same names for the
> 'dist' and 'ppm_dist' archives if the module author wanted
> to make up a CPAN distribution and include the 'ppm_dist'
> archive (and associated ppd file) in it, so Win32 users
> could just extract the ppd and associated 'ppm_dist' archive
> and install it using ppm. What might be an idea is to rename
> the 'ppm_dist' archive to, eg, 'Module-Name.tar.gz', and
> adjust the codebase reference in Module-Name.ppd accordingly
> (remember that you would then have to add these two files to
> MANIFEST to get them included in the CPAN 'dist' archive).

Oh, I see - I didn't understand the issue when I sent the last message. 
  The problem is that Module-Name-0.01.tar.gz could alternately be a 
CPAN source distribution or a PPM distribution?  Then yeah, that is 
confusing.

How about something even more informative for the PPD, like

  PPM-Module-Name.tar.gz

or

  PPM-Module-Name.zip

or something?

  -Ken

Re: [Module::Build] [PATCH] ppm_dist action

[Ken W. <ke...@ma...>]

On Wednesday, January 14, 2004, at 10:09  AM, Glenn Linderman wrote:
> But why do I get errors during "perl build.pl" telling me that the 
> files built by the build step are not present at the "perl build.pl" 
> step?  As far as I can determine, they shouldn't be.  A similar 
> warning for META.yml and README showed up when I did "perl build.pl" 
> for the Module-Build.zip above.  Such warnings do not engender 
> confidence in the module, or in the M::B process.

Well, they're errors - errors *shouldn't* inspire confidence.  They 
indicated the real problems Randy explained.


> I'm assuming that for distribution for PPM users, that I will never 
> need to use  "perl build dist"... so the "differing content" in the 
> .tar.gz file build by "dist" vs "ppm_dist" won't annoy me... but will 
> it annoy others, that want to do both types of distributions?

Nah.  A regular distribution on CPAN is a source distribution that 
downloaders build themselves.  A PPM is a pre-built binary 
distribution.  They're meant to have very different contents.

  -Ken

Re: [Module::Build] [PATCH] ppm_dist action

[Randy K. <ra...@th...>]

On Wed, 14 Jan 2004, Randy W. Sims wrote:

> On 1/14/2004 11:09 AM, Glenn Linderman wrote:
[ ... ]
> > I'm assuming that for distribution for PPM users, that I
> > will never need to use "perl build dist"... so the
> > "differing content" in the .tar.gz file build by "dist"
> > vs "ppm_dist" won't annoy me... but will it annoy
> > others, that want to do both types of distributions?
>
> To be honest, I don't have an opinion about this issue. It
> would seem like authors should just know and should test
> each dist before release, so it shouldn't be an issue. I
> don't see any obvious alternative that I like.

There would be a problem with using the same names for the
'dist' and 'ppm_dist' archives if the module author wanted
to make up a CPAN distribution and include the 'ppm_dist'
archive (and associated ppd file) in it, so Win32 users
could just extract the ppd and associated 'ppm_dist' archive
and install it using ppm. What might be an idea is to rename
the 'ppm_dist' archive to, eg, 'Module-Name.tar.gz', and
adjust the codebase reference in Module-Name.ppd accordingly
(remember that you would then have to add these two files to
MANIFEST to get them included in the CPAN 'dist' archive).

-- 
best regards,
randy

Re: [Module::Build] Ready for 0.22?

[Ken W. <ke...@ma...>]

On Tuesday, January 13, 2004, at 07:15  PM, Tony Bowden wrote:

>> Any outstanding issues before I release 0.22 to CPAN?  If there's 
>> still a
>> significant CVS lag, here's the list of changes since the last beta:
>
> I'm coming in late, so apologies if this has already changed, but 
> AFAICS
> the current release doesn't document being able to specify a listref
> of test_files in your Build.PL. It mentions this as a command line arg,
> but I had to guess that you could also do it in Build.PL. I always hate
> relying on undocumented features so if this is a real one it would be
> nice if that was documented up with pm_files, pod_files, etc.
>
> As I'm using Test::Class, and my test are all in 
> lib/My/Project/Test/*.pm,
> the normal t/*.t approach doesn't really work for me...

Ah - I guess the only reason this isn't documented is that it never 
occurred to me to use 'test_files' the way you're using it.  I always 
use it as just a way to pick a certain t/*.t file for spot testing.  
But I can see how it's useful the way you're using it too.

I'll add it to the docs for the next release, you can consider it 
stable.

  -Ken

Re: [Module::Build] [PATCH] ppm_dist action

[Randy W. S. <Ra...@Th...>]

On 1/14/2004 11:09 AM, Glenn Linderman wrote:
> The decompress and build and install all worked lots better this time.
> 
> Now to try building my GFfP module...
> 
> Yes, that seems to work too.  Hurray!

So, ppm install <your-module> does work ???

> As expected, though, the paths are not visible.
> 
> 
> Now what about the organization of my module?
> 
> I misspoke when I mentioned needing to put my .pm file in blib manually, 
> it is required to be in lib, which is much less likely to get deleted.
> 
> But why do I get errors during "perl build.pl" telling me that the files 
> built by the build step are not present at the "perl build.pl" step?  As 
> far as I can determine, they shouldn't be.  A similar warning for 
> META.yml and README showed up when I did "perl build.pl" for the 
> Module-Build.zip above.  Such warnings do not engender confidence in the 
> module, or in the M::B process.

Module::Build works the same in this regard as MakeMaker; in fact, they 
both use the same module, ExtUtils::Manifest. You probably know that 
every module on CPAN contains a MANIFEST file. This file contains a list 
of every file included in the CPAN distribution, and it is used as a 
sanity check to detect corrupted distributions (and absent-minded 
authors). One of the first things that happen when you type 'perl 
Build.PL' or 'perl Makefile.PL' is that the contents of the MANIFEST is 
compared to the contents of the directory where the distribution is 
unpacked. If there is a mismatch, you will see the warnings you noted above.

As a module author you must keep the MANIFEST up to date. For 
Module::Build users, you need to create a 'MANIFEST.SKIP' file with at 
least the following contents:

^_build
^Build$
^blib
^MANIFEST\.SKIP$

(Others are suggested in the Module::Build and the ExtUtils::Manifest pods.)

The contents of the 'MANIFEST.SKIP' file are a series of regular 
expressions, one per line, that if matched to a file /path/ while 
scanning the distribution directory, will be omitted from the 'MANIFEST' 
file. (Maybe the above list should automatically be added to the skip list?)

Once you have that setup all you need to do is run 'perl Build manifest' 
anytime you add or remove a file from your distribution. Although it 
might initially seem complex, in practice, it is a very simple procedure 
that helps make sure distributions are 'sane'.

The reason you got the errors in the zip file I posted is that I didn't 
prepare it as a distribution--It was just for testing.

> But at least it works now, it is much more fun to talk about the 
> "little" problems when the basic functionality works!
> 
> I'm assuming that for distribution for PPM users, that I will never need 
> to use  "perl build dist"... so the "differing content" in the .tar.gz 
> file build by "dist" vs "ppm_dist" won't annoy me... but will it annoy 
> others, that want to do both types of distributions?

To be honest, I don't have an opinion about this issue. It would seem 
like authors should just know and should test each dist before release, 
so it shouldn't be an issue. I don't see any obvious alternative that I 
like.

Regards,
Randy.

Re: [Module::Build] [PATCH] ppm_dist action

[Glenn L. <pe...@ne...>]

On approximately 1/13/2004 11:21 PM, came the following characters from
the keyboard of Randy W. Sims:

> On 1/14/2004 1:12 AM, Glenn Linderman wrote:
> 
>> On approximately 1/13/2004 8:50 PM, came the following characters from
>> the keyboard of Randy W. Sims:
>>
>>> To make it easier, I've put a snapshot of the current CVS + this 
>>> patch at <http://www.thepierianspring.org/Module-Build.zip>.
>>
>>
>>
>> Well, that doesn't really make it easier when unzipping reports a CRC 
>> error on Module-Build's Base.pm file.  With either of two unzip tools. 
>> And either of two download tools.
> 
> 
> Sorry, this just isn't my week. Can you please try again; I think I 
> tranfered it in ascii mode the first time...

The decompress and build and install all worked lots better this time.

Now to try building my GFfP module...

Yes, that seems to work too.  Hurray!

As expected, though, the paths are not visible.


Now what about the organization of my module?

I misspoke when I mentioned needing to put my .pm file in blib manually, 
it is required to be in lib, which is much less likely to get deleted.

But why do I get errors during "perl build.pl" telling me that the files 
built by the build step are not present at the "perl build.pl" step?  As 
far as I can determine, they shouldn't be.  A similar warning for 
META.yml and README showed up when I did "perl build.pl" for the 
Module-Build.zip above.  Such warnings do not engender confidence in the 
module, or in the M::B process.

But at least it works now, it is much more fun to talk about the 
"little" problems when the basic functionality works!

I'm assuming that for distribution for PPM users, that I will never need 
to use  "perl build dist"... so the "differing content" in the .tar.gz 
file build by "dist" vs "ppm_dist" won't annoy me... but will it annoy 
others, that want to do both types of distributions?

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [Module::Build] [PATCH] ppm_dist action

[Randy W. S. <Ra...@Th...>]

On 1/14/2004 1:12 AM, Glenn Linderman wrote:

> On approximately 1/13/2004 8:50 PM, came the following characters from
> the keyboard of Randy W. Sims:
> 
>> To make it easier, I've put a snapshot of the current CVS + this patch 
>> at <http://www.thepierianspring.org/Module-Build.zip>.
> 
> 
> Well, that doesn't really make it easier when unzipping reports a CRC 
> error on Module-Build's Base.pm file.  With either of two unzip tools. 
> And either of two download tools.

Sorry, this just isn't my week. Can you please try again; I think I 
tranfered it in ascii mode the first time...

Regards,
Randy.

Re: [Module::Build] [PATCH] ppm_dist action

[Glenn L. <pe...@ne...>]

On approximately 1/13/2004 8:50 PM, came the following characters from
the keyboard of Randy W. Sims:
> On 1/13/2004 11:31 PM, Glenn Linderman wrote:
> 
>> On approximately 1/13/2004 6:46 PM, came the following characters from
>> the keyboard of Randy W. Sims:
>>
>>>> * For backwards compatibility (not really sure it's neccessary at 
>>>> this point, but...) I'd suggest leaving the 'ppd' action as is, and 
>>>> create a new 'ppm_dist' action that runs the 'ppd' action and 
>>>> creates an archive of the blib directory, running the 'build' action 
>>>> if neccessary. Ken? 
>>>
>>>
>>>
>>>
>>> Attached is a patch that adds a new 'ppm_dist' action. It accepts a 
>>> 'codebase' argument just like the 'ppd' action. This action runs the 
>>> 'ppd' action and then builds an archive of the blib directory. Glenn, 
>>> this should allow you to "install on the same machine it is built 
>>> on". The 'ppd' action remains unchanged. Please let me know if this 
>>> patch is correct.
>>
>>
>>
>> Perhaps it is correct, but I can't apply it to whatever version of 
>> Base.pm I have... which claims to be 0.21_02
> 
> 
> To make it easier, I've put a snapshot of the current CVS + this patch 
> at <http://www.thepierianspring.org/Module-Build.zip>.

Well, that doesn't really make it easier when unzipping reports a CRC 
error on Module-Build's Base.pm file.  With either of two unzip tools. 
And either of two download tools.

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.