module-build-general Mailing List for Module::Build (Page 161)
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: Steve P. <sp...@qu...> - 2003-08-08 15:06:30
|
On Wednesday, August 6, 2003, at 07:25 pm, Ken Williams wrote: > ... > 1) Actions now run only once per dispatch() invocation. Dave, maybe > this means the 'distmeta' interaction with the 'distdir' stuff could > be cleaned up some? I suppose there's no real reason to fix things > that aren't broken, though. Au contraire - consistency is one good reason to refactor. -Steve |
|
From: Steve P. <sp...@qu...> - 2003-08-08 15:02:18
|
On Monday, August 4, 2003, at 12:47 am, Ken Williams wrote:
> On Saturday, August 2, 2003, at 08:26 PM, Ken Williams wrote:
>
>> On Friday, August 1, 2003, at 06:42 PM, Steve Purkis wrote:
>>
>>> Hmm... that sounds like a good idea. Maybe store everything in
>>> $self->{_completed_actions} or something. Can't promise anything,
>>> but I'll have a look into it in my copious amounts of free time next
>>> week.
>>
>> It shouldn't be too hard for me to patch it up myself, actually.
>> I'll let you know.
>
> I put this patch in yesterday, along with a new test to make sure it's
> working.
Looks good, though doing this:
+ local $self->{_completed_actions} = {};
in dispatch() means that subsequent calls to dispatch() will lose
context of completed actions... don't know if that matters with
_call_action() available though.
Anyways - here's a patch to fix the docs/build dependency bug, and make
M::B create man pages at 'build' time.
-Steve
|
|
From: Ken W. <ke...@ma...> - 2003-08-06 18:25:48
|
Hey, A couple of recent code changes I committed to CVS: 1) Actions now run only once per dispatch() invocation. Dave, maybe this means the 'distmeta' interaction with the 'distdir' stuff could be cleaned up some? I suppose there's no real reason to fix things that aren't broken, though. 2) I change the instance() method to current(), since it's not really a true Singleton pattern, and I added docs for current() and notes(). -Ken |
|
From: David C. <dl...@ha...> - 2003-08-06 16:58:24
|
Back in March there was a discussion about the /lib directory vs.
EU::MakeMaker's directory structure w.r.t. resursive builds. Has any
more work been done on recursive builds?
Actually, I think what I'm mainly interested in is "recursive testing".
In a distribution which comprises a few levels of class heirarchy,
it would be very convenient for me to issue a "./Build test" from
a lower level in the heirarchy and have only the tests relevant to that
level/class be executed. Either that, or have the test method know
about subdirectories in the top-level t/ directory:
./Build test test_files=t/Foo/Bar/
run all tests found in .../t/Foo/Bar
|
|
From: Stas B. <st...@st...> - 2003-08-05 05:56:49
|
Andreas J Koenig wrote: >>>>>>On Fri, 1 Aug 2003 15:36:36 +0100, Steve Purkis <sp...@qu...> said: > > > sp> Hmm.. but then Ken will always be responsible for maintaining the spec > sp> - what happens if he ever decides to pass maintenance of M::B over to > sp> someone else? Perhaps another dir on CPAN (or perl.com) would make > sp> more sense? > > Good point. There is a very simple plan how to deal with groups on > CPAN, and it is already 3/4 implemented: larger projects are able to > register a mailinglist account. Unfortunately this is currrently not a > very usable feature, but I have promised Stas Bekman to make it more > so. I could arrange things manually now for the module-build mailing > list, if people want. That way Ken would be my victim that will have > to test the new functionality as the first one. And I can do that too if more testing is needed. role accounts, here we come... __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:st...@st... http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com |
|
From: Ken W. <ke...@ma...> - 2003-08-03 23:47:51
|
On Saturday, August 2, 2003, at 08:26 PM, Ken Williams wrote:
>
> On Friday, August 1, 2003, at 06:42 PM, Steve Purkis wrote:
>
>> Hmm... that sounds like a good idea. Maybe store everything in
>> $self->{_completed_actions} or something. Can't promise anything,
>> but I'll have a look into it in my copious amounts of free time next
>> week.
>
> It shouldn't be too hard for me to patch it up myself, actually. I'll
> let you know.
I put this patch in yesterday, along with a new test to make sure it's
working.
===================================================================
RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v
retrieving revision 1.158
retrieving revision 1.159
diff -u -r1.158 -r1.159
--- lib/Module/Build/Base.pm 1 Aug 2003 20:57:11 -0000 1.158
+++ lib/Module/Build/Base.pm 3 Aug 2003 01:38:37 -0000 1.159
@@ -778,6 +778,7 @@
sub dispatch {
my $self = shift;
+ local $self->{_completed_actions} = {};
if (@_) {
my ($action, %p) = @_;
@@ -794,6 +795,7 @@
sub _call_action {
my ($self, $action) = @_;
+ return if $self->{_completed_actions}{$action}++;
local $self->{action} = $action;
my $method = "ACTION_$action";
die "No action '$action' defined" unless $self->can($method);
===================================================================
-Ken
|
|
From: Ken W. <ke...@ma...> - 2003-08-03 01:26:37
|
On Friday, August 1, 2003, at 06:42 PM, Steve Purkis wrote:
> On Friday, August 1, 2003, at 03:42 pm, Ken Williams wrote:
>
>> I'm thinking it would be best to make depends_on() work like perl's
>> require(), in that it will only run each action once per "./Build
>> foo" (i.e. once per dispatch() invocation). If that proves too
>> inflexible we may need to provide additional controls on it, but I
>> think it should simplify dependencies quite a bit.
>
> Hmm... that sounds like a good idea. Maybe store everything in
> $self->{_completed_actions} or something. Can't promise anything, but
> I'll have a look into it in my copious amounts of free time next week.
It shouldn't be too hard for me to patch it up myself, actually. I'll
let you know.
-Ken
|
|
From: Steve P. <sp...@qu...> - 2003-08-01 23:42:55
|
On Friday, August 1, 2003, at 03:42 pm, Ken Williams wrote:
>
> On Thursday, July 31, 2003, at 06:32 PM, Steve Purkis wrote:
>>
>> To fix it you could make 'build' dispatch to 'builddocs', but that
>> would be bad seeing as 'builddocs' should (but doesn't for some
>> reason?) depend on 'build', which means an infinite loop.
>>
>> So maybe the best idea is to take the common code out of 'builddocs'
>> and call it from both actions, and fix the dependency issue?
>
> Hmm, this isn't the first time this kind of dependency issue has
> cropped up. Building the META.yml file had the same issues, it took
> Dave several tries to rework the dependency order.
>
> I'm thinking it would be best to make depends_on() work like perl's
> require(), in that it will only run each action once per "./Build foo"
> (i.e. once per dispatch() invocation). If that proves too inflexible
> we may need to provide additional controls on it, but I think it
> should simplify dependencies quite a bit.
Hmm... that sounds like a good idea. Maybe store everything in
$self->{_completed_actions} or something. Can't promise anything, but
I'll have a look into it in my copious amounts of free time next week.
-Steve
|
|
From: Steve P. <sp...@qu...> - 2003-08-01 23:40:29
|
On Friday, August 1, 2003, at 09:57 pm, Ken Williams wrote: > On Friday, August 1, 2003, at 03:36 PM, Dave Rolsky wrote: > >> On Fri, 1 Aug 2003, Ken Williams wrote: >> >>> ./Build docs >>> >>> . I wonder if I should change it now, since it will be harder to >>> change it later. Opinions? >> >> Change it, the former is just silly. > > Yeah, ok, done. yay! * spurkis scratches something of his todo list -Steve |
|
From: Ken W. <ke...@ma...> - 2003-08-01 20:58:04
|
On Friday, August 1, 2003, at 03:36 PM, Dave Rolsky wrote: > On Fri, 1 Aug 2003, Ken Williams wrote: > >> >> On Friday, August 1, 2003, at 02:16 PM, Michael G Schwern wrote: >>> >>> Aww, I always liked the term "docify". >>> >>> Don't mind me. ;) >> >> Actually, I chose the term "builddocs" but I'm not too happy with it. >> It means that you can end up typing >> >> ./Build builddocs >> >> instead of the more natural >> >> ./Build docs >> >> . I wonder if I should change it now, since it will be harder to >> change it later. Opinions? > > Change it, the former is just silly. Yeah, ok, done. -Ken |
|
From: Dave R. <au...@ur...> - 2003-08-01 20:37:27
|
On Fri, 1 Aug 2003, Ken Williams wrote: > > On Friday, August 1, 2003, at 02:16 PM, Michael G Schwern wrote: > > > > Aww, I always liked the term "docify". > > > > Don't mind me. ;) > > Actually, I chose the term "builddocs" but I'm not too happy with it. > It means that you can end up typing > > ./Build builddocs > > instead of the more natural > > ./Build docs > > . I wonder if I should change it now, since it will be harder to > change it later. Opinions? Change it, the former is just silly. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-08-01 20:31:04
|
On Friday, August 1, 2003, at 02:16 PM, Michael G Schwern wrote: > > Aww, I always liked the term "docify". > > Don't mind me. ;) Actually, I chose the term "builddocs" but I'm not too happy with it. It means that you can end up typing ./Build builddocs instead of the more natural ./Build docs . I wonder if I should change it now, since it will be harder to change it later. Opinions? -Ken |
|
From: Ken W. <ke...@ma...> - 2003-08-01 16:00:18
|
Hi,
I just uploaded a new beta to sourceforge and CPAN. Changes since
0.19_03:
0.19_04
- 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]
- Now we don't build man pages when there's nowhere to install them,
such as on some Win32 or most Mac OS systems.
- 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.
-Ken
|
|
From: Ken W. <ke...@ma...> - 2003-08-01 15:58:13
|
On Friday, August 1, 2003, at 10:00 AM, Andreas J Koenig wrote: >>>>>> On Fri, 1 Aug 2003 15:36:36 +0100, Steve Purkis >>>>>> <sp...@qu...> said: > > sp> Hmm.. but then Ken will always be responsible for maintaining the > spec > sp> - what happens if he ever decides to pass maintenance of M::B > over to > sp> someone else? Perhaps another dir on CPAN (or perl.com) would > make > sp> more sense? > > Good point. There is a very simple plan how to deal with groups on > CPAN, and it is already 3/4 implemented: larger projects are able to > register a mailinglist account. Unfortunately this is currrently not a > very usable feature, but I have promised Stas Bekman to make it more > so. I could arrange things manually now for the module-build mailing > list, if people want. That way Ken would be my victim that will have > to test the new functionality as the first one. Heh - sure, sounds good to me. -Ken |
|
From: Ken W. <ke...@ma...> - 2003-08-01 15:08:42
|
On Friday, August 1, 2003, at 01:13 AM, Jonathan Swartz wrote: > I tried, it still doesn't work with 0.19_04. > > swartz> pwd > /home/swartz/.cpan/build/Module-Build-0.18_04 > swartz> ./Build install install_base=/home/mhq > Warning: You do not have permissions to install into > /usr/lib/perl5/site_perl/5.6.1 at > /usr/lib/perl5/5.6.1/ExtUtils/Install.pm > line 84. > mkdir /usr/lib/perl5/site_perl/5.6.1/Module: Permission denied at > /usr/lib/perl5/5.6.1/ExtUtils/Install.pm line 136 > > I also tried setting install_base during the initial "perl Build.PL", > same > thing. Does install_base have any effect at all? Argh, argh, argh! You're right - the 'install_base' was missing from the [ill-conceived] %valid_properties list, so it wasn't being respected properly. I've added a regression test in t/install.t for this too. Looks like it's time for at least a new beta. -Ken |
|
From: Andreas J K. <and...@an...> - 2003-08-01 15:00:43
|
>>>>> On Fri, 1 Aug 2003 15:36:36 +0100, Steve Purkis <sp...@qu...> said: sp> Hmm.. but then Ken will always be responsible for maintaining the spec sp> - what happens if he ever decides to pass maintenance of M::B over to sp> someone else? Perhaps another dir on CPAN (or perl.com) would make sp> more sense? Good point. There is a very simple plan how to deal with groups on CPAN, and it is already 3/4 implemented: larger projects are able to register a mailinglist account. Unfortunately this is currrently not a very usable feature, but I have promised Stas Bekman to make it more so. I could arrange things manually now for the module-build mailing list, if people want. That way Ken would be my victim that will have to test the new functionality as the first one. -- andreas |
|
From: Ken W. <ke...@ma...> - 2003-08-01 14:42:52
|
On Thursday, July 31, 2003, at 06:32 PM, Steve Purkis wrote: > > To fix it you could make 'build' dispatch to 'builddocs', but that > would be bad seeing as 'builddocs' should (but doesn't for some > reason?) depend on 'build', which means an infinite loop. > > So maybe the best idea is to take the common code out of 'builddocs' > and call it from both actions, and fix the dependency issue? Hmm, this isn't the first time this kind of dependency issue has cropped up. Building the META.yml file had the same issues, it took Dave several tries to rework the dependency order. I'm thinking it would be best to make depends_on() work like perl's require(), in that it will only run each action once per "./Build foo" (i.e. once per dispatch() invocation). If that proves too inflexible we may need to provide additional controls on it, but I think it should simplify dependencies quite a bit. -Ken |
|
From: Steve P. <sp...@qu...> - 2003-08-01 14:36:46
|
On Friday, August 1, 2003, at 11:24 am, Andreas J Koenig wrote: >>>>>> On Fri, 1 Aug 2003 03:17:20 -0700, Michael G Schwern >>>>>> <sc...@po...> said: > >> On Fri, Aug 01, 2003 at 09:25:24AM +0200, Andreas J Koenig wrote: >>> And would people think it would be a good idea to include the URL of >>> the spec into every META.yml file? I'm not sure. > >> Couldn't hurt, its just a comment. It would be nice if the URL was >> permenant, though. I have a sneaking suspicion Module::Build might >> move off >> SF.net one day. Say a pobox.com or module-build.org (if such a beast >> exists) address? > > I believe the document should live in Ken's CPAN directory. Hmm.. but then Ken will always be responsible for maintaining the spec - what happens if he ever decides to pass maintenance of M::B over to someone else? Perhaps another dir on CPAN (or perl.com) would make more sense? -Steve |
|
From: Graham B. <gb...@po...> - 2003-08-01 13:36:14
|
On Friday, Aug 1, 2003, at 03:41 US/Pacific, Michael G Schwern wrote: > On Fri, Aug 01, 2003 at 12:24:23PM +0200, Andreas J Koenig wrote: >> I believe the document should live in Ken's CPAN directory. > > We'd still need a cannonical URL for the latest version since the one > directly to CPAN would be constantly changing to match the version # or > disappearing as old versions get deleted. Having the version number in the URL would be a good thing, the URL would then also be documenting which version of the spec the file implements. Just don't delete old versions of it from CPAN. Graham. |
|
From: Dave R. <au...@ur...> - 2003-08-01 13:08:24
|
On Fri, 1 Aug 2003, Andreas J Koenig wrote: > >>>>> On Mon, 28 Jul 2003 17:44:56 -0500 (CDT), Dave Rolsky <au...@ur...> said: > > dr> Bleah, that sucks! Whoever wrote EU::Manifest needs to be beaten. > > Me, Me! That's it, I'm gonna get ya! > dr> Here's a good one. If you set the copying method to 'cp' it changes the > dr> permissions on the copied files to remove write permission. Just > dr> brilliant, really. After all, it's inconceivable that anyone might need > dr> to ever alter these files. > > I apologise for not documenting this behaviour. But please consider > the age of the code base and the original target audience. I wrote it > ~7 years ago and the only place it was used was for the 'make dist' > target of MakeMaker. At that time everybody agreed that we should > C<chmod -w> all files in a distribution file for CPAN. Yeah, I know the origins. Sorry for the rant. I was just frustrated after spending some time figuring out why every time I changed a file in the dist dir, I saw changes under the base directory. Anyway, I think having M::B use the 'cp' mode is fine for now. Maybe we can add a 'clean' mode in the future which just copies and doesn't tweak permissions. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Andreas J K. <and...@an...> - 2003-08-01 10:58:22
|
>>>>> On Fri, 1 Aug 2003 03:41:08 -0700, Michael G Schwern <sc...@po...> said:
> On Fri, Aug 01, 2003 at 12:24:23PM +0200, Andreas J Koenig wrote:
>> I believe the document should live in Ken's CPAN directory.
> We'd still need a cannonical URL for the latest version since the one
> directly to CPAN would be constantly changing to match the version # or
> disappearing as old versions get deleted.
*.html files may be overwritten, so META-spec.html can remain the
latest spec. As long as it contains links to earlier versions, this
should be all you ever need to link to.
> This is a problem for CPAN modules in general.
That's why there is the exception that says:
documentation files may be overwritten. There's a simple regular
expression that draws the line between docu und code:
<code>/(README|readme|\.html|\.txt)$/</code>. Filenames matching
this RE can be uploaded as often as you like.
(from CPAN/modules/04pause.html)
--
andreas
|
|
From: Andreas J K. <and...@an...> - 2003-08-01 10:24:39
|
>>>>> On Fri, 1 Aug 2003 03:17:20 -0700, Michael G Schwern <sc...@po...> said: > On Fri, Aug 01, 2003 at 09:25:24AM +0200, Andreas J Koenig wrote: >> And would people think it would be a good idea to include the URL of >> the spec into every META.yml file? I'm not sure. > Couldn't hurt, its just a comment. It would be nice if the URL was > permenant, though. I have a sneaking suspicion Module::Build might move off > SF.net one day. Say a pobox.com or module-build.org (if such a beast > exists) address? I believe the document should live in Ken's CPAN directory. -- andreas |
|
From: Andreas J K. <and...@an...> - 2003-08-01 10:11:26
|
>>>>> On Mon, 28 Jul 2003 17:44:56 -0500 (CDT), Dave Rolsky <au...@ur...> said: dr> Bleah, that sucks! Whoever wrote EU::Manifest needs to be beaten. Me, Me! dr> Here's a good one. If you set the copying method to 'cp' it changes the dr> permissions on the copied files to remove write permission. Just dr> brilliant, really. After all, it's inconceivable that anyone might need dr> to ever alter these files. I apologise for not documenting this behaviour. But please consider the age of the code base and the original target audience. I wrote it ~7 years ago and the only place it was used was for the 'make dist' target of MakeMaker. At that time everybody agreed that we should C<chmod -w> all files in a distribution file for CPAN. -- andreas |
|
From: Ken W. <ke...@ma...> - 2003-08-01 03:38:05
|
On Thursday, July 31, 2003, at 06:18 PM, Steve Purkis wrote: > Hiya, > > I've whipped up a patch using the newly documented up_to_date() (ta > for pointing it out, Dave) to make the 'builddocs' action skip pod2man > generation if the output file looks up to date. > You beat me to this one too - thanks, applied. -Ken |
|
From: Ken W. <ke...@ma...> - 2003-08-01 03:30:51
|
On Thursday, July 31, 2003, at 07:13 PM, Steve Purkis wrote: > On Thursday, July 31, 2003, at 07:32 pm, Steve Purkis wrote: > >> I suppose it's worth asking this: why not use version objects? > > Because they don't come standard with most (any?) versions of perl is > one reason. Right, you beat me to the answer. =) >> Which works for most things. I think it break because of how perl >> does SV -> NV conversions [1]: >> >> '0.03_01' > '0.03' == false > > The attached patch fixes this. It doesn't do everything that > version.pm does, but I imagine it can be integrated easily if need be. Yup - my sense is that we won't actually depend on version.pm unless we really need to, but that it won't be too hard to get the compare_versions() method to do pretty much everything we need it to. Thanks for the patch, I've applied it. -Ken |
7 messages has been excluded from this view by a project administrator.
