module-build-general Mailing List for Module::Build (Page 159)
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general — General discussion about Module::Build project
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: Dave R. <au...@ur...> - 2003-08-28 14:04:06
|
On Thu, 28 Aug 2003, Ken Williams wrote: > Actually, any distribution that includes a "passthrough" or "small" > Makefile.PL (as described in Module::Build::Compat) will also be built > by CPAN using Module::Build. However, there aren't many of those at > the moment on CPAN as far as I know. I have a bunch that do that, including DateTime::TimeZone, DateTime::Locale, DateTime::Format::MySQL, DateTime::Format::ICal, Log::Dispatch, Alzabo, and Thesaurus. The last one may have been the first module to ever use the passthrough Makefile.PL stuff. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Dave R. <au...@ur...> - 2003-08-28 14:02:32
|
On Thu, 28 Aug 2003, Michael G Schwern wrote: > AFAIK nobody's seriously tried patching CPAN.pm for Module::Build. I doubt > it would be easy. ACtually, I sent a patch for this to Andreas quite some time ago. I could send it again. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-08-28 13:51:14
|
On Thursday, August 28, 2003, at 03:43 AM, Soren A wrote:
> Aha. OK. Confession: how dumb I really do feel at this moment. I
> haven't
> been thinking about M::B for too long. So, ...
>
> When I wrote previously that "I tried Michael's patch with the first
> CPAN module that uses Module::Build that I could lay hands on, M::B
> it's
> self", that didn't make a lot od sense, did it? Actually, is it true as
> I now realize that *using good 'ol CPAN.pm*, the *only* package out
> there that's going to use Module::Build to build itself is
> Module::Build, itself ("Who's on First" -- whaa? that's what I'm
> asking,
> you dope, who's on first?")? because calling `make' is so hardwired in
> to CPAN.pm? It's always going to try to build modules the same way.
Actually, any distribution that includes a "passthrough" or "small"
Makefile.PL (as described in Module::Build::Compat) will also be built
by CPAN using Module::Build. However, there aren't many of those at
the moment on CPAN as far as I know.
> I used CPAN to fetch-prepare-install Ken's Path::Class a minute ago and
> the discomforting realization of my ignorance hit me. So are we just
> waiting for the world to shift to CPANPLUS? Hmmm, now I have to (after
> some sleep) hit the Fine Documentation.
What happened with Path::Class? It's got a normal Makefile.PL that
uses MakeMaker, so it should have worked fine with the 'verbose' flag
even before Schwern's patch.
-Ken
|
|
From: Michael G S. <sc...@po...> - 2003-08-28 10:28:27
|
On Thu, Aug 28, 2003 at 04:43:54AM -0400, Soren A wrote:
> Aha. OK. Confession: how dumb I really do feel at this moment. I haven't
> been thinking about M::B for too long. So, ...
>
> When I wrote previously that "I tried Michael's patch with the first
> CPAN module that uses Module::Build that I could lay hands on, M::B it's
> self", that didn't make a lot od sense, did it? Actually, is it true as
> I now realize that *using good 'ol CPAN.pm*, the *only* package out
> there that's going to use Module::Build to build itself is
> Module::Build, itself ("Who's on First" -- whaa? that's what I'm asking,
> you dope, who's on first?")? because calling `make' is so hardwired in
> to CPAN.pm? It's always going to try to build modules the same way.
AFAIK nobody's seriously tried patching CPAN.pm for Module::Build. I doubt
it would be easy.
> I used CPAN to fetch-prepare-install Ken's Path::Class a minute ago and
> the discomforting realization of my ignorance hit me. So are we just
> waiting for the world to shift to CPANPLUS?
Pretty much.
Fortunately the Module::Build Makefile.PL compatibility wrapper is pretty
good so its pretty moot.
--
Michael G Schwern sc...@po... http://www.pobox.com/~schwern/
If it's stupid, but it works, it isn't stupid.
|
|
From: Soren A <per...@wo...> - 2003-08-28 08:44:37
|
Aha. OK. Confession: how dumb I really do feel at this moment. I haven't
been thinking about M::B for too long. So, ...
When I wrote previously that "I tried Michael's patch with the first
CPAN module that uses Module::Build that I could lay hands on, M::B it's
self", that didn't make a lot od sense, did it? Actually, is it true as
I now realize that *using good 'ol CPAN.pm*, the *only* package out
there that's going to use Module::Build to build itself is
Module::Build, itself ("Who's on First" -- whaa? that's what I'm asking,
you dope, who's on first?")? because calling `make' is so hardwired in
to CPAN.pm? It's always going to try to build modules the same way.
I used CPAN to fetch-prepare-install Ken's Path::Class a minute ago and
the discomforting realization of my ignorance hit me. So are we just
waiting for the world to shift to CPANPLUS? Hmmm, now I have to (after
some sleep) hit the Fine Documentation.
Soren
|
|
From: Soren A <per...@wo...> - 2003-08-28 08:08:44
|
For future ref, it's ok, I don't need CC:s. Thanks all the same.
On Wed, Aug 27, 2003 at 08:40:14PM -0700, Michael G Schwern wrote:
{...}
> Module::Build should deal with the most common arguments one would put
> into something automated like the CPAN shell. verbose must have
> slipped by. Its a bit odd, it doesn't follow the convention of a lot
> of others.
Exactly. It's quite odd. It's the only argument that the ordinary
invocation takes, actually, AFAICR, that's just a single statement and
not a key-value pair.
> Here's a patch for it.
Looks good. Thanks, trying it now ... {much time elapsing} HUHHH, what a
stupid fellow I am. I tried it out on the most likely candidate I could
lay my hands on, M::B itself ...
Tried to just do a "get" to the CPAN build area in the CPAN shell, then
patch the file in-place. DON'T anybody else waste your time trying that.
After much fussing I decided that it must mess with `make' horribly,
upsetting by altering the file timestamps. With care I applied the patch
and let CPAN run 'test' and everything was fine.
At least I now have M::B in 5.8.0 as well as in 5.6.1, that's a plus.
Thanks for the patch, Michael. I dub thee Sir Insty-Patch.
Soren
|
|
From: Michael G S. <sc...@po...> - 2003-08-28 03:41:31
|
On Wed, Aug 27, 2003 at 10:41:19PM -0400, Soren A wrote:
> And that is a problem. IMHO, M::B and portability scripts which enable
> it's use from the traditional MakeMaker-based invocation `perl
> makefile.PL', *must* support or at least parse and accept without error,
> *all* the things that have been possible to pass as arguments to that
> familiar routine.
As the vast majority of the arguments Makefile.PL accept make no sense for
Module::Build, or are prohibitively complicated to backport, this will
never happen.
As for silently accepting old Makefile.PL commands which it does not
implement, this sounds sketchy. At minimum a warning should be issued.
I think an error is ok since, in my world, its better to stop working
then ignore user input and bull forward. Consider, for example,
the consequences of ignoring 'DESTDIR' or 'PREFIX'. But that's up to Ken.
Module::Build should deal with the most common arguments one would put
into something automated like the CPAN shell. verbose must have
slipped by. Its a bit odd, it doesn't follow the convention of a lot
of others.
Here's a patch for it.
--- lib/Module/Build/Compat.pm 2003/08/28 03:35:44 1.1
+++ lib/Module/Build/Compat.pm 2003/08/28 03:38:21
@@ -95,7 +95,13 @@
sub makefile_to_build_args {
shift;
my @out;
+ my $verbose = 0;
foreach my $arg (@_) {
+ if( $arg eq 'verbose' ) { # special case for verbose
+ $verbose++;
+ next;
+ }
+
my ($key, $val) = $arg =~ /^(\w+)=(.+)/ or die "Malformed argument '$arg'";
if (exists $Config{lc($key)}) {
push @out, 'config=' . lc($key) . "=$val";
@@ -107,6 +113,9 @@
push @out, "\L$key\E=$val";
}
}
+
+ push @out, "verbose=$verbose" if $verbose;
+
return @out;
}
--
Michael G Schwern sc...@po... http://www.pobox.com/~schwern/
I know you get this a lot, but what's an unholy fairy like you doing in a
mosque like this?
|
|
From: Soren A <per...@wo...> - 2003-08-28 02:42:04
|
Hi, Ken! and All,
Hope you'all are doing good.
OK, Ken, I finally (YAPC::NA::2003 seems a bit of a ways back now,
doesn't it?) got subscribed to your mailing list, and I have an
immediate concern / complaint / observation to air.
Over the last several weeks (but not, unfortunately, within the last
several days), I've installed a lot of modules using CPAN. I've detected
that on my system, packages using Module::Build are broken wrt to
automatic installation via CPAN. They can be installed if, following the
CPAN blow-up, I issue the "look <package-name>" command and go in and do
things manually.
I believe the reason things are failing is that I have settings in my
CPAN/Config.pm that call `perl Makefile.PL verbose'. As the
administrator for this system I have good reasons for invoking the
Makefile.PL this way. I don't know if you are thinking that M::B as it
gets somehow called from that Makefile.PL is already handling this: but
from the immediate (unstudied) vantage point of my recent experience, it
sure looks like it isn't.
And that is a problem. IMHO, M::B and portability scripts which enable
it's use from the traditional MakeMaker-based invocation `perl
makefile.PL', *must* support or at least parse and accept without error,
*all* the things that have been possible to pass as arguments to that
familiar routine. I can't really recommend M::B yet to others after the
amount of extra trouble it's caused me (I had to get the DateTime
modules installed inahurry a few days ago) on account of this remaining
degree of non-compatibility.
Let me know what's up and how I can help.
I've got this setup:
-----------------------------------------------------------------------
Module::Build 0.19 in
/usr/local/share/perl/5.6.1/Module/Build.pm (for 5.6.1)
I haven't installed M::B to my 5.8.0 installation yet. I am on Debian
"Woody".
Best,
Soren Andersen
|
|
From: Ken W. <ke...@ma...> - 2003-08-26 19:47:09
|
Hi,
The uploaded file
Module-Build-0.20.tar.gz
has entered CPAN as
file: $CPAN/authors/id/K/KW/KWILLIAMS/Module-Build-0.20.tar.gz
size: 81068 bytes
md5: 0a9e596924b9ef35142d085a5ef80294
It's also on Sourceforge for immediate download.
Changes since 0.19 are below.
-Ken
0.20 Tue Aug 26 14:34:07 CDT 2003
- Separated the 'build' action into two separate actions, 'code' and
'docs'. This is similar to MakeMaker's separation of the 'all'
target into 'pure_all' and 'manifypods'. This fixes a permissions
hassle in which doing 'sudo Build install' would often create local
doc files that needed superuser permissions to delete.
- Enhanced the 'help' action - 'Build help foo' will now show the POD
documentation for the 'foo' action.
- Added a notes() feature, which helps share data transparently
between the Build.PL and t/*.t scripts.
- The installation process will now create man(1) and man(3) pages
from POD in modules & scripts, and install them. We don't build
man pages when there's nowhere to install them, such as on some
Win32 or most Mac systems. [large patch by Steve Purkis, 5.005 fix
by Mathieu Arnold]
- The 'distdir' action now copies files to the distribution
directory, rather than making them hard links to the original
files. This allows authors to do last-minute alterations of the
files without affecting the originals. [Dave Rolsky]
- If the author uses XS files in nonstandard locations, the copied
versions of those files will now be cleaned up properly.
- In invoking the 'test' action or invoking 'xsubpp', we now use the
same perl executable as we use everywhere else, rather than blindly
using $^X or $Config{perlpath} (neither of which are very
reliable).
- Fixed a problem with the 'install_path' parameter given to
'Build.PL' being lost in subsequent actions. [Reported by Mathieu
Arnold]
- Fixed yet another bug with installation directories, in which the
'install_base' parameter wasn't being respected on the command
line. [Spotted by Jonathan Swartz]
- Changed the way the depends_on() method works inside action
subroutines - now each action will only run once per dispatch()
invocation (similar to how perl's require() function works). This
helps avoid some difficult problems with dependency loops.
- Changed the documentation for the 'autosplit' parameter to give
reasons why it may not be a good idea to use, but no longer
threaten to remove it. [Suggested by Martyn J. Pearce]
- Improved the formatting of the 'traditional' Makefile.PL generated
by Module::Build::Compat->create_makefile_pl. [Michael Schwern]
- The 'traditional' Makefile.PL will now use the 'module_name'
parameter (as NAME) if it's available, otherwise it will continue
to use the 'dist_name' (as DISTNAME). [Michael Schwern]
- Created read/write accessor methods for all our 'properties'.
[Michael Schwern]
- The 'test_files' parameter can now be specified using glob() syntax
(i.e. 't/*.t'), and the corresponding test_files() method is now a
read/write accessor.
- The location of the 'blib' directory is now a property of the Build
object - nobody is likely to notice this change, with any luck, but
it makes the design and code cleaner.
- The 'disttest' and 'distsign' methods now chdir() back to the
directory where they started, rather than to the base_dir of the
build.
- Improved comparisons of version strings containing underscore
characters (indicating "beta" status). [Steve Purkis]
- Added documentation for the 'dist_author', 'dist_abstract', and
'codebase' parameters to new(), and for the 'ppd' action. [Dave
Rolsky]
- Added documentation for the up_to_date() and contains_pod()
methods. [Dave Rolsky]
- 'traditional' pass-through Makefile.PLs will now contain an
INSTALLDIRS parameter matching the Build.PL's 'installdirs'
setting.
- version_from_file() now ignores $VERSION variables that are defined
in POD or comments. It can still be tricked by $VERSIONs in string
literals, though. [Steve Purkis]
- The code to find packages in module files now uses Steve's scanning
method (above) to skip package-declaration-lookalikes in POD or
comments.
- The 'disttest' action will now propagate its @INC settings to its
subprocesses.
|
|
From: Ken W. <ke...@ma...> - 2003-08-19 14:09:09
|
On Tuesday, August 19, 2003, at 08:49 AM, Dave Rolsky wrote:
>
> I think we just need to chmod the file in the distmeta action.
Might be better to just remove it if it exists - not sure how chmod()
will act on different platforms. I've just committed the following
patch.
-Ken
Index: lib/Module/Build/Base.pm
===================================================================
RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v
retrieving revision 1.173
retrieving revision 1.174
diff -u -r1.173 -r1.174
--- lib/Module/Build/Base.pm 18 Aug 2003 16:02:24 -0000 1.173
+++ lib/Module/Build/Base.pm 19 Aug 2003 14:07:07 -0000 1.174
@@ -1507,7 +1507,7 @@
my $dist_dir = $self->dist_dir;
$self->delete_filetree($dist_dir);
$self->add_to_cleanup($dist_dir);
- ExtUtils::Manifest::manicopy($dist_files, $dist_dir, 'best');
+ ExtUtils::Manifest::manicopy($dist_files, $dist_dir, 'cp');
warn "*** Did you forget to add $self->{metafile} to the
MANIFEST?\n" unless exists $dist_files->{$self->{metafile}};
$self->_sign_dir($dist_dir) if $self->{properties}{sign};
@@ -1595,6 +1595,9 @@
};
$node->{generated_by} = "Module::Build version " .
Module::Build->VERSION;
+
+ # If we're in the distdir, the metafile may exist and be
non-writable.
+ $self->delete_filetree($self->{metafile});
# YAML API changed after version 0.30
my $yaml_sub = $YAML::VERSION le '0.30' ? \&YAML::StoreFile :
\&YAML::DumpFile;
|
|
From: Dave R. <au...@ur...> - 2003-08-19 13:50:13
|
On Mon, 18 Aug 2003, Ken Williams wrote: > > On Wednesday, August 13, 2003, at 10:52 AM, Dave Rolsky wrote: > > > I proposed this earlier and got no response so here's a patch to > > implement > > this. I think doing this just makes more sense, since otherwise we > > can't > > manipular files in the dist dir without affecting the base dir files, > > since the dist dir could just be symlinks. > > This patch seems to have broken M::B's 'disttest' action, because we > don't have permission to write META.yml files. > > I'm about to do a new beta release of 0.19_05, so I'll roll back this > change for it - if you can figure out how to make it work properly > again, I'll re-patch. I agree that it's weird to make links, > especially since links aren't really a cross-platform concept. I think we just need to chmod the file in the distmeta action. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v retrieving revision 1.173 diff -u -r1.173 Base.pm --- lib/Module/Build/Base.pm 18 Aug 2003 16:02:24 -0000 1.173 +++ lib/Module/Build/Base.pm 19 Aug 2003 13:47:57 -0000 @@ -1507,7 +1507,7 @@ my $dist_dir = $self->dist_dir; $self->delete_filetree($dist_dir); $self->add_to_cleanup($dist_dir); - ExtUtils::Manifest::manicopy($dist_files, $dist_dir, 'best'); + ExtUtils::Manifest::manicopy($dist_files, $dist_dir, 'cp'); warn "*** Did you forget to add $self->{metafile} to the MANIFEST?\n" unless exists $dist_files->{$self->{metafile}}; $self->_sign_dir($dist_dir) if $self->{properties}{sign}; @@ -1595,6 +1595,9 @@ }; $node->{generated_by} = "Module::Build version " . Module::Build->VERSION; + + chmod 0644, $self->{metafile} + or die "Cannot make $self->{metafile} writeable: $!"; # YAML API changed after version 0.30 my $yaml_sub = $YAML::VERSION le '0.30' ? \&YAML::StoreFile : \&YAML::DumpFile; |
|
From: Ken W. <ke...@ma...> - 2003-08-18 16:40:00
|
Hey,
There's a new M::B on sourceforge & CPAN, changes since 0.19_04 are:
- Changed the way the depends_on() method works inside action
subroutines - now each action will only run once per dispatch()
invocation (similar to how perl's require() function works). This
helps avoid some difficult problems with dependency loops.
- Separated the 'build' action into two separate actions, 'code' and
'docs'. This is similar to MakeMaker's separation of the 'all'
target into 'pure_all' and 'manifypods'. This fixes a permissions
hassle in which doing 'sudo Build install' would often create local
doc files that needed superuser permissions to delete.
- Enhanced the 'help' action - 'Build help foo' will now show the POD
documentation for the 'foo' action.
- Changed the documentation for the 'autosplit' parameter to give
reasons why it may not be a good idea to use, but no longer
threaten to remove it. [Suggested by Martyn J. Pearce]
- Improved the formatting of the 'traditional' Makefile.PL generated
by Module::Build::Compat->create_makefile_pl. [Michael Schwern]
- The 'traditional' Makefile.PL will now use the 'module_name'
parameter (as NAME) if it's available, otherwise it will continue
to use the 'dist_name' (as DISTNAME). [Michael Schwern]
- Created read/write accessor methods for all our 'properties'.
[Michael Schwern]
- The 'test_files' parameter can now be specified using glob() syntax
(i.e. 't/*.t'), and the corresponding test_files() method is now a
read/write accessor.
- The 'builddocs' action from the last beta release has been renamed
to 'docs'.
- The location of the 'blib' directory is now a property of the Build
object - nobody is likely to notice this change, with any luck, but
it makes the design and code cleaner.
- The 'disttest' and 'distsign' methods now chdir() back to the
directory where they started, rather than to the base_dir of the
build.
-Ken
|
|
From: Ken W. <ke...@ma...> - 2003-08-18 16:18:41
|
On Wednesday, August 13, 2003, at 10:52 AM, Dave Rolsky wrote: > I proposed this earlier and got no response so here's a patch to > implement > this. I think doing this just makes more sense, since otherwise we > can't > manipular files in the dist dir without affecting the base dir files, > since the dist dir could just be symlinks. This patch seems to have broken M::B's 'disttest' action, because we don't have permission to write META.yml files. I'm about to do a new beta release of 0.19_05, so I'll roll back this change for it - if you can figure out how to make it work properly again, I'll re-patch. I agree that it's weird to make links, especially since links aren't really a cross-platform concept. -Ken |
|
From: Michael G S. <sc...@po...> - 2003-08-18 11:47:12
|
I just got a patch for MakeMaker's META.yml generation adding the YAML document header to the metafile. That's the "--- #YAML:1.0" thing. I rejected it because its optional in YAML and just clutter in a short document like META.yml. But I've noticed that nowhere else in the META.yml spec does it attempt to specify the format of the YAML file. Everywhere else the formatting rules are left to the YAML spec. Mentioning the document header is then something of an unnecessary inconsistency and should probably be removed. The first line of a META.yml file should be a valid YAML document header like "--- #YAML:1.0". That line. -- Michael G Schwern sc...@po... http://www.pobox.com/~schwern/ |
|
From: Michael G S. <sc...@po...> - 2003-08-18 08:50:38
|
The default MANIFEST.SKIP shipped with ExtUtils::MakeMaker 6.16 now
skips Build and _build/. This means the following is now useful:
perl Build.PL
Build manifest
Huzzah!
--
Michael G Schwern sc...@po... http://www.pobox.com/~schwern/
Playstation? Of course Perl runs on Playstation.
-- Jarkko Hietaniemi
|
|
From: Roland B. <rol...@ff...> - 2003-08-16 22:36:54
|
On Sat, 16 Aug 2003 17:31:52 +0200 (Westeuropäische Sommerzeit) Roland Bauer <rol...@ff...> wrote: RB> this is a patch over the old v0.19. I get much better results with v0.19_04. Sorry for this hasty posting ;-) Roland |
|
From: Roland B. <rol...@ff...> - 2003-08-16 20:57:32
|
Just 2 minor changes:
1)$VERSION added
2)a more informative error message
Roland
--- Base.pm_0.19_04 Fri Aug 01 17:04:20 2003
+++ Base.pm Sat Aug 16 19:43:46 2003
@@ -1,6 +1,8 @@
package Module::Build::Base;
use strict;
+use vars qw($VERSION);
+$VERSION = '0.01';
BEGIN { require 5.00503 }
use Config;
use File::Copy ();
@@ -471,7 +473,7 @@
my $fh = IO::File->new("< $file") or die "Can't read $file: $!";
$ph->{disk} = eval do {local $/; <$fh>};
- die $@ if $@;
+ die sprintf("ERROR in %s line %s: $@", __FILE__, __LINE__) if $@;
}
sub add_to_cleanup {
--
Roland Bauer
http://www.fff.at/contact/
|
|
From: Roland B. <rol...@ff...> - 2003-08-16 18:41:53
|
When there are no pm_files this results in an error.
Maybe an empty hash should be returned instead.
Regards,
Roland
--- Base.pm_0.19_04 Fri Aug 01 17:04:20 2003
+++ Base.pm Sat Aug 16 19:54:12 2003
@@ -1107,7 +1107,7 @@
return { map $self->localize_file_path($_), %$files };
}
- return unless -d 'lib';
+ return {} unless -d 'lib';
return { map {$_, $_} @{ $self->rscan_dir('lib', qr{\.$type$}) } };
}
--
Roland Bauer
http://www.fff.at/contact/
|
|
From: Roland B. <rol...@ff...> - 2003-08-16 15:39:18
|
Hi,
sorry, this is a patch over the old v0.19. But I hope it shows the idea:
1) a $VERSION variable should be added
2) I had troubles with target 'dist' and I think this is
because strings like Module-Name-0.10, Module-Name and Module/Name
are mixed up. I think it should/could be:
Module-Name-0.10 .......... dist_file
Module-Name-0.10.tar.gz ... dist_tgz
Module-Name ............... dist_name
Module/Name ............... dist_dir
It seems to work, however, maybe I've misunderstood
the concept.
Regards,
Roland.
#----------------------------------------CUT-------------------
--- Base.pm_v0.19 Tue Jul 08 00:02:22 2003
+++ Base.pm Sat Aug 16 15:58:09 2003
@@ -1,6 +1,10 @@
package Module::Build::Base;
use strict;
+use vars qw($VERSION);
+
+$VERSION = '0.01';
+
BEGIN { require 5.00503 }
use Config;
use File::Copy ();
@@ -1186,7 +1190,7 @@
my $dist_dir = $self->dist_dir;
- $self->make_tarball($dist_dir);
+ $self->make_tarball($dist_dir, $self->dist_file);
$self->delete_filetree($dist_dir);
}
@@ -1288,7 +1292,13 @@
sub dist_dir {
my ($self) = @_;
- return "$self->{properties}{dist_name}-$self->{properties}{dist_version}";
+ (my $dir = $self->dist_name) =~ s#-#/#g;
+ $dir;
+}
+
+sub dist_file {
+ my ($self) = @_;
+ my $file = join '-', $self->dist_name, $self->dist_version;
}
sub script_files {
@@ -1393,13 +1403,13 @@
}
sub make_tarball {
- my ($self, $dir) = @_;
+ my ($self, $dir, $distfile) = @_;
require Archive::Tar;
my $files = $self->rscan_dir($dir);
- print "Creating $dir.tar.gz\n";
- Archive::Tar->create_archive("$dir.tar.gz", 1, @$files);
+ print "Creating $distfile.tar.gz\n";
+ Archive::Tar->create_archive("$distfile.tar.gz", 1, @$files);
}
sub install_base_relative {
#----------------------------------------CUT-------------------
|
|
From: Michael G S. <sc...@po...> - 2003-08-14 05:45:14
|
On Wed, Aug 13, 2003 at 03:58:28PM -0500, Ken Williams wrote: > I think the sorting should move from where it is now (end of > test_files()) to inside the expand_test_dir() routine. That will > preserve any order the user specifies with the 'test_files' parameter, > while giving predictable sorting order on glob expansions. Sensible. -- Michael G Schwern sc...@po... http://www.pobox.com/~schwern/ Thanks, applied. Or, ??????k@???????K^U as we Bulgarian EBCDIC users like to say. -- Jarkko Hietaniemi in <200...@al...> |
|
From: Ken W. <ke...@ma...> - 2003-08-13 21:10:10
|
On Wednesday, August 13, 2003, at 03:02 PM, Michael G Schwern wrote:
> Danger! Sorting order. Using glob("t/*.t") as the default order means
> it is no longer guaranteed. At best they'll be ASCIIbetical, but even
> that
> depends on the glob implementation.
Yeah, but they do get sorted later on.
> just change that to
>
> push @tests, sort { lc $a cmp lc $b } $self->expand_test_dir('t')
> ...
>
> in order to guarantee that "Build test" runs in the same order on
> every OS.
> Don't sort anything but the default, though. You want to leave an
> opening
> for users to change the order.
I think the sorting should move from where it is now (end of
test_files()) to inside the expand_test_dir() routine. That will
preserve any order the user specifies with the 'test_files' parameter,
while giving predictable sorting order on glob expansions.
-Ken
|
|
From: Michael G S. <sc...@po...> - 2003-08-13 20:17:42
|
On Wed, Aug 13, 2003 at 10:26:35AM -0500, Ken Williams wrote:
> Okay, here's what I'll do. I like running 'test_files' through glob(),
> for several reasons. First, it means the default changes from a bunch
> of code that finds the files, to the string "t/*.t".
Danger! Sorting order. Using glob("t/*.t") as the default order means
it is no longer guaranteed. At best they'll be ASCIIbetical, but even that
depends on the glob implementation.
> - push @tests, @{$self->rscan_dir('t', qr{\.t$})} if -e 't' and -d _;
> + push @tests, $self->expand_test_dir('t') if -e 't' and -d _;
just change that to
push @tests, sort { lc $a cmp lc $b } $self->expand_test_dir('t') ...
in order to guarantee that "Build test" runs in the same order on every OS.
Don't sort anything but the default, though. You want to leave an opening
for users to change the order.
--
Michael G Schwern sc...@po... http://www.pobox.com/~schwern/
Don't step on my funk
|
|
From: Ken W. <ke...@ma...> - 2003-08-13 17:26:46
|
On Wednesday, August 13, 2003, at 10:52 AM, Dave Rolsky wrote: > I proposed this earlier and got no response so here's a patch to > implement > this. Yeah, I wasn't sure whether we had achieved consensus yet, mostly because I didn't understand all the issues yet. I don't see any harm in the patch, though. I'll apply. > I think doing this just makes more sense, since otherwise we can't > manipular files in the dist dir without affecting the base dir files, > since the dist dir could just be symlinks. I think they would be hard links, not symlinks. Not that these concepts translate very well to different platforms or anything. -Ken |
|
From: Ken W. <ke...@ma...> - 2003-08-13 17:10:57
|
On Wednesday, August 13, 2003, at 10:26 AM, Ken Williams wrote: > Here's how I'll apply the first patch. The 'recursive_test_files' > property remains unimplemented and I'm not sure about the name yet. > Steve's 'matching' argument can still be implemented later if we want > regexes. I also just made test_files() a read/write accessor, so that I could write a proper test case for the globbing. Can anyone comment on the cross-platform abilities of glob()? -Ken |
|
From: Dave R. <au...@ur...> - 2003-08-13 16:43:24
|
I proposed this earlier and got no response so here's a patch to implement this. I think doing this just makes more sense, since otherwise we can't manipular files in the dist dir without affecting the base dir files, since the dist dir could just be symlinks. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ --- Base.pm.~1.163.~ 1969-12-31 19:00:01.000000000 -0500 +++ Base.pm 2003-08-13 11:51:12.000000000 -0400 @@ -1486,7 +1486,7 @@ my $dist_dir = $self->dist_dir; $self->delete_filetree($dist_dir); $self->add_to_cleanup($dist_dir); - ExtUtils::Manifest::manicopy($dist_files, $dist_dir, 'best'); + ExtUtils::Manifest::manicopy($dist_files, $dist_dir, 'cp'); warn "*** Did you forget to add $self->{metafile} to the MANIFEST?\n" unless exists $dist_files->{$self->{metafile}}; $self->_sign_dir($dist_dir) if $self->{properties}{sign}; |
7 messages has been excluded from this view by a project administrator.
