module-build-general Mailing List for Module::Build (Page 140)
Status: Beta
Brought to you by:
kwilliams
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(24) |
Sep
(2) |
Oct
(18) |
Nov
(36) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(3) |
Feb
(96) |
Mar
(82) |
Apr
(63) |
May
(90) |
Jun
(52) |
Jul
(94) |
Aug
(89) |
Sep
(75) |
Oct
(118) |
Nov
(101) |
Dec
(111) |
| 2004 |
Jan
(159) |
Feb
(155) |
Mar
(65) |
Apr
(121) |
May
(62) |
Jun
(68) |
Jul
(54) |
Aug
(45) |
Sep
(78) |
Oct
(80) |
Nov
(271) |
Dec
(205) |
| 2005 |
Jan
(128) |
Feb
(96) |
Mar
(83) |
Apr
(113) |
May
(46) |
Jun
(120) |
Jul
(146) |
Aug
(47) |
Sep
(93) |
Oct
(118) |
Nov
(116) |
Dec
(60) |
| 2006 |
Jan
(130) |
Feb
(330) |
Mar
(228) |
Apr
(203) |
May
(97) |
Jun
(15) |
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Randy W. S. <Ra...@Th...> - 2004-01-11 13:51:09
|
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. |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-11 11:40:12
|
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. |
|
From: Glenn L. <pe...@ne...> - 2004-01-11 08:04:05
|
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. |
|
From: Ken W. <ke...@ma...> - 2004-01-11 00:09:48
|
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 |
|
From: Randy K. <ra...@th...> - 2004-01-10 16:55:13
|
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 |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-10 15:23:18
|
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. |
|
From: Ken W. <ke...@ma...> - 2004-01-10 14:59:23
|
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" />
>
|
|
From: Ken W. <ke...@ma...> - 2004-01-10 14:57:35
|
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 |
|
From: Ken W. <ke...@ma...> - 2004-01-10 14:54:36
|
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: > > |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-10 10:55:59
|
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. |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-10 10:13:17
|
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: |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-10 08:44:49
|
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. |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-10 08:10:23
|
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" />
|
|
From: Glenn L. <pe...@ne...> - 2004-01-10 05:18:57
|
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. |
|
From: Ken W. <ke...@ma...> - 2004-01-10 04:55:44
|
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
|
|
From: Glenn L. <pe...@ne...> - 2004-01-09 22:24:39
|
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. |
|
From: Ken W. <ke...@ma...> - 2004-01-09 18:03:13
|
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 |
|
From: Ken W. <ke...@ma...> - 2004-01-09 18:01:47
|
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 |
|
From: Ken W. <ke...@ma...> - 2004-01-09 17:56:54
|
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 |
|
From: Ken W. <ke...@ma...> - 2004-01-09 17:54:35
|
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
|
|
From: Ken W. <ke...@ma...> - 2004-01-09 17:34:21
|
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 |
|
From: Ken W. <ke...@ma...> - 2004-01-09 17:29:36
|
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
|
|
From: Randy W. S. <Ra...@Th...> - 2004-01-09 01:55:25
|
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. |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-09 01:05:53
|
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. |
|
From: Glenn L. <pe...@ne...> - 2004-01-08 06:42:28
|
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.
|