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