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

Re: [Module::Build] codebase? paths in .tar.gz?

[Jos I. B. <ka...@dw...>]

On Sun, 21 Dec 2003, Randy W. Sims wrote:
> Actually this problem is occuring in recent versions of Archive::Tar; In
> fact, it happens with a post 1.07 snapshot Andrew referred me to a while
> back when we were having other problems (warnings when directories are
> added to the tar). If Ken can confirm that he used 'perl Build dist' to
> create the 'Module-Build-0.21_01.tar.gz' dist currently on CPAN and that
> he used a recent version of Archive::Tar, I think that will narrow down
> the problem to something in the way tar files are created on Windows as
> opposed to other OSs. When I look at that dist in WinZip (one of the
> common programs on windows used to handle tar files), the directory
> structure is there. When I untar that dist and run 'perl Build dist' in
> it, the tar file created on Windows does not show the directory
> structure (although it is there as confirmed by some ported versions of
> gnu tar). So, the problem seems to be in the creation process on Windows...

hmm, well it would be good if you could make a small test case on win32
that demonstrates this problem (one file, one dir kind of thing), so i can
investigate the tar file and see what goes wrong...

Re: [Module::Build] Module-Build-0.21 on OS/2

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

On 12/20/2003 3:17 PM, Ken Williams wrote:

> 
> On Saturday, December 20, 2003, at 10:40  AM, Randy W. Sims wrote:
> 
>>
>> I'm actually quite eager to dig into CBuilder, but it seems like 
>> everytime I get ready to something comes up. Fixing the Windows code 
>> should be trivial.
> 
> Ooh, I was hoping you'd say that. =)  It probably wouldn't be trivial 
> for me, because I'd have to start understanding how it works.
> 
> In fact, if you're interested, I'd be happy to hand the CBuilder code 
> over to you as official maintainer/owner.  Just let me know.

It's so much more fun when you're not maintainer; You still get to write 
code. You get to annoy the maintainer with patches, bug reports, feature 
requests, etc. Any you get none of the aforesaid annoyances. ;-)

Actually, I'd be happy to help out in any way I can, whether as 
maintainer, co-maintainer, or as an annoyance.

>> I've got a lot of the scaffolding already written for doing static 
>> builds; I don't think it'll take much to complete it. The code for 
>> building executables should also be trivial. I just gotta find some 
>> time...
> 
> 
> Yeah, it's only recently that I've understood that doing static builds 
> is necessary.
> 
> I think that your synopsis a couple weeks ago of the various issues 
> related to CBuilder was good.  Some of them (like building executables, 
> for example) can easily wait until later versions, though - for now we 
> can just focus on doing the stuff that tools like M::B will need to 
> build XS modules.

I completely agree. For the foreseeable future all development on 
CBuilder should be driven by the requirements of M::B. The top priority 
being to get CBuilder to do what is currently handled internally by 
M::B. Then it can be extended to handle static builds, more platforms, 
etc. as needed.

Regards,
Randy.

Re: [Module::Build] Module-Build-0.21 on OS/2

[Ilya Z. <nos...@il...>]

On Sat, Dec 20, 2003 at 09:35:10AM -0500, Randy W. Sims wrote:
> If the link_c() sub is not correct, it would be best to remove it from 
> the patch. Doesn't OS/2 perl use static linking for perl modules?

On OS/2 Perl is built in many flavors.  The main one uses DynaLoading.
One of the others is statically built.  With statically build one, the
supplied link_c() may be working (have no time to test this).

> Can you provide a dump of your Config.pm to help porting?

All the flavors use the same Config.pm (they switch the values basing
on configuration variables/functions available via OS2:: namespace).
So be prepared that the same Config.pm may provide radically different
answers.  ;-)

Yours,
Ilya

Re: [Module::Build] codebase? paths in .tar.gz?

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

On 12/20/2003 5:23 PM, Jos I. Boumans wrote:
> 
> On Sat, 20 Dec 2003, Ken Williams wrote:
> 
>>On Saturday, December 20, 2003, at 12:17  PM, Randy W. Sims wrote:
>>
>>>Well this atleast proves that the paths are there, thus it is not a
>>>problem with M::B, but I think this is going to be a big issue for
>>>Windows users. I think if it's possible for Archive::Tar to be better
>>>compatible with other tools, it should. If I knew anything about the
>>>tar  format, I'd try to provide a patch. Since I don't, I'll just cc
>>>the maintainer. ;-)
>>
>>I have some kind of vague recollection that maybe this issue in
>>Archive::Tar has been fixed privately by Kane and is just waiting for
>>him to release it.
>>
>>Kane, can you put Glenn out of his misery?  Or am I remembering wrong?
> 
> 
> well, even though m::b may use A::T to build an archive, and ppm uses it
> to extract, it may not be the same A::T -- AS perl ships with a very old
> version of A::T which does not support the full tar standard (including
> the prefix header). Several people have already advised AS to upgrade A::T
> to a recent version, that works on win32 and actually supports most of the
> spec...
> 
> the easiest fix would be to require the client to have a::t > 1.00 to make
> sure this doesn't happen, but i'm not sure how to enforce this...

Hi Jos,

Actually this problem is occuring in recent versions of Archive::Tar; In 
fact, it happens with a post 1.07 snapshot Andrew referred me to a while 
back when we were having other problems (warnings when directories are 
added to the tar). If Ken can confirm that he used 'perl Build dist' to 
create the 'Module-Build-0.21_01.tar.gz' dist currently on CPAN and that 
he used a recent version of Archive::Tar, I think that will narrow down 
the problem to something in the way tar files are created on Windows as 
opposed to other OSs. When I look at that dist in WinZip (one of the 
common programs on windows used to handle tar files), the directory 
structure is there. When I untar that dist and run 'perl Build dist' in 
it, the tar file created on Windows does not show the directory 
structure (although it is there as confirmed by some ported versions of 
gnu tar). So, the problem seems to be in the creation process on Windows...

Regards,
Randy.

Re: [Module::Build] codebase? paths in .tar.gz?

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

On approximately 12/20/2003 2:23 PM, came the following characters from
the keyboard of Jos I. Boumans:
> 
> On Sat, 20 Dec 2003, Ken Williams wrote:
> 
>>On Saturday, December 20, 2003, at 12:17  PM, Randy W. Sims wrote:
>>
>>>Well this atleast proves that the paths are there, thus it is not a
>>>problem with M::B, but I think this is going to be a big issue for
>>>Windows users. I think if it's possible for Archive::Tar to be better
>>>compatible with other tools, it should. If I knew anything about the
>>>tar  format, I'd try to provide a patch. Since I don't, I'll just cc
>>>the maintainer. ;-)
>>
>>I have some kind of vague recollection that maybe this issue in
>>Archive::Tar has been fixed privately by Kane and is just waiting for
>>him to release it.
>>
>>Kane, can you put Glenn out of his misery?  Or am I remembering wrong?
> 
> 
> well, even though m::b may use A::T to build an archive, and ppm uses it
> to extract, it may not be the same A::T -- AS perl ships with a very old
> version of A::T which does not support the full tar standard (including
> the prefix header). Several people have already advised AS to upgrade A::T
> to a recent version, that works on win32 and actually supports most of the
> spec...
> 
> the easiest fix would be to require the client to have a::t > 1.00 to make
> sure this doesn't happen, but i'm not sure how to enforce this...

Well, I had to upgrade Archive::Tar to get Module::Build to work.  Can 
ppm still use an older version after I've installed a new one?

C:\Documents and Settings\Glenn>ppm
PPM - Programmer's Package Manager version 3.0.1.
Copyright (c) 2001 ActiveState SRL. All Rights Reserved.

Entering interactive shell. Using Term::ReadLine::Stub as readline library.

Profile tracking is not enabled. If you save and restore profiles manually,
your profile may be out of sync with your computer. See 'help profile' for
more information.

Type 'help' to get started.

ppm> query Archive
Querying target 1 (ActivePerl 5.8.0.805)
   1. Archive-Tar  [1.07] Manipulates TAR archives
   2. Archive-Zip  [1.06] Provide an interface to ZIP archive files.
ppm> exit

-- 
Glenn -- http://nevcal.com/
===========================
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick.  It's ridiculous.
-- Bill Gates

And here is why it is ridiculous:
  The division that includes Windows posted an operating profit of $2.26 
  billion on revenue of $2.81 billion.
  --from Reuters via 
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html

So that's profit of over 400% of investment... with a bit more 
investment in Windows technology, particularly in the area of 
reliability, the profit percentage might go down, but so might the bugs 
and security problems?  Seems like it would be a reasonable tradeoff. 
WalMart earnings are 3.4% of investment.

Re: [Module::Build] codebase? paths in .tar.gz?

[Jos I. B. <ka...@dw...>]

On Sat, 20 Dec 2003, Ken Williams wrote:
> On Saturday, December 20, 2003, at 12:17  PM, Randy W. Sims wrote:
> >
> > Well this atleast proves that the paths are there, thus it is not a
> > problem with M::B, but I think this is going to be a big issue for
> > Windows users. I think if it's possible for Archive::Tar to be better
> > compatible with other tools, it should. If I knew anything about the
> > tar  format, I'd try to provide a patch. Since I don't, I'll just cc
> > the maintainer. ;-)
>
> I have some kind of vague recollection that maybe this issue in
> Archive::Tar has been fixed privately by Kane and is just waiting for
> him to release it.
>
> Kane, can you put Glenn out of his misery?  Or am I remembering wrong?

well, even though m::b may use A::T to build an archive, and ppm uses it
to extract, it may not be the same A::T -- AS perl ships with a very old
version of A::T which does not support the full tar standard (including
the prefix header). Several people have already advised AS to upgrade A::T
to a recent version, that works on win32 and actually supports most of the
spec...

the easiest fix would be to require the client to have a::t > 1.00 to make
sure this doesn't happen, but i'm not sure how to enforce this...

-jos

Re: [Module::Build] codebase? paths in .tar.gz?

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

On Saturday, December 20, 2003, at 12:17  PM, Randy W. Sims wrote:
>
> Well this atleast proves that the paths are there, thus it is not a 
> problem with M::B, but I think this is going to be a big issue for 
> Windows users. I think if it's possible for Archive::Tar to be better 
> compatible with other tools, it should. If I knew anything about the 
> tar  format, I'd try to provide a patch. Since I don't, I'll just cc 
> the maintainer. ;-)

I have some kind of vague recollection that maybe this issue in 
Archive::Tar has been fixed privately by Kane and is just waiting for 
him to release it.

Kane, can you put Glenn out of his misery?  Or am I remembering wrong?

  -Ken

Re: [Module::Build] Module-Build-0.21 on OS/2

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

On Saturday, December 20, 2003, at 10:40  AM, Randy W. Sims wrote:
>
> I'm actually quite eager to dig into CBuilder, but it seems like 
> everytime I get ready to something comes up. Fixing the Windows code 
> should be trivial.

Ooh, I was hoping you'd say that. =)  It probably wouldn't be trivial 
for me, because I'd have to start understanding how it works.

In fact, if you're interested, I'd be happy to hand the CBuilder code 
over to you as official maintainer/owner.  Just let me know.

> I've got a lot of the scaffolding already written for doing static 
> builds; I don't think it'll take much to complete it. The code for 
> building executables should also be trivial. I just gotta find some 
> time...

Yeah, it's only recently that I've understood that doing static builds 
is necessary.

I think that your synopsis a couple weeks ago of the various issues 
related to CBuilder was good.  Some of them (like building executables, 
for example) can easily wait until later versions, though - for now we 
can just focus on doing the stuff that tools like M::B will need to 
build XS modules.

  -Ken

Re: [Module::Build] codebase? paths in .tar.gz?

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

On Saturday, December 20, 2003, at 10:49  AM, Randy W. Sims wrote:

> On 12/20/2003 11:23 AM, Ken Williams wrote:
>
>> Hi,
>> I applied the documentation part of the patch, but I had already 
>> patched the other stuff in a different way by the time I saw this.  
>> Is it not good to simply die() when there's no version, abstract, or 
>> author?  Seems like those should be required.
>
> I wavered a bit when working on the patch. I definately think that a 
> PPD file should not be released without all of the above information. 
> I guess the only concern I have is if a module does something abnormal 
> like putting the pod in a separate pod file, so that M::B doesn't find 
> the abstract; at least the author could manually fix the PPD file. 
> But, maybe it should just die, and if anyone runs into anything 
> reasonably abnormal we can make the appropriate change.

Currently it looks for the abstract & author in the same place as the 
version.  If that's not proper, the author can actually just add a 
'dist_abstract' and/or 'dist_author' parameter to the Build->new() 
method too.

  -Ken

Re: [Module::Build] codebase? paths in .tar.gz?

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

On 12/20/2003 12:10 PM, Glenn Linderman wrote:

> So that is good, I guess, even if it means that all the tar programs in 
> the world are broken except GNU tar 1.13, and A::T.  (One cannot help 
> but wonder instead if GNU tar 1.13 and A::T are the ones that are broken.)

Well this atleast proves that the paths are there, thus it is not a 
problem with M::B, but I think this is going to be a big issue for 
Windows users. I think if it's possible for Archive::Tar to be better 
compatible with other tools, it should. If I knew anything about the tar 
  format, I'd try to provide a patch. Since I don't, I'll just cc the 
maintainer. ;-)

> Unfortunately, there still seems to be one major outstanding problem: 
> installing my module using PPD does not cause my files to be copied into 
> the c:\perl directory tree.
[...]

> Now I suppose, since this is my first module, that I could have left out 
> something.  But somehow, "perl build install" figured out how to install 
> the module successfully (albeit, it doesn't create the two files above, 
> which seems to be a PPM record of configuration, so that is probably 
> correct).  However, using the same environment, and creating the "perl 
> build dist" and "perl build ppd" (with a hand edit to the PPD for 
> version-checking... oh, should that have been in the patch?  That's 
> another unresolved issue, I think), followed by "PPM install", does not 
> place the files where they belong.  So if there is something missing, I 
> guess that Cookbook needs some more help.  Or if it is some other 
> reason, perhaps M::B should be improved to deal with it?

No, you haven't missed anything. It should work. I suspect the problem 
is related to the problem with the tar format. I don't understand though 
why. Module::Build uses Archive::Tar to create the dist. ppm uses 
Archive::Tar to unpack it. I hate ppm, but I guess I'll see if I can 
trace though and see what the problem is.

Randy.

Re: [Module::Build] codebase? paths in .tar.gz?

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

On 12/20/2003 12:17 PM, Glenn Linderman wrote:
> I'm no expert in the required contents of a .ppd file.  But I can't 
> imagine ever wanting one that doesn't have a version.  While it is nice 
> to also have the author and abstract, I can't see that having them or 
> not having them makes the module more or less functional.

Those fields are not required for a PPD file. It's been a long time 
since I've used ppm, but I recall seeing more than a few without 
abstracts and other info. But, I think it is more than reasonable to 
require this information. Browsing thruough several screens of module 
names (many of which are unhelpfully named to say the least) trying to 
figure out what each module does is a pain and a waste of time. An 
author name should also be required in case there are problems with the 
module or the distribution. Name and version are obvious requirements. 
Besides even if it was decided to not require this info for the PPD, it 
would still need to be required for the META.yml files, thus the info 
would be there anyway. :-)

Regards,
Randy.

Re: [Module::Build] codebase? paths in .tar.gz?

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

I'm no expert in the required contents of a .ppd file.  But I can't 
imagine ever wanting one that doesn't have a version.  While it is nice 
to also have the author and abstract, I can't see that having them or 
not having them makes the module more or less functional.

On approximately 12/20/2003 8:23 AM, came the following characters from
the keyboard of Ken Williams:

> Hi,
> 
> I applied the documentation part of the patch, but I had already patched 
> the other stuff in a different way by the time I saw this.  Is it not 
> good to simply die() when there's no version, abstract, or author?  
> Seems like those should be required.
> 
>  -Ken
> 
> 
> On Saturday, December 20, 2003, at 04:41  AM, Randy W. Sims wrote:
> 
>>
>> This patch:
>>
>> * Moves documentation for the C<codebase> parameter to the section
>> describing the ppd action.
>>
>> * Set C<codebase> to default to the distribution name with a '.tar.gz'
>> extension. Notify user if the default is used.
>>
>> * Warn user to edit the produced PPD file if we can't determine values
>> for name, version, and abstract.
>>
>>
>> I will leave writing tutorials to someone with more literary talent than
>> I :-)
>>
>> Regards,
>> Randy.
>>
>>
>> diff -urN Module-Build-orig/lib/Module/Build/PPMMaker.pm 
>> Module-Build/lib/Module/Build/PPMMaker.pm
>> --- Module-Build-orig/lib/Module/Build/PPMMaker.pm    2003-07-25 
>> 10:15:19.000000000 -0400
>> +++ Module-Build/lib/Module/Build/PPMMaker.pm    2003-12-20 
>> 04:56:36.000000000 -0500
>> @@ -15,14 +15,23 @@
>>    my ($self, %args) = @_;
>>    my $build = delete $args{build};
>>
>> -  die "Cannot create a PPD file unless codebase argument is given\n"
>> -    unless exists $args{codebase};
>> -  my @codebase = ref $args{codebase} ? @{$args{codebase}} : 
>> ($args{codebase});
>> +  my $name         = $build->dist_name     || '';
>> +  my $author       = $build->dist_author   || '';
>> +  my $abstract     = $build->dist_abstract || '';
>> +  my $version      = $self->_ppd_version($build->dist_version) || '';
>> +
>> +  die "Cannot determine distribution name.\n" unless length($name);
>> +
>> +  warn "Missing information for PPD. Please edit before distributing.\n"
>> +    unless length($author) && length($abstract) && length($version);
>> +
>> +  unless (exists $args{codebase}) {
>> +    my $codebase = $build->dist_dir . '.tar.gz';
>> +    $args{codebase} = $codebase;
>> +    print "Using a default CODEBASE of '$codebase'\n";
>> +  }
>>
>> -  my $name         = $build->dist_name;
>> -  my $author       = $build->dist_author;
>> -  my $abstract     = $build->dist_abstract;
>> -  my $version      = $self->_ppd_version($build->dist_version);
>> +  my @codebase = ref $args{codebase} ? @{$args{codebase}} : 
>> ($args{codebase});
>>
>>    $self->_simple_xml_escape($_) foreach ($abstract, $author);
>>
>> diff -urN Module-Build-orig/lib/Module/Build.pm 
>> Module-Build/lib/Module/Build.pm
>> --- Module-Build-orig/lib/Module/Build.pm    2003-12-09 
>> 21:36:45.000000000 -0500
>> +++ Module-Build/lib/Module/Build.pm    2003-12-20 04:35:23.000000000 
>> -0500
>> @@ -575,13 +575,6 @@
>>  version.  It looks for the first line matching C<$package\s-\s(.+)>,
>>  and uses the captured text as the abstract.
>>
>> -=item codebase
>> -
>> -This can be either a single scalar string, or an array reference of
>> -strings.  It is required when creating PPD files.  It should be a URL,
>> -or URLs, to be used as the value for the C<< <CODEBASE> >> tag in the
>> -generated PPD.
>> -
>>  =back
>>
>>  =item subclass()
>> @@ -1212,6 +1205,15 @@
>>
>>  Build a PPD file for your distribution.
>>
>> +This action takes an optional argument C<codebase> which is used in
>> +the generated ppd file to specify the (usually relative) URL of the
>> +distribution. By default, this value is the distribution name without
>> +any path information.
>> +
>> +Example:
>> +
>> + perl Build ppd 
>> codebase="MSWin32-x86-multi-thread/Module-Build-0.21.tar.gz"
>> +
>>  =back
>>
>>  =head2 How Installation Paths are Determined
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general
> 
> 

-- 
Glenn -- http://nevcal.com/
===========================
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick.  It's ridiculous.
-- Bill Gates

And here is why it is ridiculous:
  The division that includes Windows posted an operating profit of $2.26 
  billion on revenue of $2.81 billion.
  --from Reuters via 
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html

So that's profit of over 400% of investment... with a bit more 
investment in Windows technology, particularly in the area of 
reliability, the profit percentage might go down, but so might the bugs 
and security problems?  Seems like it would be a reasonable tradeoff. 
WalMart earnings are 3.4% of investment.

Re: [Module::Build] codebase? paths in .tar.gz?

[Dave R. <au...@ur...>]

On Sat, 20 Dec 2003, Randy W. Sims wrote:

> I wavered a bit when working on the patch. I definately think that a PPD
> file should not be released without all of the above information. I
> guess the only concern I have is if a module does something abnormal
> like putting the pod in a separate pod file, so that M::B doesn't find
> the abstract; at least the author could manually fix the PPD file. But,
> maybe it should just die, and if anyone runs into anything reasonably
> abnormal we can make the appropriate change.

I think it would be better to die and then add code to accomodate this.

For example, we could do something like add a "ppd_info_file" constructor
argument so that M::B would like there for the abstract & author info.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Re: [Module::Build] codebase? paths in .tar.gz?

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

On approximately 12/20/2003 12:17 AM, came the following characters from
the keyboard of Randy W. Sims:

> On 12/19/2003 6:19 PM, Randy W. Sims wrote:
> 
>> You can extract ptar from an older version of Archive::Tar 
>> <http://search.cpan.org/dist/Archive-Tar-0.23/>, or get a version of 
>> tar for windows that I know to be working at 
>> <http://unxutils.sourceforge.net/>, or you can email me (off list) the 
>> file and I'll take a look at it.
> 
> 
> I made a mistake. The tar on the computer I was using was broke as is 
> the one at the url above. I'm sending you the same working tar (and 
> support files) I sent Ron as well as ptar. Please try them and let me 
> know. I used them on the file you sent and it does work here.

Well, I tried ptar first.  In the below, teh sequence of characters "^@" 
represent a true NULL character, which won't paste into the email.  So 
it seems like the old ptar isn't particularly compatible with something 
or another.  It sounded like it might have a nice feature of reading the 
compressed version of the archive directly, but I guess that doesn't 
work either.

D:\>\downloads\ptar tvzf GFfP-0.1.tar.gz
\downloads\ptar tvzf GFfP-0.1.tar.gz
Read error on tarfile 'GFfP-0.1/build.pl' at \downloads\ptar.bat line 67

D:\>\downloads\ptar tvf GFfP-0.1.tar
\downloads\ptar tvf GFfP-0.1.tar
: checksum error at \downloads\ptar.bat line 67
Couldn't read chunk '	This list of files
META.yml                        no clue, but Module::Build wants it
build.pl                        Module::Build facility
blib/lib/GFfP.pm                The main module (but no brains)
blib/arch/auto/GFfP/GFfP.bs     no clue
blib/arch/auto/GFfP/GFfP.dll    The brains for the module
blib/arch/auto/GFfP/GFfP.exp    related to the .dll somehow
blib/arch/auto/GFfP/GFfP.lib    related to the .dll somehow
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@META.yml^@^@^@^@^@^@^@^@^@^@' 
at \downloads\ptar.bat line 67
: checksum error at \downloads\ptar.bat line 67
: GFfP
version: 0.1
license: restrictive
distribution_type: module
requires:
   perl: 5.8.0
recommend: checksum error at \downloads\ptar.bat line 67
: checksum error at \downloads\ptar.bat line 67
############################################################
package GFfP;

use strict;
use warnings;

require DynaLoader;

our $VERSION = '0.1';

our @ISA/#################################################
#
# GFfP - Glenn's Forth for Perl
#
# 2003/12/18 b: checksum error at \downloads\ptar.bat line 67
Couldn't read chunk 'oader );

bootstrap GFfP $VERSION;

###############################################################################
# PUBLIC METHODS
# (@)PACKAGE:GFfP

###########################################################################
# (@)METHOD:Version()
# Returns the module version number.

sub Version
{ return $VERSION;
}

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@GFfP.bs^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@' 
at \downloads\ptar.bat line 67
: checksum error at \downloads\ptar.bat line 67
: checksum error at \downloads\ptar.bat line 67
: checksum error at \downloads\ptar.bat line 67
: checksum error at \downloads\ptar.bat line 67
GFfP-0.1/build.pl

D:\>


So then I tried an old version of GNU tar I must have downloaded at some 
point...

D:\>bin\tar --version
bin\tar --version
tar (GNU tar) 1.12

Copyright (C) 1988, 92, 93, 94, 95, 96, 97 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Written by John Gilmore and Jay Fenlason.

D:\>bin\tar tvf GFfP-0.1.tar
bin\tar tvf GFfP-0.1.tar
-rw-rw-rw- unknown/unknown 267 2003-12-18 22:00 build.pl
-rw-rw-rw- unknown/unknown 443 2003-12-19 00:15 MANIFEST
-rw-rw-rw- unknown/unknown 226 2003-12-19 15:30 META.yml
-rw-rw-rw- unknown/unknown 902 2003-12-18 22:29 GFfP.pm
-rw-rw-rw- unknown/unknown   0 2003-12-19 00:41 GFfP.bs
-rw-rw-rw- unknown/unknown 24629 2003-12-19 00:41 GFfP.dll
-rw-rw-rw- unknown/unknown   739 2003-12-19 00:41 GFfP.exp
-rw-rw-rw- unknown/unknown  2074 2003-12-19 00:41 GFfP.lib

D:\>


So then I tried the tar you sent, which turns out to be one version 
newer of GNU tar:

D:\>bin\tar --version
bin\tar --version
tar (GNU tar) 1.13

Copyright (C) 1988, 92,93,94,95,96,97,98, 1999 Free Software Foundation, 
Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Written by John Gilmore and Jay Fenlason.

D:\>bin\tar tvf GFfP-0.1.tar
bin\tar tvf GFfP-0.1.tar
-rw-rw-rw- unknown/unknown 267 2003-12-18 22:00 GFfP-0.1/build.pl
-rw-rw-rw- unknown/unknown 443 2003-12-19 00:15 GFfP-0.1/MANIFEST
-rw-rw-rw- unknown/unknown 226 2003-12-19 15:30 GFfP-0.1/META.yml
-rw-rw-rw- unknown/unknown 902 2003-12-18 22:29 GFfP-0.1/blib/lib/GFfP.pm
-rw-rw-rw- unknown/unknown   0 2003-12-19 00:41 
GFfP-0.1/blib/arch/auto/GFfP/GFfP.bs
-rw-rw-rw- unknown/unknown 24629 2003-12-19 00:41 
GFfP-0.1/blib/arch/auto/GFfP/GFfP.dll
-rw-rw-rw- unknown/unknown   739 2003-12-19 00:41 
GFfP-0.1/blib/arch/auto/GFfP/GFfP.exp
-rw-rw-rw- unknown/unknown  2074 2003-12-19 00:41 
GFfP-0.1/blib/arch/auto/GFfP/GFfP.lib

D:\>

And indeed, for the first time, I see path names produced from my .tar file.

So that is good, I guess, even if it means that all the tar programs in 
the world are broken except GNU tar 1.13, and A::T.  (One cannot help 
but wonder instead if GNU tar 1.13 and A::T are the ones that are broken.)


And the patch you submitted looks good on the surface, it sounds like 
improvements to several rough edges I've reported in M::B.

I look forward to see a snapshot version I can install containing those 
fixes, so I can try again.

Unfortunately, there still seems to be one major outstanding problem: 
installing my module using PPD does not cause my files to be copied into 
the c:\perl directory tree.

D:\>ppm install d:\GFfP\GFfP.ppd
ppm install d:\GFfP\GFfP.ppd
====================
Install 'GFfP' version 0.1 in ActivePerl 5.8.0.805.
====================
Successfully installed GFfP version 0.1 in ActivePerl 5.8.0.805.

D:\>c:
c:

C:\Perl>dir GFfP* /s
dir GFfP* /s
  Volume in drive C has no label.
  Volume Serial Number is 9875-3276

  Directory of C:\Perl\site\lib\ppm-conf

12/20/2003  09:04a                 126 GFfP.pkg
12/20/2003  09:04a                 351 GFfP.ppd
                2 File(s)            477 bytes

      Total Files Listed:
                2 File(s)            477 bytes
                0 Dir(s)  24,073,785,344 bytes free

Now I suppose, since this is my first module, that I could have left out 
something.  But somehow, "perl build install" figured out how to install 
the module successfully (albeit, it doesn't create the two files above, 
which seems to be a PPM record of configuration, so that is probably 
correct).  However, using the same environment, and creating the "perl 
build dist" and "perl build ppd" (with a hand edit to the PPD for 
version-checking... oh, should that have been in the patch?  That's 
another unresolved issue, I think), followed by "PPM install", does not 
place the files where they belong.  So if there is something missing, I 
guess that Cookbook needs some more help.  Or if it is some other 
reason, perhaps M::B should be improved to deal with it?

> Thanks,
> Randy.
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general
> 
> 

-- 
Glenn -- http://nevcal.com/
===========================
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick.  It's ridiculous.
-- Bill Gates

And here is why it is ridiculous:
  The division that includes Windows posted an operating profit of $2.26 
  billion on revenue of $2.81 billion.
  --from Reuters via 
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html

So that's profit of over 400% of investment... with a bit more 
investment in Windows technology, particularly in the area of 
reliability, the profit percentage might go down, but so might the bugs 
and security problems?  Seems like it would be a reasonable tradeoff. 
WalMart earnings are 3.4% of investment.

Re: [Module::Build] codebase? paths in .tar.gz?

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

On 12/20/2003 11:23 AM, Ken Williams wrote:

> Hi,
> 
> I applied the documentation part of the patch, but I had already patched 
> the other stuff in a different way by the time I saw this.  Is it not 
> good to simply die() when there's no version, abstract, or author?  
> Seems like those should be required.

I wavered a bit when working on the patch. I definately think that a PPD 
file should not be released without all of the above information. I 
guess the only concern I have is if a module does something abnormal 
like putting the pod in a separate pod file, so that M::B doesn't find 
the abstract; at least the author could manually fix the PPD file. But, 
maybe it should just die, and if anyone runs into anything reasonably 
abnormal we can make the appropriate change.

Randy.

Re: [Module::Build] Module-Build-0.21 on OS/2

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

On 12/20/2003 11:11 AM, Ken Williams wrote:
> 
> On Saturday, December 20, 2003, at 08:43  AM, Randy W. Sims wrote:
> 
>> On 12/18/2003 8:41 PM, Ilya Zakharevich wrote:
>>
>>> This patch is very incomplete...  All it does is copying of cygwin 
>>> architecture
>>> file as os2 architecture file.
>>> Given that Module::Build removed all the portability hooks of 
>>> MakeMaker, it
>>> will take a lot of effort to make Module::Build compile XS extensions 
>>> on OS/2.
>>> However, with the manpage_separator() of cygwin, at least the build of
>>> pure-Perl extensions kinda-succeeds.
>>
>>
>> Ken, until compiling does work you might want to put in a stub for 
>> have_c_compiler() to return false to avoid errors.
> 
> 
> Done.
> 
> It would be great if we could actually get this working in 
> ExtUtils::CBuilder, and then switch over so that M::B uses it.
> 
>  -Ken
> 

I'm actually quite eager to dig into CBuilder, but it seems like 
everytime I get ready to something comes up. Fixing the Windows code 
should be trivial. I've got a lot of the scaffolding already written for 
doing static builds; I don't think it'll take much to complete it. The 
code for building executables should also be trivial. I just gotta find 
some time...

Randy.

Re: [Module::Build] codebase? paths in .tar.gz?

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

Hi,

I applied the documentation part of the patch, but I had already 
patched the other stuff in a different way by the time I saw this.  Is 
it not good to simply die() when there's no version, abstract, or 
author?  Seems like those should be required.

  -Ken


On Saturday, December 20, 2003, at 04:41  AM, Randy W. Sims wrote:

>
> This patch:
>
> * Moves documentation for the C<codebase> parameter to the section
> describing the ppd action.
>
> * Set C<codebase> to default to the distribution name with a '.tar.gz'
> extension. Notify user if the default is used.
>
> * Warn user to edit the produced PPD file if we can't determine values
> for name, version, and abstract.
>
>
> I will leave writing tutorials to someone with more literary talent 
> than
> I :-)
>
> Regards,
> Randy.
>
>
> diff -urN Module-Build-orig/lib/Module/Build/PPMMaker.pm 
> Module-Build/lib/Module/Build/PPMMaker.pm
> --- Module-Build-orig/lib/Module/Build/PPMMaker.pm	2003-07-25 
> 10:15:19.000000000 -0400
> +++ Module-Build/lib/Module/Build/PPMMaker.pm	2003-12-20 
> 04:56:36.000000000 -0500
> @@ -15,14 +15,23 @@
>    my ($self, %args) = @_;
>    my $build = delete $args{build};
>
> -  die "Cannot create a PPD file unless codebase argument is given\n"
> -    unless exists $args{codebase};
> -  my @codebase = ref $args{codebase} ? @{$args{codebase}} : 
> ($args{codebase});
> +  my $name         = $build->dist_name     || '';
> +  my $author       = $build->dist_author   || '';
> +  my $abstract     = $build->dist_abstract || '';
> +  my $version      = $self->_ppd_version($build->dist_version) || '';
> +
> +  die "Cannot determine distribution name.\n" unless length($name);
> +
> +  warn "Missing information for PPD. Please edit before 
> distributing.\n"
> +    unless length($author) && length($abstract) && length($version);
> +
> +  unless (exists $args{codebase}) {
> +    my $codebase = $build->dist_dir . '.tar.gz';
> +    $args{codebase} = $codebase;
> +    print "Using a default CODEBASE of '$codebase'\n";
> +  }
>
> -  my $name         = $build->dist_name;
> -  my $author       = $build->dist_author;
> -  my $abstract     = $build->dist_abstract;
> -  my $version      = $self->_ppd_version($build->dist_version);
> +  my @codebase = ref $args{codebase} ? @{$args{codebase}} : 
> ($args{codebase});
>
>    $self->_simple_xml_escape($_) foreach ($abstract, $author);
>
> diff -urN Module-Build-orig/lib/Module/Build.pm 
> Module-Build/lib/Module/Build.pm
> --- Module-Build-orig/lib/Module/Build.pm	2003-12-09 
> 21:36:45.000000000 -0500
> +++ Module-Build/lib/Module/Build.pm	2003-12-20 04:35:23.000000000 
> -0500
> @@ -575,13 +575,6 @@
>  version.  It looks for the first line matching C<$package\s-\s(.+)>,
>  and uses the captured text as the abstract.
>
> -=item codebase
> -
> -This can be either a single scalar string, or an array reference of
> -strings.  It is required when creating PPD files.  It should be a URL,
> -or URLs, to be used as the value for the C<< <CODEBASE> >> tag in the
> -generated PPD.
> -
>  =back
>
>  =item subclass()
> @@ -1212,6 +1205,15 @@
>
>  Build a PPD file for your distribution.
>
> +This action takes an optional argument C<codebase> which is used in
> +the generated ppd file to specify the (usually relative) URL of the
> +distribution. By default, this value is the distribution name without
> +any path information.
> +
> +Example:
> +
> + perl Build ppd 
> codebase="MSWin32-x86-multi-thread/Module-Build-0.21.tar.gz"
> +
>  =back
>
>  =head2 How Installation Paths are Determined
>

Re: [Module::Build] [ilya@Math.Berkeley.EDU: Module-CoreList-1.93]

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

On Saturday, December 20, 2003, at 08:21  AM, Randy W. Sims wrote:

> On 12/19/2003 3:16 AM, Richard Clamp wrote:
>
>> Hi, I'm redirecting this to the Module::Build list as the Makefile.PL
>> was auto generated by it.
>> Module::Build version 0.21, with create_makefile_pl => 'passthrough'
>
> Perhaps all autogenerated files should have a comment at the beginning 
> saying it is autogenerated and not to edit it. :-)

Done.

  -Ken

Re: [Module::Build] Module-Build-0.21 on OS/2

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

On Saturday, December 20, 2003, at 08:43  AM, Randy W. Sims wrote:

> On 12/18/2003 8:41 PM, Ilya Zakharevich wrote:
>
>> This patch is very incomplete...  All it does is copying of cygwin 
>> architecture
>> file as os2 architecture file.
>> Given that Module::Build removed all the portability hooks of 
>> MakeMaker, it
>> will take a lot of effort to make Module::Build compile XS extensions 
>> on OS/2.
>> However, with the manpage_separator() of cygwin, at least the build of
>> pure-Perl extensions kinda-succeeds.
>
> Ken, until compiling does work you might want to put in a stub for 
> have_c_compiler() to return false to avoid errors.

Done.

It would be great if we could actually get this working in 
ExtUtils::CBuilder, and then switch over so that M::B uses it.

  -Ken

Re: [Module::Build] codebase? paths in .tar.gz?

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

On Friday, December 19, 2003, at 04:05  AM, Randy W. Sims wrote:
>
> This is happening because M::B didn't find an abstract (this comes 
> from the pod, =head1 NAME section). I'm not sure, but in PPMMaker.pm 
> lines 22-25 I think all of these fields should be required (name, 
> author, abstract, version) and we should die with a usefull message if 
> not found. Ken?

Agreed.

> On 12/19/2003 4:30 AM, Glenn Linderman wrote:
>
>> This produces a pretty nice looking result, real corresponding to 
>> other .ppd files for other modules with similar requirements.  But 
>> apparently there are a couple bugs in the build ppd that produce the 
>> warnings above.
>> And so I'd like to see a "fix" to allow CODEBASE to default to the 
>> name of the .tar.gz file built by "build dist", and then people that 
>> want something more complex can still provide the command line 
>> override, or the build.pl file setting, or whatever.  But the above 
>> type of PPD can be copied from spot to spot, together with keeping 
>> the .tar.gz in the same directory, and works great.
>
> Ok, I agree with this, with the caveat that M::B should print out an 
> informational message saying what it is using a default.

Done.

>> Yeah, they went away like magic, once YAML was installed.  Just more 
>> dependency-itis to deal with.
>
> This still needs some kind of fix. If YAML is not available, M::B 
> should handle it more gracefully...
>

It's possible we could produce the META.yml without using YAML.pm, but 
the META.yml does need to be produced.  At this point it's a real error 
not to have YAML.pm installed.

  -Ken

Re: [Module::Build] [ilya@Math.Berkeley.EDU: Module-CoreList-1.93]

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

Thanks, applied.

  -Ken

On Friday, December 19, 2003, at 02:16  AM, Richard Clamp wrote:

> Hi, I'm redirecting this to the Module::Build list as the Makefile.PL
> was auto generated by it.
>
> Module::Build version 0.21, with create_makefile_pl => 'passthrough'
>
> -- 
> Richard Clamp <ric...@un...>
>
> From: Ilya Zakharevich <il...@Ma...>
> Date: Thu Dec 18, 2003  7:47:23  PM US/Central
> To: ric...@un...
> Subject: Module-CoreList-1.93
>
>
> Thank you for designing this module.  However, I needed some
> modifications to make it build.
>
> The first chunk is cosmetic only; the second one avoids an infinite 
> loop if
> the install of Module::Build fails.
>
> Thanks,
> Ilya
>
> --- ./Makefile.PL-pre	Fri Nov 14 05:55:04 2003
> +++ ./Makefile.PL	Sun Dec 14 17:15:52 2003
> @@ -7,8 +7,7 @@
>  	('  Install Module::Build now from CPAN?', 'y');
>
>        unless ($yn =~ /^y/i) {
> -	warn " *** Cannot install without Module::Build.  Exiting ...\n";
> -	exit 1;
> +	die " *** Cannot install without Module::Build.  Exiting ...\n";
>        }
>
>        require Cwd;
> @@ -19,7 +18,8 @@
>        my $cwd = Cwd::cwd();
>        my $makefile = File::Spec->rel2abs($0);
>
> -      CPAN::Shell->install('Module::Build::Compat');
> +      CPAN::Shell->install('Module::Build::Compat')
> +	or die " *** Cannot install without Module::Build.  Exiting ...\n";
>
>        chdir $cwd or die "Cannot chdir() back to $cwd: $!";
>        exec $^X, $makefile, @ARGV;  # Redo now that we have 
> Module::Build
>
>

Re: [Module::Build] Module-Build-0.21 on OS/2

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

On 12/18/2003 8:41 PM, Ilya Zakharevich wrote:

> This patch is very incomplete...  All it does is copying of cygwin architecture
> file as os2 architecture file.
> 
> Given that Module::Build removed all the portability hooks of MakeMaker, it
> will take a lot of effort to make Module::Build compile XS extensions on OS/2.
> However, with the manpage_separator() of cygwin, at least the build of
> pure-Perl extensions kinda-succeeds.

Ken, until compiling does work you might want to put in a stub for 
have_c_compiler() to return false to avoid errors.

Regards,
Randy.

Re: [Module::Build] Module-Build-0.21 on OS/2

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

On 12/18/2003 8:41 PM, Ilya Zakharevich wrote:

> This patch is very incomplete...  All it does is copying of cygwin architecture
> file as os2 architecture file.
> 
> Given that Module::Build removed all the portability hooks of MakeMaker, it
> will take a lot of effort to make Module::Build compile XS extensions on OS/2.
> However, with the manpage_separator() of cygwin, at least the build of
> pure-Perl extensions kinda-succeeds.

If the link_c() sub is not correct, it would be best to remove it from 
the patch. Doesn't OS/2 perl use static linking for perl modules? Can 
you provide a dump of your Config.pm to help porting?

Thanks,
Randy.

Re: [Module::Build] [ilya@Math.Berkeley.EDU: Module-CoreList-1.93]

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

On 12/19/2003 3:16 AM, Richard Clamp wrote:

> Hi, I'm redirecting this to the Module::Build list as the Makefile.PL
> was auto generated by it.
> 
> Module::Build version 0.21, with create_makefile_pl => 'passthrough'
> 

Perhaps all autogenerated files should have a comment at the beginning 
saying it is autogenerated and not to edit it. :-)

Re: [Module::Build] codebase? paths in .tar.gz?

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

This patch:

* Moves documentation for the C<codebase> parameter to the section
describing the ppd action.

* Set C<codebase> to default to the distribution name with a '.tar.gz'
extension. Notify user if the default is used.

* Warn user to edit the produced PPD file if we can't determine values
for name, version, and abstract.


I will leave writing tutorials to someone with more literary talent than
I :-)

Regards,
Randy.