Thread: [Module::Build] codebase? paths in .tar.gz?
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Glenn L. <pe...@ne...> - 2003-12-19 08:30:12
|
So, having seen some discussion on "the best way to build Perl modules",
and needing to write my very first Perl module (that needs to be
packaged for distribution, and yes, it contains XS code) I decided to
try out Module::Build.
It would be helpful if there were sample build.pl files in the
documentation or with the distribution. Maybe there are, but not in
what was installed by PPM.
Of course there is the "trivial" build.pl file in the documentation, so
I started there, and things went well. Got my module compiled and
linked, and even installed.
"perl build dist" produces errors, and "perl build ppd" produces errors:
D:\GFfP>perl build dist
Deleting META.yml
mkdir GFfP-0.1
mkdir GFfP-0.1/blib
mkdir GFfP-0.1/blib/arch
mkdir GFfP-0.1/blib/arch/auto
mkdir GFfP-0.1/blib/arch/auto/GFfP
mkdir GFfP-0.1/blib/lib
Creating GFfP-0.1.tar.gz
Unable to add file: 'GFfP-0.1' at C:\Perl\site\lib/Module/Build/Base.pm
line 1706
Unable to add file: 'GFfP-0.1/blib' at
C:\Perl\site\lib/Module/Build/Base.pm line 1706
Unable to add file: 'GFfP-0.1/blib/lib' at
C:\Perl\site\lib/Module/Build/Base.pm line 1706
Unable to add file: 'GFfP-0.1/blib/arch' at
C:\Perl\site\lib/Module/Build/Base.pm line 1706
Unable to add file: 'GFfP-0.1/blib/arch/auto' at
C:\Perl\site\lib/Module/Build/Base.pm line 1706
Unable to add file: 'GFfP-0.1/blib/arch/auto/GFfP' at
C:\Perl\site\lib/Module/Build/Base.pm line 1706
Deleting GFfP-0.1
D:\GFfP>perl build ppd
Cannot create a PPD file unless codebase argument is given
Here's my build.pl
use Module::Build;
my $build = Module::Build->new
(
module_name => 'GFfP',
license => 'restrictive',
dist_author => 'Glenn Linderman <pe...@ne...>',
requires => { 'perl' => '5.8.0', },
codebase => '.',
);
$build->create_build_script;
So you can see from the build.pl that I *did* supply a codebase
parameter, at least as far as I could figure out how. I figured to
compare the resulting .ppd file with one from a different module and
tweak the supplied value appropriately, but I get the error that it
isn't supplied, so maybe I am supplying it in the wrong place?
The documentation Module::Build supplies for "codebase" is pretty terse,
and there are no examples of it in the sample Build.pl file.
And all those warnings from perl build dist are for directories... and
indeed, the resulting .tar.gz file has a flat structure... the files are
all there, but their directory structure is not preserved. As a
result, I can't distribute the package.
It'd be nice to have a sample MANIFEST file too, for a sample
project.
Seems to me like the Cookbook should have a trivial, but complete,
example of all the stuff you need to make your own pure perl module, and
another example with all the stuff you need to make your own XS module.
I know that those sorts of examples would have saved me a lot of time
today.
--
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.
|
|
From: Dave R. <au...@ur...> - 2003-12-19 08:36:52
|
On Fri, 19 Dec 2003, Glenn Linderman wrote:
> "perl build dist" produces errors, and "perl build ppd" produces errors:
You probably don't want to build a PPD unless you understand what the
various things that go in a PPD are. I'm not an expert on it, but I did
write the PPD-related code for Module::Build, and from what I can gather
you need to actually understand how it will be used, where it will be
installed from, etc., to make it work.
> Unable to add file: 'GFfP-0.1/blib' at
> C:\Perl\site\lib/Module/Build/Base.pm line 1706
This I'll let Ken answer.
> D:\GFfP>perl build ppd
> Cannot create a PPD file unless codebase argument is given
>
>
> Here's my build.pl
>
> use Module::Build;
> my $build = Module::Build->new
> (
> module_name => 'GFfP',
> license => 'restrictive',
> dist_author => 'Glenn Linderman <pe...@ne...>',
> requires => { 'perl' => '5.8.0', },
> codebase => '.',
> );
> $build->create_build_script;
For some reason I can't recall, I coded it so that codebase can only be
given from the command line via:
./Build ppd codebase=.
However, I'm pretty sure a codebase on "." will not work, but I won't
swear to it.
A patch to make codebase settable via the new() method is probably good
thing, right Ken?
> The documentation Module::Build supplies for "codebase" is pretty terse,
> and there are no examples of it in the sample Build.pl file.
That's cause I don't really understand the PPD stuff too well. I was kind
of hoping some Win32 expert would fill in the the rest.
> And all those warnings from perl build dist are for directories... and
> indeed, the resulting .tar.gz file has a flat structure... the files are
> all there, but their directory structure is not preserved. As a result,
> I can't distribute the package.
I wonder if it's a permissions problem.
> It'd be nice to have a sample MANIFEST file too, for a sample
> project.
./Build manifest
> Seems to me like the Cookbook should have a trivial, but complete,
> example of all the stuff you need to make your own pure perl module, and
> another example with all the stuff you need to make your own XS module.
A module with (simple) XS is handled identically to a pure Perl module.
If you need to specify linker/compiler flags then it's a little different.
> I know that those sorts of examples would have saved me a lot of time
> today.
Now that you know what they should be, why not submit a patch? ;)
-ave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
|
|
From: Randy W. S. <Ra...@Th...> - 2003-12-19 08:53:22
|
On 12/19/2003 3:36 AM, Dave Rolsky wrote: > On Fri, 19 Dec 2003, Glenn Linderman wrote: > > For some reason I can't recall, I coded it so that codebase can only be > given from the command line via: > > ./Build ppd codebase=. > > However, I'm pretty sure a codebase on "." will not work, but I won't > swear to it. > > A patch to make codebase settable via the new() method is probably good > thing, right Ken? I think you did the Right Thing. No one but the person executing the ppd target knows what the codebase should be, so it must be supplied by the user on the command line. Randy. |
|
From: Glenn L. <pe...@ne...> - 2003-12-19 09:36:18
|
On approximately 12/19/2003 12:53 AM, came the following characters from the keyboard of Randy W. Sims: > On 12/19/2003 3:36 AM, Dave Rolsky wrote: > >> On Fri, 19 Dec 2003, Glenn Linderman wrote: >> >> For some reason I can't recall, I coded it so that codebase can only be >> given from the command line via: >> >> ./Build ppd codebase=. >> >> However, I'm pretty sure a codebase on "." will not work, but I won't >> swear to it. >> >> A patch to make codebase settable via the new() method is probably good >> thing, right Ken? > > > I think you did the Right Thing. No one but the person executing the ppd > target knows what the codebase should be, so it must be supplied by the > user on the command line. Well, no one but the person executing ANY command that takes parameters knows what the parameter value should be, but if there is a reasonable default, it can be helpful. In this case, it seems to me that there is a reasonable default: the unqualified by path name file name produced by the build dist command. -- 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. |
|
From: Glenn L. <pe...@ne...> - 2003-12-19 09:05:29
|
On approximately 12/19/2003 12:36 AM, came the following characters from
the keyboard of Dave Rolsky:
> On Fri, 19 Dec 2003, Glenn Linderman wrote:
>
>
>>"perl build dist" produces errors, and "perl build ppd" produces errors:
>
>
> You probably don't want to build a PPD unless you understand what the
> various things that go in a PPD are. I'm not an expert on it, but I did
> write the PPD-related code for Module::Build, and from what I can gather
> you need to actually understand how it will be used, where it will be
> installed from, etc., to make it work.
I want to build a PPD, even though I don't fully understand all the
things in the PPD. This is a module for ActivePerl I'm building, so it
needs to be PPD.
I do have some experience with PPD files, as I fought with a bug in PPM
long enough to learn a little about them. As it turns out, a relative
path in the URL is the "best" in the sense that then the .tar.gz file is
looked for in the same directory as the .ppd file, and that is certainly
the easiest to package into a .zip (or any other kind of) wrapper for
distributing the .ppd and .tar.gz files together. It also works well
for installing them on a Web site, or moving them around on one's hard
disk, without having to re-edit the .ppd file to reflect the path
change. As far as the rest? I'm probably ignorant. The bug? I tried
installing from the root directory of a drive during a period of time
when that didn't work.
>>Unable to add file: 'GFfP-0.1/blib' at
>>C:\Perl\site\lib/Module/Build/Base.pm line 1706
>
>
> This I'll let Ken answer.
Yes... Ken? And one more thing... it seems that case is not preserved
in the file names... While that "doesn't matter" as long as the platform
is Windows, it could be critical if the platform is not Windows.
Windows is case-preserving, so if the user creates the files correctly,
they will follow the proper conventions for a case sensitive file system
as well. But M::B doesn't do that at present.
>>D:\GFfP>perl build ppd
>>Cannot create a PPD file unless codebase argument is given
>>
>>
>>Here's my build.pl
>>
>>use Module::Build;
>>my $build = Module::Build->new
>> (
>> module_name => 'GFfP',
>> license => 'restrictive',
>> dist_author => 'Glenn Linderman <pe...@ne...>',
>> requires => { 'perl' => '5.8.0', },
>> codebase => '.',
>> );
>>$build->create_build_script;
>
>
> For some reason I can't recall, I coded it so that codebase can only be
> given from the command line via:
>
> ./Build ppd codebase=.
>
> However, I'm pretty sure a codebase on "." will not work, but I won't
> swear to it.
Ah, at least I can experiment now.
> A patch to make codebase settable via the new() method is probably good
> thing, right Ken?
Perhaps overridable from the command line, for those that need it.
Actually, assuming "no path at all" is probably a fine default.
Certainly it is what I want.
>>The documentation Module::Build supplies for "codebase" is pretty terse,
>>and there are no examples of it in the sample Build.pl file.
>
>
> That's cause I don't really understand the PPD stuff too well. I was kind
> of hoping some Win32 expert would fill in the the rest.
I'm not he, the expert is likely Jan Dubois, if you can get him
interested in Module::Build.
>>And all those warnings from perl build dist are for directories... and
>>indeed, the resulting .tar.gz file has a flat structure... the files are
>>all there, but their directory structure is not preserved. As a result,
>>I can't distribute the package.
>
>
> I wonder if it's a permissions problem.
Dunno, I'm running as an administrator, and everything is in directories
I own.
>>It'd be nice to have a sample MANIFEST file too, for a sample
>>project.
>
>
> ./Build manifest
I stumbled across that, but it wasn't immediately clear which files
should be in MANIFEST, and which should not.
Remember, I'm on my first module here.
>>Seems to me like the Cookbook should have a trivial, but complete,
>>example of all the stuff you need to make your own pure perl module, and
>>another example with all the stuff you need to make your own XS module.
>
>
> A module with (simple) XS is handled identically to a pure Perl module.
> If you need to specify linker/compiler flags then it's a little different.
>
>
>> I know that those sorts of examples would have saved me a lot of time
>>today.
>
>
> Now that you know what they should be, why not submit a patch? ;)
Not everything is working 100% yet, so it is not clear I am an expert
yet. And by the time I figure out how to submit a patch, Ken will have
released this module.... maybe for the next release....
Thanks for your responses, though.
Oh, here's one other issue: perl build.pl seems to check the MANIFEST,
but of course there is lots of stuff missing before you compile. It
seems like maybe I either still don't understand MANIFEST files, or else
the checking of MANIFEST should be done after the build, or else the
MANIFEST should discriminate between "source" and "built" files, so
proper (but different) checking can be done at either time.
--
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.
|
|
From: Randy W. S. <Ra...@Th...> - 2003-12-19 08:44:37
|
On 12/19/2003 3:27 AM, Glenn Linderman wrote: > D:\GFfP>perl build dist > Deleting META.yml > mkdir GFfP-0.1 > mkdir GFfP-0.1/blib > mkdir GFfP-0.1/blib/arch > mkdir GFfP-0.1/blib/arch/auto > mkdir GFfP-0.1/blib/arch/auto/GFfP > mkdir GFfP-0.1/blib/lib > Creating GFfP-0.1.tar.gz > Unable to add file: 'GFfP-0.1' at C:\Perl\site\lib/Module/Build/Base.pm > line 1706 > Unable to add file: 'GFfP-0.1/blib' at > C:\Perl\site\lib/Module/Build/Base.pm line 1706 > Unable to add file: 'GFfP-0.1/blib/lib' at > C:\Perl\site\lib/Module/Build/Base.pm line 1706 > Unable to add file: 'GFfP-0.1/blib/arch' at > C:\Perl\site\lib/Module/Build/Base.pm line 1706 > Unable to add file: 'GFfP-0.1/blib/arch/auto' at > C:\Perl\site\lib/Module/Build/Base.pm line 1706 > Unable to add file: 'GFfP-0.1/blib/arch/auto/GFfP' at > C:\Perl\site\lib/Module/Build/Base.pm line 1706 > Deleting GFfP-0.1 These warnings are due to Archive::Tar and are fixed for future release >= 1.08. These are just warnings and won't cause problems. > D:\GFfP>perl build ppd > Cannot create a PPD file unless codebase argument is given I misspoke on the win32 list: It's the ppd target (not dist) where you specify the codebase param: perl Build ppd codebase="." > > So you can see from the build.pl that I *did* supply a codebase > parameter, at least as far as I could figure out how. I figured to > compare the resulting .ppd file with one from a different module and > tweak the supplied value appropriately, but I get the error that it > isn't supplied, so maybe I am supplying it in the wrong place? > The documentation Module::Build supplies for "codebase" is pretty terse, > and there are no examples of it in the sample Build.pl file. > > And all those warnings from perl build dist are for directories... and > indeed, the resulting .tar.gz file has a flat structure... the files are > all there, but their directory structure is not preserved. As a > result, I can't distribute the package. Some programs don't see the directory structure in the tar created by Archive::Tar. If you use the ptar script distributed with A::T, you should see that the directory structure is valid. Andrew, do you know if this has changed for future versions of A::T? > It'd be nice to have a sample MANIFEST file too, for a sample > project. > > Seems to me like the Cookbook should have a trivial, but complete, > example of all the stuff you need to make your own pure perl module, and > another example with all the stuff you need to make your own XS module. > I know that those sorts of examples would have saved me a lot of time > today. > I see you got past the YAML errors; did they go away after installing YAML? Regards, Randy. |
|
From: Glenn L. <pe...@ne...> - 2003-12-19 09:35:31
|
On approximately 12/19/2003 12:44 AM, came the following characters from
the keyboard of Randy W. Sims:
>
> These warnings are due to Archive::Tar and are fixed for future release
>
>> = 1.08. These are just warnings and won't cause problems.
I don't believe that until I can see the directory structure in the
.tar.gz file... because right now it seems there are warnings, and the
result is broken.
>> D:\GFfP>perl build ppd
>> Cannot create a PPD file unless codebase argument is given
>
>
> I misspoke on the win32 list: It's the ppd target (not dist) where you
> specify the codebase param:
>
> perl Build ppd codebase="."
I guess the missing codebase wasn't the only problem.
D:\GFfP>perl build ppd codebase=.
Use of uninitialized value in substitution (s///) at
C:\Perl\site\lib/Module/Build/PPMMaker.pm line 126.
Use of uninitialized value in sprintf at
C:\Perl\site\lib/Module/Build/PPMMaker.pm line 31.
But looking at the .ppd, it does seem that a better default for codebase
would be the simple name of the .tar.gz file.... so
D:\GFfP>perl build ppd codebase="GFfP-0.1.tar.gz"
Use of uninitialized value in substitution (s///) at
C:\Perl\site\lib/Module/Build/PPMMaker.pm line 126.
Use of uninitialized value in sprintf at
C:\Perl\site\lib/Module/Build/PPMMaker.pm line 31.
D:\GFfP>type GFfP.ppd
<SOFTPKG NAME="GFfP" VERSION="0,1,0,0">
<TITLE>GFfP</TITLE>
<ABSTRACT></ABSTRACT>
<AUTHOR>Glenn Linderman <pe...@ne...></AUTHOR>
<IMPLEMENTATION>
<PERLCORE VERSION="5,008000,0,0" />
<OS VALUE="MSWin32" />
<ARCHITECTURE NAME="MSWin32-x86-multi-thread" />
<CODEBASE HREF="GFfP-0.1.tar.gz" />
</IMPLEMENTATION>
</SOFTPKG>
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.
>> And all those warnings from perl build dist are for directories... and
>> indeed, the resulting .tar.gz file has a flat structure... the files
>> are all there, but their directory structure is not preserved. As a
>> result, I can't distribute the package.
>
>
> Some programs don't see the directory structure in the tar created by
> Archive::Tar. If you use the ptar script distributed with A::T, you
> should see that the directory structure is valid.
So you mean A::T is incompatible with the standard TAR files that lots
of programs know about? Hmmm. ptar didn't get installed with A::T.
Well, if the directory structure is there, I have 2 tar other programs
that A::T is incompatible with.
Hmmm. Can't find "ptar" in the A::T distribution, either. But I do
notice that the A::T distribution has a directory structure that my
programs that can't see the directory structure of M::B dist output can
see. Of course, maybe A::T doesn't use itself to pack itself, I
wouldn't know without reading its build code... too late for that
yesterday. I've got to get to bed.
> Andrew, do you know if this has changed for future versions of A::T?
>
>> It'd be nice to have a sample MANIFEST file too, for a sample
>> project.
>>
>> Seems to me like the Cookbook should have a trivial, but complete,
>> example of all the stuff you need to make your own pure perl module,
>> and another example with all the stuff you need to make your own XS
>> module. I know that those sorts of examples would have saved me a lot
>> of time today.
>>
>
> I see you got past the YAML errors; did they go away after installing YAML?
Yeah, they went away like magic, once YAML was installed. Just more
dependency-itis to deal with.
Thanks again for the responses.
--
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.
|
|
From: Randy W. S. <Ra...@Th...> - 2003-12-19 10:05:32
|
On 12/19/2003 4:30 AM, Glenn Linderman wrote: > On approximately 12/19/2003 12:44 AM, came the following characters from > the keyboard of Randy W. Sims: > I guess the missing codebase wasn't the only problem. > > D:\GFfP>perl build ppd codebase=. > Use of uninitialized value in substitution (s///) at > C:\Perl\site\lib/Module/Build/PPMMaker.pm line 126. > Use of uninitialized value in sprintf at > C:\Perl\site\lib/Module/Build/PPMMaker.pm line 31. > > But looking at the .ppd, it does seem that a better default for codebase > would be the simple name of the .tar.gz file.... so > > D:\GFfP>perl build ppd codebase="GFfP-0.1.tar.gz" > Use of uninitialized value in substitution (s///) at > C:\Perl\site\lib/Module/Build/PPMMaker.pm line 126. > Use of uninitialized value in sprintf at > C:\Perl\site\lib/Module/Build/PPMMaker.pm line 31. > > D:\GFfP>type GFfP.ppd > <SOFTPKG NAME="GFfP" VERSION="0,1,0,0"> > <TITLE>GFfP</TITLE> > <ABSTRACT></ABSTRACT> > <AUTHOR>Glenn Linderman <pe...@ne...></AUTHOR> > <IMPLEMENTATION> > <PERLCORE VERSION="5,008000,0,0" /> > <OS VALUE="MSWin32" /> > <ARCHITECTURE NAME="MSWin32-x86-multi-thread" /> > <CODEBASE HREF="GFfP-0.1.tar.gz" /> > </IMPLEMENTATION> > </SOFTPKG> 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? > 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. >>> And all those warnings from perl build dist are for directories... >>> and indeed, the resulting .tar.gz file has a flat structure... the >>> files are all there, but their directory structure is not >>> preserved. As a result, I can't distribute the package. >> >> >> >> Some programs don't see the directory structure in the tar created by >> Archive::Tar. If you use the ptar script distributed with A::T, you >> should see that the directory structure is valid. > > > So you mean A::T is incompatible with the standard TAR files that lots > of programs know about? Hmmm. ptar didn't get installed with A::T. Well, I think the tar format has been around for a very long time, and in that time it has evolved. I.e. their are variations in the format. But, if gnu tar can produce a tar file compatible with most tools on Windows, I think Archive::Tar should also; Windows is one of the reasons that Archive::Tar is such an important module, because there is no common tar program on Windows. >> I see you got past the YAML errors; did they go away after installing >> YAML? > > > 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... > Thanks again for the responses. > Thanks for your feedback and patience; those are the things most needed to improve M::B. Regards, Randy. |
|
From: Glenn L. <pe...@ne...> - 2003-12-19 21:18:12
|
On approximately 12/19/2003 2:05 AM, came the following characters from
the keyboard of Randy W. Sims:
> On 12/19/2003 4:30 AM, Glenn Linderman wrote:
>
>> On approximately 12/19/2003 12:44 AM, came the following characters from
>> the keyboard of Randy W. Sims:
>
>
>> I guess the missing codebase wasn't the only problem.
>>
>> D:\GFfP>perl build ppd codebase=.
>> Use of uninitialized value in substitution (s///) at
>> C:\Perl\site\lib/Module/Build/PPMMaker.pm line 126.
>> Use of uninitialized value in sprintf at
>> C:\Perl\site\lib/Module/Build/PPMMaker.pm line 31.
>>
>> But looking at the .ppd, it does seem that a better default for
>> codebase would be the simple name of the .tar.gz file.... so
>>
>> D:\GFfP>perl build ppd codebase="GFfP-0.1.tar.gz"
>> Use of uninitialized value in substitution (s///) at
>> C:\Perl\site\lib/Module/Build/PPMMaker.pm line 126.
>> Use of uninitialized value in sprintf at
>> C:\Perl\site\lib/Module/Build/PPMMaker.pm line 31.
>>
>> D:\GFfP>type GFfP.ppd
>> <SOFTPKG NAME="GFfP" VERSION="0,1,0,0">
>> <TITLE>GFfP</TITLE>
>> <ABSTRACT></ABSTRACT>
>> <AUTHOR>Glenn Linderman <pe...@ne...></AUTHOR>
>> <IMPLEMENTATION>
>> <PERLCORE VERSION="5,008000,0,0" />
>> <OS VALUE="MSWin32" />
>> <ARCHITECTURE NAME="MSWin32-x86-multi-thread" />
>> <CODEBASE HREF="GFfP-0.1.tar.gz" />
>> </IMPLEMENTATION>
>> </SOFTPKG>
>
>
> 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?
If it remains optional, something like the following should be used to
eliminate the warnings:
$archive = '' unless defined $archive;
If it becomes a requirement (and the abstract can also be specified in
the Build.pl it appears) then an error informing the user of the missing
abstract would be nice, yes.
My opinion? Leave it optional, warn if empty (but not those warnings,
an informative one).
>> 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.
Explaining that it was omitting and describing what it defaulted to
never hurts, although some might think it is just noise.
>>>> And all those warnings from perl build dist are for directories...
>>>> and indeed, the resulting .tar.gz file has a flat structure... the
>>>> files are all there, but their directory structure is not
>>>> preserved. As a result, I can't distribute the package.
>>>
>>> Some programs don't see the directory structure in the tar created by
>>> Archive::Tar. If you use the ptar script distributed with A::T, you
>>> should see that the directory structure is valid.
>>
>> So you mean A::T is incompatible with the standard TAR files that lots
>> of programs know about? Hmmm. ptar didn't get installed with A::T.
>
>
> Well, I think the tar format has been around for a very long time, and
> in that time it has evolved. I.e. their are variations in the format.
> But, if gnu tar can produce a tar file compatible with most tools on
> Windows, I think Archive::Tar should also; Windows is one of the reasons
> that Archive::Tar is such an important module, because there is no
> common tar program on Windows.
I suppose I should try to install my module, to determine if it winds up
flat.... well, I still don't know if it is flat.... I notice that
another module I use, Win32::GUI, has a similar .ppd file, but there are
two differences... there is no PERLCORE VERSION, and "-5.8" is added
into the ARCHITECTURE NAME value. I include its successfully installing
.ppd file below the one for my GFfP packagae.
D:\>ppm install d:\gffp\gffp.ppd
Error: no suitable installation target found for package GFfP.
D:\>type gffp\gffp.ppd
<SOFTPKG NAME="GFfP" VERSION="0,1,0,0">
<TITLE>GFfP</TITLE>
<ABSTRACT></ABSTRACT>
<AUTHOR>Glenn Linderman <pe...@ne...></AUTHOR>
<IMPLEMENTATION>
<PERLCORE VERSION="5,008000,0,0" />
<OS VALUE="MSWin32" />
<ARCHITECTURE NAME="MSWin32-x86-multi-thread" />
<CODEBASE HREF="GFfP-0.1.tar.gz" />
</IMPLEMENTATION>
</SOFTPKG>
D:\>perl -v
This is perl, v5.8.0 built for MSWin32-x86-multi-thread
(with 1 registered patch, see perl -V for more detail)
Copyright 1987-2002, Larry Wall
Binary build 805 provided by ActiveState Corp. http://www.ActiveState.com
Built 18:08:02 Feb 4 2003
D:\>type gui\win32-gui.ppd
<SOFTPKG NAME="Win32-GUI" VERSION="0,0,680,0">
<TITLE>Win32-GUI</TITLE>
<ABSTRACT>Perl-Win32 Graphical User Interface Extension</ABSTRACT>
<AUTHOR>Aldo Calpini <da...@pe...></AUTHOR>
<IMPLEMENTATION>
<OS NAME="MSWin32" />
<ARCHITECTURE NAME="MSWin32-x86-multi-thread-5.8" />
<CODEBASE HREF="Win32-GUI.tar.gz" />
</IMPLEMENTATION>
</SOFTPKG>
--
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.
|
|
From: Randy W. S. <Ra...@Th...> - 2003-12-19 22:09:57
|
On 12/19/2003 4:05 PM, Glenn Linderman wrote: > I suppose I should try to install my module, to determine if it winds up > flat.... well, I still don't know if it is flat.... I notice that > another module I use, Win32::GUI, has a similar .ppd file, but there are > two differences... there is no PERLCORE VERSION, and "-5.8" is added > into the ARCHITECTURE NAME value. I include its successfully installing > .ppd file below the one for my GFfP packagae. > > D:\>ppm install d:\gffp\gffp.ppd > Error: no suitable installation target found for package GFfP. > > D:\>type gffp\gffp.ppd > <SOFTPKG NAME="GFfP" VERSION="0,1,0,0"> > <TITLE>GFfP</TITLE> > <ABSTRACT></ABSTRACT> > <AUTHOR>Glenn Linderman <pe...@ne...></AUTHOR> > <IMPLEMENTATION> > <PERLCORE VERSION="5,008000,0,0" /> > <OS VALUE="MSWin32" /> > <ARCHITECTURE NAME="MSWin32-x86-multi-thread" /> > <CODEBASE HREF="GFfP-0.1.tar.gz" /> > </IMPLEMENTATION> > </SOFTPKG> > > D:\>perl -v > > This is perl, v5.8.0 built for MSWin32-x86-multi-thread The problem here is ActiveState chose to solve the 5.6 vs 5.8 binary compatibility problem by appending "-5.8" to the ARCHITECTURE tag. Try manually editing the ppd file, and let me know if that works. Regards, Randy. |
|
From: Glenn L. <pe...@ne...> - 2003-12-19 23:02:12
|
On approximately 12/19/2003 2:10 PM, came the following characters from
the keyboard of Randy W. Sims:
> On 12/19/2003 4:05 PM, Glenn Linderman wrote:
>
> > I suppose I should try to install my module, to determine if it winds up
>
>> flat.... well, I still don't know if it is flat.... I notice that
>> another module I use, Win32::GUI, has a similar .ppd file, but there
>> are two differences... there is no PERLCORE VERSION, and "-5.8" is
>> added into the ARCHITECTURE NAME value. I include its successfully
>> installing .ppd file below the one for my GFfP packagae.
>>
>> D:\>ppm install d:\gffp\gffp.ppd
>> Error: no suitable installation target found for package GFfP.
>>
>> D:\>type gffp\gffp.ppd
>> <SOFTPKG NAME="GFfP" VERSION="0,1,0,0">
>> <TITLE>GFfP</TITLE>
>> <ABSTRACT></ABSTRACT>
>> <AUTHOR>Glenn Linderman <pe...@ne...></AUTHOR>
>> <IMPLEMENTATION>
>> <PERLCORE VERSION="5,008000,0,0" />
>> <OS VALUE="MSWin32" />
>> <ARCHITECTURE NAME="MSWin32-x86-multi-thread" />
>> <CODEBASE HREF="GFfP-0.1.tar.gz" />
>> </IMPLEMENTATION>
>> </SOFTPKG>
>>
>> D:\>perl -v
>>
>> This is perl, v5.8.0 built for MSWin32-x86-multi-thread
>
>
> The problem here is ActiveState chose to solve the 5.6 vs 5.8 binary
> compatibility problem by appending "-5.8" to the ARCHITECTURE tag. Try
> manually editing the ppd file, and let me know if that works.
I should have thought of editing it, DUH. Well, it was late. Or early,
or whatever.
OK, so I edited it, and that made PPM happy, and it claims to have
installed it, but there are no signs of any of the files in the c:\perl
directory tree. Also missing are any indications from PPM of any files
being copied as part of the installation, which usually seems to happen.
Dare I suggest that it is because the directory structure is flat? :)
Can you point me at a ptar ? Would you like to a copy of my
GFfP-0.1.tar.gz file?
D:\GFfP>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:\GFfP>type GFfP.ppd
<SOFTPKG NAME="GFfP" VERSION="0,1,0,0">
<TITLE>GFfP</TITLE>
<ABSTRACT></ABSTRACT>
<AUTHOR>Glenn Linderman <pe...@ne...></AUTHOR>
<IMPLEMENTATION>
<OS VALUE="MSWin32" />
<ARCHITECTURE NAME="MSWin32-x86-multi-thread-5.8" />
<CODEBASE HREF="GFfP-0.1.tar.gz" />
</IMPLEMENTATION>
</SOFTPKG>
--
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.
|
|
From: Randy W. S. <Ra...@Th...> - 2003-12-19 23:19:34
|
On 12/19/2003 5:55 PM, Glenn Linderman wrote: > OK, so I edited it, and that made PPM happy, and it claims to have > installed it, but there are no signs of any of the files in the c:\perl > directory tree. Also missing are any indications from PPM of any files > being copied as part of the installation, which usually seems to happen. > > Dare I suggest that it is because the directory structure is flat? :) > > Can you point me at a ptar ? Would you like to a copy of my > GFfP-0.1.tar.gz file? > 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. Randy. |
|
From: Glenn L. <pe...@ne...> - 2003-12-19 23:38:50
|
On approximately 12/19/2003 3:19 PM, came the following characters from the keyboard of Randy W. Sims: > On 12/19/2003 5:55 PM, Glenn Linderman wrote: > > > OK, so I edited it, and that made PPM happy, and it claims to have > >> installed it, but there are no signs of any of the files in the >> c:\perl directory tree. Also missing are any indications from PPM of >> any files being copied as part of the installation, which usually >> seems to happen. >> >> Dare I suggest that it is because the directory structure is flat? :) >> >> Can you point me at a ptar ? Would you like to a copy of my >> GFfP-0.1.tar.gz file? >> > > You can extract ptar from an older version of Archive::Tar > <http://search.cpan.org/dist/Archive-Tar-0.23/>, Well, I wasn't interest in playing potential versionitis games.... or get a version of tar > for windows that I know to be working at > <http://unxutils.sourceforge.net/>, So I chose to download the unxutils, and here is its analysis of gunzip'd file built by M::B. D:\GFfP>tar_unxutils tvf gffp-0.1.tar -rwSrwSrw- unknown/unknown 267 2003-12-18 22:00 build.pl -rwSrwSrw- unknown/unknown 443 2003-12-19 00:15 MANIFEST -rwSrwSrw- unknown/unknown 226 2003-12-19 14:43 META.yml -rwSrwSrw- unknown/unknown 902 2003-12-18 22:29 GFfP.pm -rwSrwSrw- unknown/unknown 0 2003-12-19 00:41 GFfP.bs -rwSrwSrw- unknown/unknown 24629 2003-12-19 00:41 GFfP.dll -rwSrwSrw- unknown/unknown 739 2003-12-19 00:41 GFfP.exp -rwSrwSrw- unknown/unknown 2074 2003-12-19 00:41 GFfP.lib or you can email me (off list) the > file and I'll take a look at it. I'll do this too... -- 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. |
|
From: Randy W. S. <Ra...@Th...> - 2003-12-20 00:06:01
|
Argh... You're right, there is no directory structure in the file you sent. I didn't believe it, so I downloaded Module-CoreList and did a perl Build.PL, perl Build, perl Build dist, and got the same results... a tar dist with a flat directory structure. I'm confused. There was a discussion on the list early November, "Help: Module::Build V 0.21 under WinXP" where this same problem came up. I traced through it. M::B was working. A::T was was working. Off list talking with Ron, we found the problem to be the tar program he was using; I sent him my working version, and everything worked. Now same circumstances, and the solution has apparently changed. The only thing different is the computer I'm using right now has perl 5.8, whereas I did my testing before on a system with 5.6, but that shouldn't make a difference. I am convinced that the problem is not in M::B, nothing there has changed since I looked into it before... Unfortunately, I won't be able to investigate this further until tomorrow :-(. Regards, Randy. |
|
From: Glenn L. <pe...@ne...> - 2003-12-20 00:31:58
|
On approximately 12/19/2003 4:05 PM, came the following characters from the keyboard of Randy W. Sims: > > Argh... Ah, now we share the same feeling :) > You're right, there is no directory structure in the file you sent. I > didn't believe it, so I downloaded Module-CoreList and did a perl > Build.PL, perl Build, perl Build dist, and got the same results... a tar > dist with a flat directory structure. I'm confused. > > There was a discussion on the list early November, "Help: Module::Build > V 0.21 under WinXP" where this same problem came up. I traced through > it. M::B was working. A::T was was working. Off list talking with Ron, > we found the problem to be the tar program he was using; I sent him my > working version, and everything worked. Now same circumstances, and the > solution has apparently changed. The only thing different is the > computer I'm using right now has perl 5.8, whereas I did my testing > before on a system with 5.6, but that shouldn't make a difference. > > I am convinced that the problem is not in M::B, nothing there has > changed since I looked into it before... Well, I suppose that different versions of A::T could change something too, although published interfaces should stay consistent.... > Unfortunately, I won't be able to investigate this further until > tomorrow :-(. Well, "perl build install" works, for my personal use... but I'd like to be able to package it for a few others that might want to use it. But I have weeks of work to do on the rest of the program before then, so tomorrow should be soon enough. :) -- 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. |
|
From: Randy W. S. <Ra...@Th...> - 2003-12-20 08:18:21
|
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. Thanks, Randy. |
|
From: Glenn L. <pe...@ne...> - 2003-12-20 17:17:13
|
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. |
|
From: Randy W. S. <Ra...@Th...> - 2003-12-20 18:17:31
|
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. |
|
From: Ken W. <ke...@ma...> - 2003-12-20 20:22:23
|
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 |
|
From: Randy W. S. <Ra...@Th...> - 2003-12-21 08:40:01
|
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. |
|
From: <ajs...@ya...> - 2003-12-21 12:18:26
|
--- "Randy W. Sims" <Ra...@Th...> wrote: > 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... Sorry, I've been too busy lately and haven't been following this thread as closely as I should. One thing you should be aware of is trouble ticket 4437 at: http://rt.cpan.org/NoAuth/Bugs.html?Dist=Archive-Tar&ShowAll=1 As discussed in detail in this thread, tarballs created by Archive::Tar lose the directory information when unpacked/viewed with old versions of tarball viewers/extractors that do not properly implement the latest tar spec. IIRC, old versions of BSD tar and many versions of WinZip lose the directory information. At the cost of making the A::T code somewhat ugly, I think an imperfect heuristic solution is possible, so that if all PATHs in the tarball were less than 100 characters in length, A::T could write the whole path at the front of the chunk and not use the 'prefix' field -- with a different code path, using the 'prefix' field, followed if any path in the tarball exceeds 100 characters in length. /-\ http://personals.yahoo.com.au - Yahoo! Personals New people, new possibilities. FREE for a limited time. |
|
From: Jos I. B. <ka...@dw...> - 2003-12-21 12:29:28
|
On Sun, 21 Dec 2003, [iso-8859-1] Andrew Savige wrote: > At the cost of making the A::T code somewhat ugly, I think an imperfect > heuristic solution is possible, so that if all PATHs in the tarball were > less than 100 characters in length, A::T could write the whole path at > the front of the chunk and not use the 'prefix' field -- with a different > code path, using the 'prefix' field, followed if any path in the tarball > exceeds 100 characters in length. i'm very much opposed to this solution, since this still doesn't actually /fix/ the problem; it's merely coding around a problem in /other/ tools, and it will introduce a very fun /new/ 'bug' that distributions that keep their longest path under 100 chars will do the right thing, and any distribution with a path > 100 chars will now break... id much rather document this shortcoming in other tools and add a dependency on a /proper/ tar extractor, that follows the specs for the tar format... A::T, gnu tar and quite a few others do... old bsd tars and some )"(#/"#) windows tools dont..... just my $0.02 -jos |
|
From: Randy W. S. <Ra...@Th...> - 2003-12-21 12:54:16
|
On 12/21/2003 7:29 AM, Jos I. Boumans wrote: > > On Sun, 21 Dec 2003, [iso-8859-1] Andrew Savige wrote: > >>At the cost of making the A::T code somewhat ugly, I think an imperfect >>heuristic solution is possible, so that if all PATHs in the tarball were >>less than 100 characters in length, A::T could write the whole path at >>the front of the chunk and not use the 'prefix' field -- with a different >>code path, using the 'prefix' field, followed if any path in the tarball >>exceeds 100 characters in length. > > i'm very much opposed to this solution, since this still doesn't actually > /fix/ the problem; it's merely coding around a problem in /other/ tools, > and it will introduce a very fun /new/ 'bug' that distributions that keep > their longest path under 100 chars will do the right thing, and any > distribution with a path > 100 chars will now break... id much rather > document this shortcoming in other tools and add a dependency on a > /proper/ tar extractor, that follows the specs for the tar format... A::T, > gnu tar and quite a few others do... old bsd tars and some )"(#/"#) > windows tools dont..... > > just my $0.02 > > -jos > I don't believe this is the same problem. This is a problem where a tar file created on non-windows works but a tar file created on windows does not. I uploaded two tar files to: <http://www.thepierianspring.org/Archive-Tar-1.07.tar> <http://www.thepierianspring.org/ptar.tar> Both where created with the old ptar script from ~ 0.23. The first is a tar of Archive::Tar 1.07 release from CPAN. A cat shows all the files stored as expected but without path info. The second is a copy of the ptar script renamed to ptar/ptar.pl. A cat shows the file name as '.pl' and no path info. Randy. -- A little learning is a dang'rous thing; Drink deep, or taste not the Pierian spring; There shallow draughts intoxicate the brain; And drinking largely sobers us again. - Alexander Pope |
|
From: Ken W. <ke...@ma...> - 2003-12-21 16:52:59
|
On Sunday, December 21, 2003, at 06:29 AM, Jos I. Boumans wrote: > > > On Sun, 21 Dec 2003, [iso-8859-1] Andrew Savige wrote: >> At the cost of making the A::T code somewhat ugly, I think an >> imperfect >> heuristic solution is possible, so that if all PATHs in the tarball >> were >> less than 100 characters in length, A::T could write the whole path at >> the front of the chunk and not use the 'prefix' field -- with a >> different >> code path, using the 'prefix' field, followed if any path in the >> tarball >> exceeds 100 characters in length. > i'm very much opposed to this solution, since this still doesn't > actually > /fix/ the problem; it's merely coding around a problem in /other/ > tools, Those other tools aren't broken, they're simply written to an older version of the TAR spec. And it seems really bad to produce tarballs that will silently fail with all such tools. You know, "backward compatibility" and all.... -Ken |
|
From: Glenn L. <pe...@ne...> - 2003-12-22 01:31:11
|
On approximately 12/21/2003 4:29 AM, came the following characters from
the keyboard of Jos I. Boumans:
>
> On Sun, 21 Dec 2003, [iso-8859-1] Andrew Savige wrote:
>
>>At the cost of making the A::T code somewhat ugly, I think an imperfect
>>heuristic solution is possible, so that if all PATHs in the tarball were
>>less than 100 characters in length, A::T could write the whole path at
>>the front of the chunk and not use the 'prefix' field -- with a different
>>code path, using the 'prefix' field, followed if any path in the tarball
>>exceeds 100 characters in length.
>
> i'm very much opposed to this solution, since this still doesn't actually
> /fix/ the problem; it's merely coding around a problem in /other/ tools,
> and it will introduce a very fun /new/ 'bug' that distributions that keep
> their longest path under 100 chars will do the right thing, and any
> distribution with a path > 100 chars will now break... id much rather
> document this shortcoming in other tools and add a dependency on a
> /proper/ tar extractor, that follows the specs for the tar format... A::T,
> gnu tar and quite a few others do... old bsd tars and some )"(#/"#)
> windows tools dont.....
>
> just my $0.02
>
> -jos
Interesting point of view. That's sort of like outlawing all the old
cars that don't have some new safety feature, making it illegal to drive
them on the roads.
Sure seems to me that a high percentage of the tarballs in the world
have mostly paths less than 100 characters.
It is too bad that the old programs can look at the new tarball and see
a subset of the data, instead of reporting the real condition, at least
as a warning if not an error: "This tarball was produced using a version
of tar that implements a newer specification than this tar program. To
see the tarball in its full detail, you should use a tar program that
implements specification GHI. This tar program only implements
specification ABC."
That would explain the situation to the user.
On the other hand, for those tarballs that can be correctly created
according to the older specifications, without loss of functionality,
that is an extremely friendly feature even for a program that is capable
of creating tarballs using the new specifications, with new
functionality. This sort of thing is called "backward compatibility",
and it encourages people to use the new program, since it interoperates
with the old, instead of encouraging them to throw the new program away,
sticking with the old tried and true and interoperable programs.
I have to admit that if I was under time pressure today to release my
new module (I still have a few weeks to go), that I would be extremely
tempted to discard both
(1) Archive::Tar,
(2) Module::Build,
because
(A) the module that I built won't install properly using PPM (even
with A::T v1.07),
(B) I can't see the paths to the files using PowerArchiver 2001,
(C) I don't get warnings for each directory that is supposed to be
in the tarball, and
(D) I have other sample modules using MakeMaker and tar programs,
that do not suffer from (A), (B), and (C), so it is clearly a functional
path to take.
Since I have some lead time, I'll wait and see how this plays out over
the next few weeks. People like backward compatibility, because it
makes things work. And when things don't work, because of incremental
versionitis, it is nice if there is a built in method for reporting that
that is why, instead of simply providing reduced functionality without
warning. Providing reduced functionality is OK, with the warning. So
if an old tar program can extract the data, but not put it in the right
place, that is OK, if it tells me that it the tarball is a newer version
that it might not be able to fully decode.
The fact that there are bugs and deficiencies in old programs, however,
is no excuse for a new program not to be as backward compatible as it
can be.
Personally, I'd rather see archives stored as .zip files, which at least
were designed to do both archiving and compression in one step, rather
than play the two-step jig of .tar.gz. But that's a whole 'nother
story, and an idea which probably won't get much momentum or attention,
because .tar.gz is there and works. Well, given my above woes, sort of.
--
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.
|
Thanks for helping keep SourceForge clean.
X