Re: [Module::Build] codebase? paths in .tar.gz?
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
Re: [Module::Build] codebase? paths in .tar.gz?
|
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.
|
