Thread: [Module::Build] Ready for 0.22?
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
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: 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-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-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: 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 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: 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: 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 K. <ra...@th...> - 2004-01-12 17:04:32
|
On Sun, 11 Jan 2004, Randy W. Sims wrote: > 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. I think this may be a problem between versions of Archive::Tar mixed in with some OS considerations. For example, - using either A::T version 1.04 or 1.08 on a linux machine to create an archive, I find on a Windows machine that A::T version 0.072 (that comes with ActivePerl 806) has problems with it. The same archive is read fine on the linux machine using A::T, and can also be read on the Windows machine using cygwin tar/gzip, but Winzip has problems opening it. However, if I upgrade A::T on the Windows machine to 1.08, the archive can be read. - using the system tar/gzip on the linux machine to create an archive, both A::T versions 0.072 and 1.08 on the Windows machine can read it, as can cygwin tar/gzip and Winzip. - using either A::T version 0.072 or 1.08 on the Windows machine to create an archive, both A::T versions on the Windows machine can read it, as can cygwin tar/gzip and Winzip, and also there's no problems reading it on the linux box using either A::T or the system tar/gzip. > 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. Yes, I have used M::B (which is great!) in this context, and have run into these problems. It gets messy, but for creating ppm archives that would be compatible with older Win32 ActivePerls (that use, eg A::T version 0.072), what one might do is, - if it's being built on Win32, use A::T (with perhaps a recommendation to upgrade to A::T 1.08, in order to read other A::T archives), - if it's being built on Unix, and it's intended for Win32, use the system tar/gzip to create the archive, unless one can assume that A::T on the client can be upgraded to 1.08. This latter thing is tricky to do, as A::T is used by ppm, and so is designated as a "precious" package; I thought ppm could upgrade such packages via ppm> upgrade -install -precious but at least with my ActivePerl 806 that doesn't seem to work. -- best 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: 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: 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: 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: 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: Mathieu A. <ma...@Fr...> - 2004-01-13 13:48:55
|
+-le 09/01/2004 11:29 -0600, Ken Williams =E9crivait :
| Hey,
|=20
| 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:
|=20
|=20
| - 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.
|=20
| - Made some fixups to the 'PPM' info-file that improve compatibility
| with ActiveState's PPM tools. [Randy Sims, Glenn Linderman]
|=20
| - The 'dist_author' property can now accept multiple authors, see the
| docs for more info. [Randy Sims]
|=20
| - If the user doesn't have YAML.pm installed during ACTION_dist, we
| now create a minimal YAML.pm anyway, without any dependency
| information.
|=20
| - 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.
|=20
|=20
| 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.
I was on my way updating the FreeBSD's port to 0.22 and I ran into a
problem, Module::Build now needed gmake to build, now, I know, gmake should
be installed on almost every FreeBSD system, but well, why bother when only
a one line patch like can have make work instead :
--- lib/Module/Build/Compat.pm~ Sun Jan 11 05:19:59 2004
+++ lib/Module/Build/Compat.pm Tue Jan 13 14:44:22 2004
@@ -144,7 +144,7 @@
$perl -e unlink -e shift $makefile
force_do_it :
- @
+
EOF
# XXX - user might be using a different subclass
now, I'm not a great make expert, and I don't really know why this "@" was
there anyway, but with, it only works with gmake, and without, it works
with our make, so...
If I'm doing anything stupid with this patch, please, let me know :)
--=20
Mathieu Arnold |
|
From: Ken W. <ke...@ma...> - 2004-01-13 22:31:51
|
On Tuesday, January 13, 2004, at 07:48 AM, Mathieu Arnold wrote: > I was on my way updating the FreeBSD's port to 0.22 and I ran into a > problem, Module::Build now needed gmake to build, now, I know, gmake > should > be installed on almost every FreeBSD system, but well, why bother when > only > a one line patch like can have make work instead : > > --- lib/Module/Build/Compat.pm~ Sun Jan 11 05:19:59 2004 > +++ lib/Module/Build/Compat.pm Tue Jan 13 14:44:22 2004 > @@ -144,7 +144,7 @@ > $perl -e unlink -e shift $makefile > > force_do_it : > - @ > + > EOF I don't know the proper answer here - a previous patch had me put the '@' *in* the file, for much the same reason (doing so made it work with more 'make' tools, supposedly...). Anyone able to sort this out? -Ken |
|
From: Nicholas C. <ni...@cc...> - 2004-01-13 23:09:22
|
On Tue, Jan 13, 2004 at 04:31:43PM -0600, Ken Williams wrote: > > On Tuesday, January 13, 2004, at 07:48 AM, Mathieu Arnold wrote: > >I was on my way updating the FreeBSD's port to 0.22 and I ran into a > >problem, Module::Build now needed gmake to build, now, I know, gmake > >should > >be installed on almost every FreeBSD system, but well, why bother when > >only > >a one line patch like can have make work instead : > > > >--- lib/Module/Build/Compat.pm~ Sun Jan 11 05:19:59 2004 > >+++ lib/Module/Build/Compat.pm Tue Jan 13 14:44:22 2004 > >@@ -144,7 +144,7 @@ > > $perl -e unlink -e shift $makefile > > > > force_do_it : > >- @ > >+ > > EOF > > I don't know the proper answer here - a previous patch had me put the > '@' *in* the file, for much the same reason (doing so made it work with > more 'make' tools, supposedly...). > > Anyone able to sort this out? Off the top of my head, @ will mean "don't echo the command" There is no command after it, so I guess one system's make was happy with that but didn't like that rule to build force_do_it not having and "commands", whereas FreeBSD make doesn't mind there being no commands, but doesn't like a no-echo of "" Does @/bin/true make everybody happy? [or @$(NOOP) assuming that there is a NOOP macro defined earlier in the Makefile] Nicholas Clark |
|
From: Dave R. <au...@ur...> - 2004-01-13 23:16:29
|
On Tue, 13 Jan 2004, Nicholas Clark wrote: > > Does > > @/bin/true > > make everybody happy? I'm sure that Windows will not like this ;) -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-13 23:24:19
|
On 1/13/2004 6:09 PM, Nicholas Clark wrote: > On Tue, Jan 13, 2004 at 04:31:43PM -0600, Ken Williams wrote: > >>On Tuesday, January 13, 2004, at 07:48 AM, Mathieu Arnold wrote: >> >>>I was on my way updating the FreeBSD's port to 0.22 and I ran into a >>>problem, Module::Build now needed gmake to build, now, I know, gmake >>>should >>>be installed on almost every FreeBSD system, but well, why bother when >>>only >>>a one line patch like can have make work instead : >>> >>>--- lib/Module/Build/Compat.pm~ Sun Jan 11 05:19:59 2004 >>>+++ lib/Module/Build/Compat.pm Tue Jan 13 14:44:22 2004 >>>@@ -144,7 +144,7 @@ >>> $perl -e unlink -e shift $makefile >>> >>>force_do_it : >>>- @ >>>+ >>>EOF >> >>I don't know the proper answer here - a previous patch had me put the >>'@' *in* the file, for much the same reason (doing so made it work with >>more 'make' tools, supposedly...). >> >>Anyone able to sort this out? > > > Off the top of my head, @ will mean "don't echo the command" > There is no command after it, so I guess one system's make was happy with > that but didn't like that rule to build force_do_it not having and > "commands", whereas FreeBSD make doesn't mind there being no commands, > but doesn't like a no-echo of "" > > Does > > @/bin/true > > make everybody happy? Unfortunately, 'true' is not available out of the box on some systems. > [or @$(NOOP) > assuming that there is a NOOP macro defined earlier in the Makefile] $(NOOP) is not available. MakeMaker uses a $(NOOP) variable, but it differs by OS. It would be nice to find a universal noop. I wonder if '@cd .' or "@cd File::Spec->curdir()" is universal? I know it works on *nix, Windows, OS/2. I'm not sure about VMS and the like. Randy. |
|
From: Ken W. <ke...@ma...> - 2004-01-13 23:33:18
|
On Tuesday, January 13, 2004, at 05:23 PM, Randy W. Sims wrote:
>
> $(NOOP) is not available. MakeMaker uses a $(NOOP) variable, but it
> differs by OS. It would be nice to find a universal noop. I wonder if
> '@cd .' or "@cd File::Spec->curdir()" is universal? I know it works on
> *nix, Windows, OS/2. I'm not sure about VMS and the like.
'cd' always makes me a little edgy.
Maybe something like this?
my $os_type = Module::Build->os_type;
my $noop = ($os_type eq 'Windows' ? 'rem' :
$os_type eq 'VMS' ? 'Continue' :
'true');
That's basically what MakeMaker does.
Or do you mean 'true' isn't even available on some Unix systems?
-Ken
|
|
From: Randy W. S. <Ra...@Th...> - 2004-01-13 23:42:38
|
On 1/13/2004 6:32 PM, Ken Williams wrote: > > On Tuesday, January 13, 2004, at 05:23 PM, Randy W. Sims wrote: > >> >> $(NOOP) is not available. MakeMaker uses a $(NOOP) variable, but it >> differs by OS. It would be nice to find a universal noop. I wonder if >> '@cd .' or "@cd File::Spec->curdir()" is universal? I know it works on >> *nix, Windows, OS/2. I'm not sure about VMS and the like. > > > 'cd' always makes me a little edgy. > > Maybe something like this? > > my $os_type = Module::Build->os_type; > my $noop = ($os_type eq 'Windows' ? 'rem' : > $os_type eq 'VMS' ? 'Continue' : > 'true'); > > That's basically what MakeMaker does. > > Or do you mean 'true' isn't even available on some Unix systems? 'true' should always be available on *nix. The above looks safe to me, but then I thought '@' was safe. Randy. |
|
From: Tony B. <to...@ka...> - 2004-01-14 01:15:35
|
> 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'm coming in late, so apologies if this has already changed, but AFAICS the current release doesn't document being able to specify a listref of test_files in your Build.PL. It mentions this as a command line arg, but I had to guess that you could also do it in Build.PL. I always hate relying on undocumented features so if this is a real one it would be nice if that was documented up with pm_files, pod_files, etc. As I'm using Test::Class, and my test are all in lib/My/Project/Test/*.pm, the normal t/*.t approach doesn't really work for me... Thanks, Tony |
|
From: Ken W. <ke...@ma...> - 2004-01-15 01:58:08
|
On Tuesday, January 13, 2004, at 07:15 PM, Tony Bowden wrote: >> 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'm coming in late, so apologies if this has already changed, but > AFAICS > the current release doesn't document being able to specify a listref > of test_files in your Build.PL. It mentions this as a command line arg, > but I had to guess that you could also do it in Build.PL. I always hate > relying on undocumented features so if this is a real one it would be > nice if that was documented up with pm_files, pod_files, etc. > > As I'm using Test::Class, and my test are all in > lib/My/Project/Test/*.pm, > the normal t/*.t approach doesn't really work for me... Ah - I guess the only reason this isn't documented is that it never occurred to me to use 'test_files' the way you're using it. I always use it as just a way to pick a certain t/*.t file for spot testing. But I can see how it's useful the way you're using it too. I'll add it to the docs for the next release, you can consider it stable. -Ken |
|
From: <mod...@tm...> - 2004-01-15 08:03:58
|
On Wed, Jan 14, 2004 at 07:57:58PM -0600, Ken Williams wrote: > >As I'm using Test::Class, and my test are all in > >lib/My/Project/Test/*.pm, > >the normal t/*.t approach doesn't really work for me... > Ah - I guess the only reason this isn't documented is that it never > occurred to me to use 'test_files' the way you're using it. I always > use it as just a way to pick a certain t/*.t file for spot testing. > But I can see how it's useful the way you're using it too. > I'll add it to the docs for the next release, you can consider it > stable. Great. Thanks, Tony |
Thanks for helping keep SourceForge clean.
X