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

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

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 &lt;pe...@ne...&gt;</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.