Thread: [Module-build-general] make doesn't create man pages
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Mike C. <da...@ix...> - 2003-07-24 18:34:47
|
My normal install process for installing perl modules is:
perl Makefile.PL
make
su -
make install
Now, for most systems, this is ok, but for module-build, the make install
step is where the man pages get created, and so they get created as root.
So when I go to delete the directory afterwards, I can't.
Very annoying.
Please adjust.
mrc
--
Mike Castle da...@ix... www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
|
|
From: Steve P. <sp...@qu...> - 2003-07-31 23:35:37
|
On Thursday, July 24, 2003, at 07:34 pm, Mike Castle wrote: > > My normal install process for installing perl modules is: > > perl Makefile.PL > make > su - > make install > > > Now, for most systems, this is ok, but for module-build, the make > install > step is where the man pages get created, and so they get created as > root. > > So when I go to delete the directory afterwards, I can't. Well, you could just do: % sudo make clean but agreed - very annoying. 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? -Steve |
|
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 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: 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: 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: Steve P. <sp...@qu...> - 2003-08-08 15:02:18
Attachments:
Module-Build-0.19_04-docs.patch
|
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-08 16:53:42
|
On Friday, August 8, 2003, at 10:02 AM, Steve Purkis wrote:
>
> Anyways - here's a patch to fix the docs/build dependency bug, and
> make M::B create man pages at 'build' time.
Looks good, Steve - below is the patch I'll commit. It creates a new
action 'code', which does what 'build' used to do, and now 'build'
creates both code & docs.
Hmm, I guess this doesn't actually need the loop-avoidance patch
anymore, does it! Well, I guess it's still good to have that.
-Ken
Index: lib/Module/Build/Base.pm
===================================================================
RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v
retrieving revision 1.160
diff -u -r1.160 Base.pm
--- lib/Module/Build/Base.pm 5 Aug 2003 17:28:35 -0000 1.160
+++ lib/Module/Build/Base.pm 8 Aug 2003 16:50:58 -0000
@@ -913,7 +913,7 @@
my $p = $self->{properties};
require Test::Harness;
- $self->depends_on('build');
+ $self->depends_on('code');
# Do everything in our power to work with all versions of
Test::Harness
local ($Test::Harness::switches,
@@ -967,7 +967,7 @@
$self->depends_on('test');
}
-sub ACTION_build {
+sub ACTION_code {
my ($self) = @_;
# All installable stuff gets created in blib/ .
@@ -990,6 +990,12 @@
$self->process_script_files;
}
+sub ACTION_build {
+ my $self = shift;
+ $self->depends_on('code');
+ $self->depends_on('docs');
+}
+
sub compile_support_files {
my $self = shift;
my $p = $self->{properties};
@@ -1167,6 +1173,7 @@
sub ACTION_docs {
my $self = shift;
+ $self->depends_on('code');
require Pod::Man;
$self->manify_bin_pods() if $self->install_destination('bindoc');
$self->manify_lib_pods() if $self->install_destination('libdoc');
@@ -1307,14 +1314,14 @@
sub ACTION_install {
my ($self) = @_;
require ExtUtils::Install;
- $self->depends_on('build', 'docs');
+ $self->depends_on('build');
ExtUtils::Install::install($self->install_map('blib'), 1, 0,
$self->{args}{uninst}||0);
}
sub ACTION_fakeinstall {
my ($self) = @_;
require ExtUtils::Install;
- $self->depends_on('build', 'docs');
+ $self->depends_on('build');
ExtUtils::Install::install($self->install_map('blib'), 1, 1,
$self->{args}{uninst}||0);
}
@@ -1324,7 +1331,7 @@
die "You must have only.pm 0.25 or greater installed for this
operation: $@\n"
unless eval { require only; 'only'->VERSION(0.25); 1 };
- $self->depends_on('build', 'docs');
+ $self->depends_on('build');
my %onlyargs = map {exists($self->{args}{$_}) ? ($_ =>
$self->{args}{$_}) : ()}
qw(version versionlib);
|
|
From: Steve P. <sp...@qu...> - 2003-08-08 18:12:37
|
On Friday, August 8, 2003, at 05:53 pm, Ken Williams wrote: > > On Friday, August 8, 2003, at 10:02 AM, Steve Purkis wrote: >> >> Anyways - here's a patch to fix the docs/build dependency bug, and >> make M::B create man pages at 'build' time. > > Looks good, Steve - below is the patch I'll commit. It creates a new > action 'code', which does what 'build' used to do, and now 'build' > creates both code & docs. Good idea, and its much more obvious what's happening that way. Wish I'd thought of it :) > Hmm, I guess this doesn't actually need the loop-avoidance patch > anymore, does it! Well, I guess it's still good to have that. Yeah, but hopefully to be used sparingly.. -Steve |
Thanks for helping keep SourceForge clean.
X