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

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

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

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.

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

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

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.

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

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

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.

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

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

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.

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

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

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.

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

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

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

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

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

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 &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>
> 
> 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.

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

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

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 &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?

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 &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>

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

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.

Re: [Module::Build] M::B - the developer snapshot

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

On approximately 12/19/2003 1:21 AM, came the following characters from
the keyboard of Randy W. Sims:

> On 12/19/2003 3:44 AM, Glenn Linderman wrote:
> 
>> In attempting to install the developer snapshot as Randy Sims suggested,
>> I got the following, confidence-decreasing :) error on the first step!
>>
>> D:\Module-Build-0.21_01>perl build.pl
>> Checking whether your kit is complete...
>> Looks good
>>  * Version <none> is installed, but we prefer to have 2.02
>> ERRORS/WARNINGS FOUND IN PREREQUISITES.  You may wish to install the 
>> versions
>>  of the modules indicated above before proceeding with this installation.
> 
> 
> This was already fixed by Ken in CVS. This is just a warning about an
> optional module that M::B wants. If you don't have CVS just grab the
> file from:
> 
> <http://cvs.sourceforge.net/viewcvs.py/*checkout*/module-build/Module-Build/lib/Module/Build/Base.pm?rev=1.227> 
> 
> 
> and save it to <perl-directory>/site/lib/Module/Build/Base.pm
> 
>> Creating new 'Build' script for 'Module-Build' version '0.21_01'
>>
>> Pressing forward....
>>
>> Using the new M::B, per above install, the .tar.gz file still contains 
>> no directories, and still produces "Unable to add file" warnings for 
>> each directory that should be in there.
> 
> 
> What did you use to untar it? 

I have PowerArchiver 2001, and I have an binary tar.exe that was 
distributed sometime back around when Windows NT 4.0 came out.  Neither 
of those can see the directory structure.

> Did you try ptar? 

Couldn't find ptar in the A::T distribution.  There is a reference in 
the README to ptar in release 0.71, but I don't see it in the release 
1.07 at all.

> As I said the warning is
> a false warning. We've seen this before, and the problem is that
> different programs vary in the way they read the tar format. The files
> are correctly stored with directory information. I've trace through the
> code and verified it. Hopefully, the next version of Archive::Tar will
> be more compatible with other tools.

Yeah, hopefully.  How can it be named Tar if it isn't compatible?

>> And build ppd still complains about the lack of the codebase argument.
> 
> 
> have you tried:
> 
> perl Build ppd codebase="."

Lots of messages flying around, it gets confusing.  I answered this in 
another branch of this thread, so won't repeat it here.

> 
>> I guess I can't tell much difference between 0.21 and 0.21_01 :(  And 
>> was hoping for a miracle :)
>>
> 
> Let us know if any of this helps.

Lots of it helps, I appreciate the quick responses.  Unfortunately, we 
are not quite there yet.... but getting closer!

-- 
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?

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

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.

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

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

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 &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 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.

Re: [Module::Build] M::B - the developer snapshot

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

On 12/19/2003 3:44 AM, Glenn Linderman wrote:

> In attempting to install the developer snapshot as Randy Sims suggested,
> I got the following, confidence-decreasing :) error on the first step!
> 
> D:\Module-Build-0.21_01>perl build.pl
> Checking whether your kit is complete...
> Looks good
>  * Version <none> is installed, but we prefer to have 2.02
> ERRORS/WARNINGS FOUND IN PREREQUISITES.  You may wish to install the 
> versions
>  of the modules indicated above before proceeding with this installation.

This was already fixed by Ken in CVS. This is just a warning about an
optional module that M::B wants. If you don't have CVS just grab the
file from:

<http://cvs.sourceforge.net/viewcvs.py/*checkout*/module-build/Module-Build/lib/Module/Build/Base.pm?rev=1.227>

and save it to <perl-directory>/site/lib/Module/Build/Base.pm

> Creating new 'Build' script for 'Module-Build' version '0.21_01'
> 
> Pressing forward....
> 
> Using the new M::B, per above install, the .tar.gz file still contains 
> no directories, and still produces "Unable to add file" warnings for 
> each directory that should be in there.

What did you use to untar it? Did you try ptar? As I said the warning is
a false warning. We've seen this before, and the problem is that
different programs vary in the way they read the tar format. The files
are correctly stored with directory information. I've trace through the
code and verified it. Hopefully, the next version of Archive::Tar will
be more compatible with other tools.

> And build ppd still complains about the lack of the codebase argument.

have you tried:

perl Build ppd codebase="."

> I guess I can't tell much difference between 0.21 and 0.21_01 :(  And 
> was hoping for a miracle :)
> 

Let us know if any of this helps.

Regards,
Randy.

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

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

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.

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

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

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.

[Module::Build] M::B - the developer snapshot

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

In attempting to install the developer snapshot as Randy Sims suggested,
I got the following, confidence-decreasing :) error on the first step!

D:\Module-Build-0.21_01>perl build.pl
Checking whether your kit is complete...
Looks good
  * Version <none> is installed, but we prefer to have 2.02
ERRORS/WARNINGS FOUND IN PREREQUISITES.  You may wish to install the 
versions
  of the modules indicated above before proceeding with this installation.

Creating new 'Build' script for 'Module-Build' version '0.21_01'

Pressing forward....

Using the new M::B, per above install, the .tar.gz file still contains 
no directories, and still produces "Unable to add file" warnings for 
each directory that should be in there.

And build ppd still complains about the lack of the codebase argument.

I guess I can't tell much difference between 0.21 and 0.21_01 :(  And 
was hoping for a miracle :)

-- 
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/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.

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

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

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
=======================*/

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

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

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.

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

[Richard C. <ric...@un...>]

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...>

[Module::Build] Re: Module::Build ???

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

On 12/19/2003 1:22 AM, Glenn Linderman wrote:
> "perl build dist" produces errors, and "perl build ppd" produces errors:
> 
> D:\GFfP>perl build dist
> Couldn't load YAML.pm: Can't locate YAML.pm in @INC (@INC contains: 
> C:\Perl\lib C:\Perl\site\lib D:\GFfP) at 
> C:\Perl\site\lib/Module/Build/Base.pm line 1626.
> 
> mkdir GFfP-0.1
> mkdir GFfP-0.1/lib
> *** Did you forget to add META.yml to the MANIFEST?
> Creating GFfP-0.1.tar.gz
> Can't locate object method "create_archive" via package "Archive::Tar" 
> at C:\Perl\site\lib/Module/Build/Base.pm line 1706.
> 

Actually this part is a problem, and it should be handled better by 
Module::Build. I'm forwarding to the module-build mailing list as I 
haven't look to closely at the dist target.

I'm thinking it should not error if you don't have YAML installed. M::B 
aught to be able to produce the META.yml if YAML is not found.

I'll take a closer look when I get a chance.

Randy.

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

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

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.

Yours,
Ilya

P.S.  I did not try to fix other shortcomings of Module::Build, such as
      incompatibility of the generated Makefile.PL with builds in
      subdirectories.  Hmm, I remember I saw two architecture-independent
      problems; when I remember the other one, I will let you know...

--- ./MANIFEST-pre	Wed Oct 15 17:39:20 2003
+++ ./MANIFEST	Sun Dec 14 18:07:16 2003
@@ -22,6 +22,7 @@ lib/Module/Build/Platform/VOS.pm
 lib/Module/Build/Platform/Windows.pm
 lib/Module/Build/Platform/cygwin.pm
 lib/Module/Build/Platform/darwin.pm
+lib/Module/Build/Platform/os2.pm
 t/MANIFEST
 t/Sample/Build.PL
 t/Sample/MANIFEST
--- ./lib/Module/Build/Platform/os2.pm-pre	Sun Dec 14 18:06:42 2003
+++ ./lib/Module/Build/Platform/os2.pm	Sun Dec 14 18:06:16 2003
@@ -0,0 +1,46 @@
+package Module::Build::Platform::os2;
+
+use strict;
+use Module::Build::Platform::Unix;
+
+use vars qw(@ISA);
+@ISA = qw(Module::Build::Platform::Unix);
+
+sub link_c {
+  my ($self, $to, $file_base) = @_;
+  my ($cf, $p) = ($self->{config}, $self->{properties}); # For convenience
+  my $flags = $p->{extra_linker_flags};
+  local $p->{extra_linker_flags} = ['-L'.File::Spec->catdir($cf->{archlibexp}, 'CORE'),
+				    '-lperl',
+				    ref $flags ? @$flags : $self->split_like_shell($flags)];
+  return $self->SUPER::link_c($to, $file_base);
+}
+
+sub manpage_separator {
+   '.'
+}
+
+1;
+__END__
+
+
+=head1 NAME
+
+Module::Build::Platform::os2 - Builder class for OS/2 EMX platform
+
+=head1 DESCRIPTION
+
+This module provides some routines very specific to the OS/2 EMX
+platform.
+
+Please see the L<Module::Build> for the general docs.
+
+=head1 AUTHOR
+
+Initial stub by Ilya Zakharevich
+
+=head1 SEE ALSO
+
+perl(1), Module::Build(3), ExtUtils::MakeMaker(3)
+
+=cut

Re: [Module::Build] ANNOUNCE: 0.21_01

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

Thanks - this is now fixed in CVS.

  -Ken

On Wednesday, December 17, 2003, at 08:47  PM, drieux wrote:

>
> On Dec 17, 2003, at 6:25 AM, Ken Williams wrote:
>
>> http://sourceforge.net/project/ 
>> showfiles.php?group_id=45731&release_id=204435
>>
>>   or eventually:
>>
>> http://search.cpan.org/~kwilliams/Module-Build-0.21_01/
>>
> [..]
>
> I too ran into the <none>
>
> [jeeves: 7:] perl Bu*.PL
> Checking whether your kit is complete...
> Looks good
>  * Version <none> is installed, but we prefer to have 2.02
>  * Version <none> is installed, but we prefer to have 1.00
>  * Version <none> is installed, but we prefer to have 0.35
> ERRORS/WARNINGS FOUND IN PREREQUISITES.  You may wish to install the  
> versions
>  of the modules indicated above before proceeding with this  
> installation.
>
> Deleting Build
> Removed previous script 'Build'
> Creating new 'Build' script for 'Module-Build' version '0.21_01'
> [jeeves: 8:] perl Bu*.PL
> Checking whether your kit is complete...
> Looks good
>  * Optional prerequisite Archive::Tar isn't installed
>  * Optional prerequisite ExtUtils::ParseXS isn't installed
>  * Optional prerequisite YAML isn't installed
> ERRORS/WARNINGS FOUND IN PREREQUISITES.  You may wish to install the  
> versions
>  of the modules indicated above before proceeding with this  
> installation.
>
> Deleting Build
> Removed previous script 'Build'
> Creating new 'Build' script for 'Module-Build' version '0.21_01'
> [jeeves: 9:]
>
> I got that 'fixed' by editing the Build.pm
>
> [jeeves: 32:] diff -c Base.pm Base.pm.ORIG
> *** Base.pm     Wed Dec 17 18:43:56 2003
> --- Base.pm.ORIG        Wed Dec 17 18:32:30 2003
> ***************
> *** 627,634 ****
>     } else {
>       my $file = $self->find_module_by_name($modname, \@INC);
>       unless ($file) {
> !       @status{ qw(have message) } = ('', "Prerequisite $modname  
> isn't installed");
> !       #@status{ qw(have message) } = ('<none>', "Prerequisite  
> $modname isn't installed");
>         return \%status;
>       }
>
> --- 627,633 ----
>     } else {
>       my $file = $self->find_module_by_name($modname, \@INC);
>       unless ($file) {
> !       @status{ qw(have message) } = ('<none>', "Prerequisite  
> $modname isn't installed");
>         return \%status;
>       }
>
> [jeeves: 33:]
>
> seemed like the cleanest fix.
>
> I am running this on OSX 10.3.1
> with the default perl  v5.8.1-RC3 built for darwin-thread-multi-2level

Re: [Module::Build] create_readme =>1 doesn't cause README to be added to MANIFEST

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

On Monday, December 15, 2003, at 03:35  PM, Sagar Shah wrote:
> I agree with Michael's comments, but the use case where i hit this was
> where I don't even have a MANIFEST. I just use a MANIFEST.SKIP and have
> M::B create my MANIFEST for me.
>
> So you see, i cannot add README to the MANIFEST because i don't have a
> self made MANIFEST. create_readme doesn't cause the README to be 
> created
> before the MANIFEST is generated. So perhaps if you don't want
> create_readme to explicty insert README into MANIFEST, perhaps you can
> change the ordering of the actions slightly?
>
> That way users who do have a MANIFEST will not get surprised by extra
> additions. Whereas users with no MANIFEST, will 'get the right
> manifest'.
>
> Warming to the idea @ all?

Okay, y'all convinced me.  Could I get a patch from someone?  An 
add_to_manifest() method would be nice, it could also be used to handle 
the SIGNATURE file.

  -Ken

Re: [Module::Build] ANNOUNCE: 0.21_01

[drieux <dr...@we...>]

On Dec 17, 2003, at 6:25 AM, Ken Williams wrote:

> http://sourceforge.net/project/showfiles.php? 
> group_id=45731&release_id=204435
>
>   or eventually:
>
> http://search.cpan.org/~kwilliams/Module-Build-0.21_01/
>
[..]

I too ran into the <none>

[jeeves: 7:] perl Bu*.PL
Checking whether your kit is complete...
Looks good
  * Version <none> is installed, but we prefer to have 2.02
  * Version <none> is installed, but we prefer to have 1.00
  * Version <none> is installed, but we prefer to have 0.35
ERRORS/WARNINGS FOUND IN PREREQUISITES.  You may wish to install the  
versions
  of the modules indicated above before proceeding with this  
installation.

Deleting Build
Removed previous script 'Build'
Creating new 'Build' script for 'Module-Build' version '0.21_01'
[jeeves: 8:] perl Bu*.PL
Checking whether your kit is complete...
Looks good
  * Optional prerequisite Archive::Tar isn't installed
  * Optional prerequisite ExtUtils::ParseXS isn't installed
  * Optional prerequisite YAML isn't installed
ERRORS/WARNINGS FOUND IN PREREQUISITES.  You may wish to install the  
versions
  of the modules indicated above before proceeding with this  
installation.

Deleting Build
Removed previous script 'Build'
Creating new 'Build' script for 'Module-Build' version '0.21_01'
[jeeves: 9:]

I got that 'fixed' by editing the Build.pm

[jeeves: 32:] diff -c Base.pm Base.pm.ORIG
*** Base.pm     Wed Dec 17 18:43:56 2003
--- Base.pm.ORIG        Wed Dec 17 18:32:30 2003
***************
*** 627,634 ****
     } else {
       my $file = $self->find_module_by_name($modname, \@INC);
       unless ($file) {
!       @status{ qw(have message) } = ('', "Prerequisite $modname isn't  
installed");
!       #@status{ qw(have message) } = ('<none>', "Prerequisite  
$modname isn't installed");
         return \%status;
       }

--- 627,633 ----
     } else {
       my $file = $self->find_module_by_name($modname, \@INC);
       unless ($file) {
!       @status{ qw(have message) } = ('<none>', "Prerequisite $modname  
isn't installed");
         return \%status;
       }

[jeeves: 33:]

seemed like the cleanest fix.

I am running this on OSX 10.3.1
with the default perl  v5.8.1-RC3 built for darwin-thread-multi-2level

ciao
drieux