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

Re: [Module::Build] Ready for 0.22?

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

On 1/10/2004 11:53 AM, Randy Kobes wrote:

> On Sat, 10 Jan 2004, Randy W. Sims wrote:
> 
> [ ... ]
> 
>>I don't know why this is just now occuring to me (prolly
>>'cuz I don't use ppm), but ppm can use both .tar.gz
>>archives and .zip archives. If you look at the repository
>>at
>><http://ppm.activestate.com/PPMPackages/zips/8xx-builds-only/Windows/>
>>you'll see that all of them are .zip archives, so that's
>>the reason this issue has never come up before wrt ppm.
>>There are a couple of other repositories out there (Jenda
>>Krynicky's and Randy Kobes' though I don't remember the
>>urls); I suspect that they either use zips or use a
>>working version of tar to create their archives.
> 
> 
> Hopefully not to add too much to the confusion, but, at
> least for our repository, I use A::T on a Windows box to
> create the .tar.gz archives. So in principle A::T can be
> used exclusively to read/write .tar.gz files. Problems may
> arise when using different versions of A::T across different
> platforms - for example, I know of cases when a Win32 client
> can't extract an archive (using A::T) when that archive was
> created on a linux box (using A::T).
> 

I'm not sure what's going on at this point. Glenn is descibing two 
problems. 1) A::T produces a tar file that is incompatible with most 
Windows utilities (WinZip, PowerArchiver, etc.). This is confirmed, and 
I believe Jos is working on a fix. 2) Module::Build is used to create a 
dist and ppd file, ppm is run to install the dist which seems to work, 
but in fact, does not install anything. Until now I suspected this was 
related to (1) above, but your account seems to eliminate A::T as the 
culprit.

Have you had occasions to use M::B yet? (version 0.22 should be on CPAN 
by now;) Have you used it to create a dist? Have you run into any 
problems? You know much more about creating ppm distributions than I, so 
I (and many others) would be gratefull for any help or suggestions.

Thanks,
Randy.

Re: [Module::Build] Re: CBuilder vs Windows update

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

On 1/10/2004 7:09 PM, Ken Williams wrote:

> Excellent, I've applied it and released a beta 0.00_03.  If you let me 
> know that it works okay on Win32, I'll make it a 0.01.

A small fix to a big bug that slipped past me in EU::CBuilder:

$ diff -u0 Windows.pm-orig Windows.pm
--- Windows.pm-orig     2004-01-10 11:53:03.000000000 -0500
+++ Windows.pm  2004-01-11 06:34:41.000000000 -0500
@@ -98 +98 @@
-    objects       => @objects,
+    objects       => \@objects,

With this patch, everything passes for perl 5.6.1 & 5.8.x for all 
compilers on Windows & cygwin. (M::B-0.22 passes all tests as well).

I really need to start reviewing my patches more thoroughly...

Randy.

Re: [Module::Build] Ready for 0.22?

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

On approximately 1/10/2004 12:44 AM, came the following characters from
the keyboard of Randy W. Sims:
> On 1/10/2004 12:18 AM, Glenn Linderman wrote:
> 
>> On approximately 1/9/2004 3:27 PM, came the following characters from
>> the keyboard of Ken Williams:
>>
>>>  - The 'dist' action now accepts an optional 'tar' parameter to use a
>>>    system utility for building the tarball, and a 'gzip' parameter for
>>>    compressing it.  If these are used, Archive::Tar won't be invoked.
>>>
>>> The idea is that people who still can't get Archive::Tar to work 
>>> might have some other alternative, like a Cygwin tar/gzip or whatever.
>>
>>
>>
>> Yep, that sounds useful as a workaround to dysfunctional Archive::Tar 
>> releases.  If PPM can deal with such, and I suspect it can, as I guess 
>> that is why modules built with MakeMaker don't have that problem... 
>> they pretty much require having a TAR and GZIP program on the box.  
>> And PPM can deal with MakeMaker built modules.
>>
>> I really don't understand how, if PPM uses A::T to dearchive modules, 
>> why M::B using A::T to archive the modules in the first place wouldn't 
>> work, but that seems to be the way it is at the moment.  But I don't 
>> know how PPM really dearchives modules, or maybe A::T is more robust 
>> at dearchiving than it is at archiving.
> 
> 
> I don't know why this is just now occuring to me (prolly 'cuz I don't 
> use ppm), but ppm can use both .tar.gz archives and .zip archives. If 
> you look at the repository at 
> <http://ppm.activestate.com/PPMPackages/zips/8xx-builds-only/Windows/> 
> you'll see that all of them are .zip archives, so that's the reason this 
> issue has never come up before wrt ppm. There are a couple of other 
> repositories out there (Jenda Krynicky's and Randy Kobes' though I don't 
> remember the urls); I suspect that they either use zips or use a working 
> version of tar to create their archives.

I think the PPMPackages URL you reference above simply has the .tar.gz 
file, and the .ppd files, packaged together into a .zip file, for 
slightly simpler downloading for people that want to make their own 
installation repository without depending on being on-line during 
installations.  So while I am not knowledgable enough to confirm or deny 
whether ppm can or cannot use .zip archives, I don't think the 
referenced URL supports the theory.

> MakeMaker has a zipdist target in addition to the regular dist target. I 
>  personally don't see the value in providing support for another format. 
> FWIW, I believe M::B shouldn't try to do more than it absolutely has to 
> so that it stays simple and easy to maintain and port. If/When a plugin 
> architecture is adopted for M::B, someone could easily add a zipdist 
> target as an addon as well as other ActiveState specific stuff like 
> their custom html man pages, etc. Or it may be possible to use the new 
> 'tar' and 'gzip' arguments to fool M::B into creating a zip, but I 
> haven't tried it yet.
> 
> Regards,
> Randy.

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [Module::Build] Re: CBuilder vs Windows update

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

On Saturday, January 10, 2004, at 09:22  AM, Randy W. Sims wrote:

> On 1/9/2004 12:34 PM, Ken Williams wrote:
>> Nah, you can send them whenever.  I do have a CVS repository already, 
>> just not a public one.  I'll import the full history when I do the 
>> switchover, so nothing will really be lost.
>
> This patch just attempts to get CBuilder working on Windows. I also 
> went ahead and changed the method names as we talked about. Still 
> needs work before integrating, but atleast this will allow a beta 
> release that works on Windows.

Excellent, I've applied it and released a beta 0.00_03.  If you let me 
know that it works okay on Win32, I'll make it a 0.01.

  -Ken

Re: [Module::Build] Ready for 0.22?

[Randy K. <ra...@th...>]

On Sat, 10 Jan 2004, Randy W. Sims wrote:

[ ... ]
> I don't know why this is just now occuring to me (prolly
> 'cuz I don't use ppm), but ppm can use both .tar.gz
> archives and .zip archives. If you look at the repository
> at
> <http://ppm.activestate.com/PPMPackages/zips/8xx-builds-only/Windows/>
> you'll see that all of them are .zip archives, so that's
> the reason this issue has never come up before wrt ppm.
> There are a couple of other repositories out there (Jenda
> Krynicky's and Randy Kobes' though I don't remember the
> urls); I suspect that they either use zips or use a
> working version of tar to create their archives.

Hopefully not to add too much to the confusion, but, at
least for our repository, I use A::T on a Windows box to
create the .tar.gz archives. So in principle A::T can be
used exclusively to read/write .tar.gz files. Problems may
arise when using different versions of A::T across different
platforms - for example, I know of cases when a Win32 client
can't extract an archive (using A::T) when that archive was
created on a linux box (using A::T).

-- 
best regards,
randy

Re: [Module::Build] Re: CBuilder vs Windows update

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

On 1/9/2004 12:34 PM, Ken Williams wrote:
> Nah, you can send them whenever.  I do have a CVS repository already, 
> just not a public one.  I'll import the full history when I do the 
> switchover, so nothing will really be lost.

This patch just attempts to get CBuilder working on Windows. I also went 
ahead and changed the method names as we talked about. Still needs work 
before integrating, but atleast this will allow a beta release that 
works on Windows.

Randy.

Re: [Module::Build] Ready for 0.22?

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

Thanks, applied.

  -Ken

On Saturday, January 10, 2004, at 02:10  AM, Randy W. Sims wrote:

> On 1/9/2004 12:29 PM, Ken Williams wrote:
>> Hey,
>> Any outstanding issues before I release 0.22 to CPAN?  If there's 
>> still a significant CVS lag, here's the list of changes since the 
>> last beta:
>
> I was hasty and didn't run the test suite on that last patch I sent to 
> fix the PPD stuff. This patch adjusts t/xs.t to use the versioned 
> archname string produced by PPMMaker.pm (which incidentally probably 
> should've been named PPDMaker.pm :).
>
> $ diff -wu1 xs.t.orig xs.t
> --- xs.t.orig   2004-01-10 02:24:34.561038400 -0500
> +++ xs.t        2004-01-10 02:21:03.347328000 -0500
> @@ -51,2 +51,3 @@
>    my $perl_version = 
> Module::Build::PPMMaker->_ppd_version($m->perl_version);
> +  my $varchname = Module::Build::PPMMaker->_varchname($m->{config});
>
> @@ -63,3 +64,3 @@
>          <OS NAME="$^O" />
> -        <ARCHITECTURE NAME="$Config{archname}" />
> +        <ARCHITECTURE NAME="$varchname" />
>          <CODEBASE HREF="/path/to/codebase-xs" />
>

Re: [Module::Build] Ready for 0.22?

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

On Saturday, January 10, 2004, at 04:55  AM, Randy W. Sims wrote:

> I'm updating the meta statistics 
> <http://www.thepierianspring.org/meta.stats>, and seeing:
>
> generated_by: Module::Build version 0.22, without YAML.pm
>
> I was wondering about future variations on the above. For example, 
> when the YAML stuff goes into CPAN::META::Specification.pm or 
> whatever, what will the above line say. Maybe:
>
> generated_by: Module::Build version 0.22, via 
> CPAN::META::Specification version 0.01

I think we ought to actually have that as a rigorous field, e.g.

  META_spec: 0.01

or

  META_spec: Foo::Company::META 0.01


I think the idea behind the "generated_by" field was something 
essentially human-readable, so people could figure out who was to blame 
if the generation went awry.

  -Ken

Re: [Module::Build] Ready for 0.22?

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

Thanks, applied.

  -Ken

On Saturday, January 10, 2004, at 04:13  AM, Randy W. Sims wrote:

> Name mismatch:
>
> $ diff -u0 Base.pm.orig Base.pm
> --- Base.pm.orig        2004-01-09 12:08:21.000000000 -0500
> +++ Base.pm     2004-01-10 05:10:58.000000000 -0500
> @@ -1631 +1631 @@
> -authored_by:
> +author:
>
>

Re: [Module::Build] Ready for 0.22?

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

I'm updating the meta statistics 
<http://www.thepierianspring.org/meta.stats>, and seeing:

generated_by: Module::Build version 0.22, without YAML.pm

I was wondering about future variations on the above. For example, when 
the YAML stuff goes into CPAN::META::Specification.pm or whatever, what 
will the above line say. Maybe:

generated_by: Module::Build version 0.22, via CPAN::META::Specification 
version 0.01

I'm just curious because I would like to be able to continue to easily 
parse the line for gathering statistics. Right now I just split 
/\s+version\s+/ to get the generator and version (see 
<http://www.thepierianspring.org/meta_stats.pl.html>), and the above is 
fine for parsing also--I just want to put my 2 cents in for following a 
fixed format that allows for future variations and that is going to be 
easily parsable.

Randy.

Re: [Module::Build] Ready for 0.22?

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

Name mismatch:

$ diff -u0 Base.pm.orig Base.pm
--- Base.pm.orig        2004-01-09 12:08:21.000000000 -0500
+++ Base.pm     2004-01-10 05:10:58.000000000 -0500
@@ -1631 +1631 @@
-authored_by:
+author:

Re: [Module::Build] Ready for 0.22?

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

On 1/10/2004 12:18 AM, Glenn Linderman wrote:

> On approximately 1/9/2004 3:27 PM, came the following characters from
> the keyboard of Ken Williams:
> 
>>  - The 'dist' action now accepts an optional 'tar' parameter to use a
>>    system utility for building the tarball, and a 'gzip' parameter for
>>    compressing it.  If these are used, Archive::Tar won't be invoked.
>>
>> The idea is that people who still can't get Archive::Tar to work might 
>> have some other alternative, like a Cygwin tar/gzip or whatever.
> 
> 
> Yep, that sounds useful as a workaround to dysfunctional Archive::Tar 
> releases.  If PPM can deal with such, and I suspect it can, as I guess 
> that is why modules built with MakeMaker don't have that problem... they 
> pretty much require having a TAR and GZIP program on the box.  And PPM 
> can deal with MakeMaker built modules.
> 
> I really don't understand how, if PPM uses A::T to dearchive modules, 
> why M::B using A::T to archive the modules in the first place wouldn't 
> work, but that seems to be the way it is at the moment.  But I don't 
> know how PPM really dearchives modules, or maybe A::T is more robust at 
> dearchiving than it is at archiving.

I don't know why this is just now occuring to me (prolly 'cuz I don't 
use ppm), but ppm can use both .tar.gz archives and .zip archives. If 
you look at the repository at 
<http://ppm.activestate.com/PPMPackages/zips/8xx-builds-only/Windows/> 
you'll see that all of them are .zip archives, so that's the reason this 
issue has never come up before wrt ppm. There are a couple of other 
repositories out there (Jenda Krynicky's and Randy Kobes' though I don't 
remember the urls); I suspect that they either use zips or use a working 
version of tar to create their archives.

MakeMaker has a zipdist target in addition to the regular dist target. I 
  personally don't see the value in providing support for another 
format. FWIW, I believe M::B shouldn't try to do more than it absolutely 
has to so that it stays simple and easy to maintain and port. If/When a 
plugin architecture is adopted for M::B, someone could easily add a 
zipdist target as an addon as well as other ActiveState specific stuff 
like their custom html man pages, etc. Or it may be possible to use the 
new 'tar' and 'gzip' arguments to fool M::B into creating a zip, but I 
haven't tried it yet.

Regards,
Randy.

Re: [Module::Build] Ready for 0.22?

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

On 1/9/2004 12:29 PM, Ken Williams wrote:
> Hey,
> 
> Any outstanding issues before I release 0.22 to CPAN?  If there's still 
> a significant CVS lag, here's the list of changes since the last beta:

I was hasty and didn't run the test suite on that last patch I sent to 
fix the PPD stuff. This patch adjusts t/xs.t to use the versioned 
archname string produced by PPMMaker.pm (which incidentally probably 
should've been named PPDMaker.pm :).

$ diff -wu1 xs.t.orig xs.t
--- xs.t.orig   2004-01-10 02:24:34.561038400 -0500
+++ xs.t        2004-01-10 02:21:03.347328000 -0500
@@ -51,2 +51,3 @@
    my $perl_version = 
Module::Build::PPMMaker->_ppd_version($m->perl_version);
+  my $varchname = Module::Build::PPMMaker->_varchname($m->{config});

@@ -63,3 +64,3 @@
          <OS NAME="$^O" />
-        <ARCHITECTURE NAME="$Config{archname}" />
+        <ARCHITECTURE NAME="$varchname" />
          <CODEBASE HREF="/path/to/codebase-xs" />

Re: [Module::Build] Ready for 0.22?

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

On approximately 1/9/2004 3:27 PM, came the following characters from
the keyboard of Ken Williams:

> 
> On Friday, January 9, 2004, at 04:24  PM, Glenn Linderman wrote:
> 
>> On approximately 1/9/2004 9:29 AM, came the following characters from
>> the keyboard of Ken Williams:
>>
>>> Hey,
>>> Any outstanding issues before I release 0.22 to CPAN?
>>
>>
>> Well, I still haven't been able to do a PPM install of a M::B built 
>> distribution for a trivial XS module.  But whether that is 
>> Module::Build, Archive::Tar, or PPM I have no clue.  And yes, this is 
>> with 0.21_02.  But I think you are aware of this one, and it may not 
>> be a showstopper for M::B 0.22 ... although until it is resolved, we 
>> won't really know where the bug is.
> 
> 
> Oh sorry, I left one item out of the "Changes" list:
> 
>  - The 'dist' action now accepts an optional 'tar' parameter to use a
>    system utility for building the tarball, and a 'gzip' parameter for
>    compressing it.  If these are used, Archive::Tar won't be invoked.
> 
> The idea is that people who still can't get Archive::Tar to work might 
> have some other alternative, like a Cygwin tar/gzip or whatever.

Yep, that sounds useful as a workaround to dysfunctional Archive::Tar 
releases.  If PPM can deal with such, and I suspect it can, as I guess 
that is why modules built with MakeMaker don't have that problem... they 
pretty much require having a TAR and GZIP program on the box.  And PPM 
can deal with MakeMaker built modules.

I really don't understand how, if PPM uses A::T to dearchive modules, 
why M::B using A::T to archive the modules in the first place wouldn't 
work, but that seems to be the way it is at the moment.  But I don't 
know how PPM really dearchives modules, or maybe A::T is more robust at 
dearchiving than it is at archiving.

> There are also changes since 0.21_02 in how the PPD file is built, I 
> think those address your other concerns.

Yep, my other concerns with M::B have been quickly and competently 
addressed, even the one that slipped through the cracks until yesterday 
(there were lots of issues, so I understand it is easy to miss one or 
two on the first round).  I appreciate all the efforts that have been 
expended to assist me in building my first module with M::B.

>  -Ken

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [Module::Build] Ready for 0.22?

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

On Friday, January 9, 2004, at 04:24  PM, Glenn Linderman wrote:

> On approximately 1/9/2004 9:29 AM, came the following characters from
> the keyboard of Ken Williams:
>> Hey,
>> Any outstanding issues before I release 0.22 to CPAN?
>
> Well, I still haven't been able to do a PPM install of a M::B built 
> distribution for a trivial XS module.  But whether that is 
> Module::Build, Archive::Tar, or PPM I have no clue.  And yes, this is 
> with 0.21_02.  But I think you are aware of this one, and it may not 
> be a showstopper for M::B 0.22 ... although until it is resolved, we 
> won't really know where the bug is.

Oh sorry, I left one item out of the "Changes" list:

  - The 'dist' action now accepts an optional 'tar' parameter to use a
    system utility for building the tarball, and a 'gzip' parameter for
    compressing it.  If these are used, Archive::Tar won't be invoked.

The idea is that people who still can't get Archive::Tar to work might 
have some other alternative, like a Cygwin tar/gzip or whatever.

There are also changes since 0.21_02 in how the PPD file is built, I 
think those address your other concerns.

  -Ken

Re: [Module::Build] Ready for 0.22?

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

On approximately 1/9/2004 9:29 AM, came the following characters from
the keyboard of Ken Williams:
> Hey,
> 
> Any outstanding issues before I release 0.22 to CPAN?

Well, I still haven't been able to do a PPM install of a M::B built 
distribution for a trivial XS module.  But whether that is 
Module::Build, Archive::Tar, or PPM I have no clue.  And yes, this is 
with 0.21_02.  But I think you are aware of this one, and it may not be 
a showstopper for M::B 0.22 ... although until it is resolved, we won't 
really know where the bug is.

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [Module::Build] notes on notes

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

On Thursday, January 8, 2004, at 07:05  PM, Randy W. Sims wrote:
>
> Aw, no one commented on all the question marks in an answer script. I 
> thought it was at least worth a grin... <g>

I grinned, but only in the privacy of my own home. ;-)

Let's keep this topic open for the new release track 0.23.

  -Ken

Re: [Module::Build] Archive::Tar file format

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

On Wednesday, January 7, 2004, at 03:08  AM, Jos I. Boumans wrote:

>
> On 7-jan-04, at 3:35, Glenn Linderman wrote:
>
>> 2) Most TAR decoding programs cannot see the PATH data, although the 
>> latest GNU TAR can
>
> yes, apparently (especially on windows) there's many clients that 
> follow an old(er) spec. Although i am still of the same opinion that 
> these clients are just inherintly broken ...

Let me reiterate that these clients are *NOT* IMO broken.  They 
implement the TAR spec, at the time of their writing, correctly.

The broken thing seems to be the updated TAR spec, which changed in 
such a way that any archive that uses the new features won't work with 
old clients.  That's really a terrible thing to do to a "standard".

  -Ken

Re: [Module::Build] bug in ExtUtils/Install.pm

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

On Wednesday, January 7, 2004, at 01:41  AM, Uri Guttman wrote:

>
> anyone ever see this before?
>
> Useless use of a variable in void context at 
> /usr/local/lib/perl5/5.6.1/ExtUtils/Install.pm line 267.
>
> the line of code is:
>
>     local *SRC, *CMD;

Yeah, I think I was actually the one that patched that line. =)

  -Ken

Re: [Module::Build] [PATCH] Write minimal META.yml unless -e YAML.pm

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

On Sunday, January 4, 2004, at 01:24  AM, Randy W. Sims wrote:

> On 1/4/2004 12:44 AM, Ken Williams wrote:
>> Do we want $self->{dist_author} to always be an array ref, or always 
>> be however the user specified it?  I'm thinking the latter, but I'm 
>> not sure.
>
> I think it has to accept either. For backwards compatibility it needs 
> to accept a single string, and that's what will probably be used most 
> often anyway, so it's convenient. I think it should also accept an 
> array reference because many projects are developed by teams, and its 
> easy and makes sense to allow for that.

Yeah, I agree - my question was about what dist_author() should output, 
not what it should accept as input.  I've checked in a version of the 
patch that accepts an arrayref or string, and outputs an arrayref, just 
as yours did (I think).

You may want to take a quick look over the patches I put in today & 
yesterday, to make sure I didn't make any boneheaded changes.  Let me 
know if so.

  -Ken

Re: [Module::Build] Re: CBuilder vs Windows update

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

On Thursday, January 8, 2004, at 07:55  PM, Randy W. Sims wrote:

> On 1/4/2004 12:12 AM, Ken Williams wrote:
>
>> I've got a new (well, actually about 10 years old) machine in my 
>> basement that I'm going to set up, among other things, as a project 
>> server for stuff like this.  All my modules will have accessible 
>> CVS/Perforce/Subversion/whatever repositories on it so we can work a 
>> little more effectively on stuff like this.
>
> Ken, do you want me to wait until you get setup before I start posting 
> patches for CBuilder?
>

Nah, you can send them whenever.  I do have a CVS repository already, 
just not a public one.  I'll import the full history when I do the 
switchover, so nothing will really be lost.

It's taking longer than anticipated to get the thing set up, due to (I 
think) flaky hardware and shoddily built 3rd-party network drivers.  Or 
something.

  -Ken

[Module::Build] Ready for 0.22?

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

Hey,

Any outstanding issues before I release 0.22 to CPAN?  If there's still 
a significant CVS lag, here's the list of changes since the last beta:


  - When building a 'traditional' Makefile.PL with
    Module::Build::Compat, we now use 'VERSION_FROM' when possible,
    rather than always using 'VERSION'.  This way the Makefile.PL
    doesn't have to get modified every release.

  - Made some fixups to the 'PPM' info-file that improve compatibility
    with ActiveState's PPM tools. [Randy Sims, Glenn Linderman]

  - The 'dist_author' property can now accept multiple authors, see the
    docs for more info. [Randy Sims]

  - If the user doesn't have YAML.pm installed during ACTION_dist, we
    now create a minimal YAML.pm anyway, without any dependency
    information.

  - The 'distribution_type' field is no longer created in META.yml
    files, in accordance with the finding made at the London CLPAN
    meeting that it's essentially meaningless and ill-defined.


Versions 0.21_01 and 0.21_02 had significant bug fixes, particularly 
for the Windows crowd, so I'd like to get 0.22 out as soon as it makes 
sense.

  -Ken

Re: [Module::Build] Re: CBuilder vs Windows update

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

On 1/4/2004 12:12 AM, Ken Williams wrote:

> I've got a new (well, actually about 10 years old) machine in my 
> basement that I'm going to set up, among other things, as a project 
> server for stuff like this.  All my modules will have accessible 
> CVS/Perforce/Subversion/whatever repositories on it so we can work a 
> little more effectively on stuff like this.

Ken, do you want me to wait until you get setup before I start posting 
patches for CBuilder?

Randy.

Re: [Module::Build] notes on notes

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

On 1/1/2004 11:19 PM, Randy W. Sims wrote:

> Example:
> 
> ?? interactive
> ?? no_clobber
> John Doe
> jd...@so...
> y
> ?? force Hello, World!
> ?? # store these so we don't have to look em up again.
> ?? set ftp = /usr/local/bin/ncftp
> ?? set cc = /usr/bin/gcc
> ?? eof
> 
> 
> Answer script format:
> 
> Each line represent an answer to a fixed sequence of prompts unless the 
> line begins with '??' in which case it is a command or flag.

Aw, no one commented on all the question marks in an answer script. I 
thought it was at least worth a grin... <g>

Randy.

Re: [Module::Build] Archive::Tar file format

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

On approximately 1/7/2004 9:15 PM, came the following characters from
the keyboard of Randy W. Sims:

> On 1/8/2004 12:04 AM, Randy W. Sims wrote:
> 
>> +sub _varchname {
>> +# copied from PPM.pm
>> +  my $varchname = $Config{archname};
>> +  # Append "-5.8" to architecture name for Perl 5.8 and later
>> +  if (length($^V) && ord(substr($^V,1)) >= 8) {
>> +    $varchname .= sprintf("-%d.%d", ord($^V), ord(substr($^V,1)));
>> +  }
>> +}
> 
> 
> Of course there should be a return $varchname at the end of that sub.

So the patch.bat in Perl Power Tools 0.12 seemed to do the job... but 
produced a bunch of funny warnings about printing to a NULL filehandle. 
  Anyway, diff -u on the results reproduced the original patch, so I 
think it did the desired patching.  Then I added the return, and rebuilt 
the .ppd.  Seems to be acceptable to PPM now.

OF course, PPM still doesn't do anything... this version didn't even 
talk about file 14/14.

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.