Thread: [Module::Build] [PATCH] ppm_dist action
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Randy W. S. <Ra...@Th...> - 2004-01-14 02:46:58
Attachments:
Base.diff
|
> * 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. Note that this does not address the problems with archivers being unable to read A::T created archives, but that should not affect this as A::T should be able to read the archives it creates. Regards, Randy. |
|
From: Glenn L. <pe...@ne...> - 2004-01-14 04:31:36
|
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
C:\Perl\site\lib\Module\Build>patch < Base.diff
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- Base.pm.orig 2004-01-10 23:19:59.000000000 -0500
|+++ Base.pm 2004-01-13 21:08:14.000000000 -0500
--------------------------
Patching file Base.pm using Plan A...
print() on unopened filehandle NULL at C:\Perl\bin/patch line 717, <IN>
line 3579.
print() on unopened filehandle NULL at C:\Perl\bin/patch line 723, <IN>
line 3579.
Hunk #1 succeeded at 1454.
Offset: -9
Hunk #2 failed--Couldn't find anywhere to put hunk.
1 out of 2 hunks ignored--saving rejects to Base.pm.rej
done
> Note that this does not address the problems with archivers being unable
> to read A::T created archives, but that should not affect this as A::T
> should be able to read the archives it creates.
Right. That would take A::T changes. In fact, that would take more
A::T changes than we have seen thus far. Of course, I'm not sure I'd
have noticed the problem with the paths produced by A::T if M::B hadn't
had a few rough edges. So for the benefit of all A::T archive creation
users, I'm glad the discussion is happening, and I hope more than
discussion happens.
> Regards,
> Randy.
>
>
> ------------------------------------------------------------------------
>
> --- Base.pm.orig 2004-01-10 23:19:59.000000000 -0500
> +++ Base.pm 2004-01-13 21:08:14.000000000 -0500
> @@ -1463,6 +1463,13 @@
> $self->add_to_cleanup($file);
> }
>
> +sub ACTION_ppm_dist {
> + my ($self) = @_;
> +
> + $self->depends_on('build', 'ppd');
> + $self->make_tarball($self->{properties}{blib}, $self->dist_dir);
> +}
> +
> sub ACTION_dist {
> my ($self) = @_;
>
> @@ -1731,18 +1738,22 @@
> }
>
> sub make_tarball {
> - my ($self, $dir) = @_;
> + my ($self, $dir, $file) = @_;
> + $file ||= $dir;
>
> - print "Creating $dir.tar.gz\n";
> + 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);
> }
> }
>
--
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.
|
|
From: Randy W. S. <Ra...@Th...> - 2004-01-14 04:50:34
|
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>. Randy. |
|
From: Glenn L. <pe...@ne...> - 2004-01-14 06:11:52
|
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. |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-14 07:21:31
|
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. |
|
From: Glenn L. <pe...@ne...> - 2004-01-14 16:09:18
|
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. |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-14 23:39:35
|
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. |
|
From: Randy K. <ra...@th...> - 2004-01-15 02:10:34
|
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 |
|
From: Ken W. <ke...@ma...> - 2004-01-15 02:40:44
|
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 |
|
From: Glenn L. <pe...@ne...> - 2004-01-15 05:00:42
|
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. |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-15 05:58:33
|
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. |
|
From: Ken W. <ke...@ma...> - 2004-01-15 14:13:55
|
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 |
|
From: Ken W. <ke...@ma...> - 2004-01-15 14:10:12
|
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 |
|
From: Glenn L. <pe...@ne...> - 2004-01-20 02:20:17
|
On approximately 1/15/2004 6:10 AM, came the following characters from the keyboard of Ken Williams: > 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. Yep, that's *precisely* what confused me. "a medium like CPAN"... PPM, from 10,000 or so feet, might be considered "a medium like CPAN"... -- 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. |
|
From: Ken W. <ke...@ma...> - 2004-01-15 02:33:29
|
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 |
|
From: Ken W. <ke...@ma...> - 2004-01-15 02:42:25
|
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 |
|
From: Randy K. <ra...@th...> - 2004-01-15 02:56:50
|
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 |
|
From: Ken W. <ke...@ma...> - 2004-01-15 03:07:39
|
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 |
|
From: Ken W. <ke...@ma...> - 2004-01-15 04:18:22
|
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);
}
|
|
From: Randy W. S. <Ra...@Th...> - 2004-01-15 05:19:58
|
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. |
|
From: Ken W. <ke...@ma...> - 2004-01-15 14:12:19
|
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 |
|
From: Glenn L. <pe...@ne...> - 2004-01-15 04:50:27
|
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. |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-15 05:42:20
|
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 @$$ |
Thanks for helping keep SourceForge clean.
X