module-build-general Mailing List for Module::Build (Page 163)
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: Ken W. <ke...@ma...> - 2003-07-22 19:55:33
|
On Tuesday, July 22, 2003, at 10:15 AM, Mathieu Arnold wrote: > There's no error message, they're just not generated. > > and for the tests, here is the global output (and the verbose for > magnifypods), after removing use warnings from t/magnifypods.t Hi Mathieu, Hmm, can't really tell what's going wrong. It's possible that -T isn't working correctly on 5.005. If you can try the current CVS when it becomes available, I've made some changes in t/manifypods.t that should give some more diagnostic information upon failure. My hunch is that contains_pod() isn't working correctly. (Note that it's "manify", not "magnify" =) -Ken |
|
From: Mathieu A. <m...@ab...> - 2003-07-22 15:15:21
|
+-le 22/07/2003 09:55 -0500, Ken Williams =E9crivait : |=20 | On Tuesday, July 22, 2003, at 08:43 AM, Mathieu Arnold wrote: |=20 |> I've not looked in the details, but is there a reason why it does not |> generates man pages with 5.005_03 ? |=20 | Should work - what error messages are you getting? Does the 0.19_02 beta | pass tests? There's no error message, they're just not generated. and for the tests, here is the global output (and the verbose for magnifypods), after removing use warnings from t/magnifypods.t --=20 Mathieu Arnold |
|
From: Ken W. <ke...@ma...> - 2003-07-22 14:55:13
|
On Tuesday, July 22, 2003, at 08:43 AM, Mathieu Arnold wrote: > > > +-le 21/07/2003 13:31 -0500, Ken Williams =E9crivait : > | Hi Steve, > | > | I've applied this patch in a modified form, and released a 0.19_02=20= > beta > | tarball containing it (on CPAN eventually, and on sourceforge now). > | Thanks a heap for doing this work! > > I've not looked in the details, but is there a reason why it does not > generates man pages with 5.005_03 ? Should work - what error messages are you getting? Does the 0.19_02=20 beta pass tests? -Ken |
|
From: Mathieu A. <m...@ab...> - 2003-07-22 13:43:39
|
+-le 21/07/2003 13:31 -0500, Ken Williams =E9crivait : | Hi Steve, |=20 | I've applied this patch in a modified form, and released a 0.19_02 beta | tarball containing it (on CPAN eventually, and on sourceforge now). | Thanks a heap for doing this work! I've not looked in the details, but is there a reason why it does not generates man pages with 5.005_03 ? --=20 Mathieu Arnold |
|
From: Steve P. <sp...@ep...> - 2003-07-22 09:36:50
|
On Monday, July 21, 2003, at 10:40 pm, Ken Williams wrote: > On Monday, July 21, 2003, at 04:12 PM, Steve Purkis wrote: > >> Hi Ken, >> >> Good to hear - will have a look at it when it comes out on CPAN (I >> can't access anon. cvs for some reason?). Will be interesting to see >> if it passes the CPAN+ tests :). Glad I could help out. > > Yeah, the CPAN lag is why I started uploading them here too: > > http://sourceforge.net/projects/module-build Ah - that works, thanks. > And the SF connection cap > (http://sourceforge.net/docman/ > display_doc.php?docid=17790&group_id=1#cvs) is why I added this > shamelessly aggressive shell alias: > > % which force > force: aliased to perl -le "while (1) { last if not system @ARGV; > sleep 1 }" > > I use it for commands like "force cvs update", which tries over and > over again until it succeeds. =) Hmm.. will try that out when I get back. But it was giving me an auth. error for user anonymous, not a connection error (had those too, though :). Anyways, I'm running off to YAPC::EU in a sec - maybe I'll see some of you there. -Steve |
|
From: Ken W. <ke...@ma...> - 2003-07-21 21:41:22
|
On Monday, July 21, 2003, at 04:12 PM, Steve Purkis wrote:
> Hi Ken,
>
> Good to hear - will have a look at it when it comes out on CPAN (I
> can't access anon. cvs for some reason?). Will be interesting to see
> if it passes the CPAN+ tests :). Glad I could help out.
Yeah, the CPAN lag is why I started uploading them here too:
http://sourceforge.net/projects/module-build
And the SF connection cap
(http://sourceforge.net/docman/
display_doc.php?docid=17790&group_id=1#cvs) is why I added this
shamelessly aggressive shell alias:
% which force
force: aliased to perl -le "while (1) { last if not system @ARGV;
sleep 1 }"
I use it for commands like "force cvs update", which tries over and
over again until it succeeds. =)
-Ken
|
|
From: Steve P. <sp...@ep...> - 2003-07-21 21:12:37
|
Hi Ken,
Good to hear - will have a look at it when it comes out on CPAN (I
can't access anon. cvs for some reason?). Will be interesting to see
if it passes the CPAN+ tests :). Glad I could help out.
-Steve
On Monday, July 21, 2003, at 07:31 pm, Ken Williams wrote:
> Hi Steve,
>
> I've applied this patch in a modified form, and released a 0.19_02
> beta tarball containing it (on CPAN eventually, and on sourceforge
> now). Thanks a heap for doing this work!
>
> -Ken
>
> On Friday, July 18, 2003, at 12:55 PM, Steve Purkis wrote:
>
>> Hi,
>>
>> I've attached the manifypods patch, as discussed. All tests pass on
>> darwin and linux. It would be good if someone could test it on other
>> platforms (esp. those where the manpage_separator differs - see >
>> below).
>>
>> However, there's one problem with this patch:
>>
>> % ./Build fakeinstall
>> ...
>> Can't figure out where to install things of type 'bindoc' at
>> /.../lib/Module/Build/Base.pm line 1551.
>>
>> I think it's a problem with which Config.pm vars we're using, but I'm
>> not sure. I'll post a follow-up on this in a sec.
>>
>> Here's a summary of what's been done:
>> ok Move to Module::Build::Base
>>
>> ok Bump up $VERSION to dev release.
>>
>> ok Start using 'blib/libdoc' and 'blib/bindoc' (instead of man1 man3)
>> because that's what the rest of Module::Build uses.
>>
>> ok In the manpage_name method, you can call File::Spec->canonpath on
>> the
>> $file var before calling splitdir, and that should remove doubled
>> directory separators and other cruft.
>>
>> ok Don't manify unless file contains pod.
>>
>> ok Installation target - make sure it works
>>
>> ok customizable $self->{properties}:
>>
>> manify_bin_dirs => [qw( blib/scripts )]
>> manify_lib_dirs => [qw( blib/lib blib/arch )]
>>
>> ok Add manifypods dependency to *install Actions.
>>
>> ok Override manpage_separator() in OS-specific modules:
>> Default ::
>> Amiga ::
>> EBCDIC ::
>> MPEiX ::
>> MacOS ::
>> RiscOS ::
>> Unix ::
>> VMS __
>> VOS ::
>> Windows .
>> darwin ::
>>
>> o I couldn't find Module::Build alternatives for these MakeMaker
>> modules:
>> MM_DOS __
>> MM_OS2 .
>> MM_UWIN .
>>
>> Also, here's what I planned to do but didn't have time:
>> o Cache timestamps of files for each generated manpage, and check
>> them before re-generating to avoid unnecessary work.
>> o Don't generate man pages if installation dir is not set?
>> ala MakeMaker. Not sure if this is needed anymore - now the
>> user can set manify_*_dirs to an empty list. a 'no_manpages'
>> option would be a better bet at any rate...
>> o Refactor manify_lib|bin_pods() - they're pretty much the same.
>>
>> hth,
>> -Steve
>>
>> <Module-Build-0.19-manifypods2.patch>
>>
>>
|
|
From: Ken W. <ke...@ma...> - 2003-07-21 18:31:32
|
Hi Steve,
I've applied this patch in a modified form, and released a 0.19_02 beta
tarball containing it (on CPAN eventually, and on sourceforge now).
Thanks a heap for doing this work!
-Ken
On Friday, July 18, 2003, at 12:55 PM, Steve Purkis wrote:
> Hi,
>
> I've attached the manifypods patch, as discussed. All tests pass on
> darwin and linux. It would be good if someone could test it on other
> platforms (esp. those where the manpage_separator differs - see > below).
>
> However, there's one problem with this patch:
>
> % ./Build fakeinstall
> ...
> Can't figure out where to install things of type 'bindoc' at
> /.../lib/Module/Build/Base.pm line 1551.
>
> I think it's a problem with which Config.pm vars we're using, but I'm
> not sure. I'll post a follow-up on this in a sec.
>
> Here's a summary of what's been done:
> ok Move to Module::Build::Base
>
> ok Bump up $VERSION to dev release.
>
> ok Start using 'blib/libdoc' and 'blib/bindoc' (instead of man1 man3)
> because that's what the rest of Module::Build uses.
>
> ok In the manpage_name method, you can call File::Spec->canonpath on
> the
> $file var before calling splitdir, and that should remove doubled
> directory separators and other cruft.
>
> ok Don't manify unless file contains pod.
>
> ok Installation target - make sure it works
>
> ok customizable $self->{properties}:
>
> manify_bin_dirs => [qw( blib/scripts )]
> manify_lib_dirs => [qw( blib/lib blib/arch )]
>
> ok Add manifypods dependency to *install Actions.
>
> ok Override manpage_separator() in OS-specific modules:
> Default ::
> Amiga ::
> EBCDIC ::
> MPEiX ::
> MacOS ::
> RiscOS ::
> Unix ::
> VMS __
> VOS ::
> Windows .
> darwin ::
>
> o I couldn't find Module::Build alternatives for these MakeMaker
> modules:
> MM_DOS __
> MM_OS2 .
> MM_UWIN .
>
> Also, here's what I planned to do but didn't have time:
> o Cache timestamps of files for each generated manpage, and check
> them before re-generating to avoid unnecessary work.
> o Don't generate man pages if installation dir is not set?
> ala MakeMaker. Not sure if this is needed anymore - now the
> user can set manify_*_dirs to an empty list. a 'no_manpages'
> option would be a better bet at any rate...
> o Refactor manify_lib|bin_pods() - they're pretty much the same.
>
> hth,
> -Steve
>
> <Module-Build-0.19-manifypods2.patch>
>
>
|
|
From: Ken W. <ke...@ma...> - 2003-07-20 21:45:02
|
On Sunday, July 20, 2003, at 02:37 AM, Dave Rolsky wrote: > On Sun, 20 Jul 2003, Dave Rolsky wrote: > >> AFAICT, there's no way to tell Module::Build to run specific test >> _files_, >> as opposed to just one file. >> >> With EU::MM I can do "make test TEST_FILES='t/foo.t t/bar.t'" and it >> works, but with M::B neither of these works: >> >> ./Build test test_files='t/foo.t t/bar.t' > > Woah, it's way too late. This works fine. Yeah, both the examples you showed should work fine. -Ken |
|
From: Dave R. <au...@ur...> - 2003-07-20 07:38:32
|
On Sun, 20 Jul 2003, Dave Rolsky wrote: > AFAICT, there's no way to tell Module::Build to run specific test _files_, > as opposed to just one file. > > With EU::MM I can do "make test TEST_FILES='t/foo.t t/bar.t'" and it > works, but with M::B neither of these works: > > ./Build test test_files='t/foo.t t/bar.t' Woah, it's way too late. This works fine. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Dave R. <au...@ur...> - 2003-07-20 07:37:26
|
AFAICT, there's no way to tell Module::Build to run specific test _files_, as opposed to just one file. With EU::MM I can do "make test TEST_FILES='t/foo.t t/bar.t'" and it works, but with M::B neither of these works: ./Build test test_files='t/foo.t t/bar.t' ./Build test test_files=t/foo.t test_files=t/bar.t Ken, do you want a patch for this? -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Michael G S. <sc...@po...> - 2003-07-19 04:35:13
|
On Fri, Jul 18, 2003 at 07:24:45PM +0100, Steve Purkis wrote: > >However, there's one problem with this patch: > > > > % ./Build fakeinstall > > ... > > Can't figure out where to install things of type 'bindoc' at > > /.../lib/Module/Build/Base.pm line 1551. > > > >I think it's a problem with which Config.pm vars we're using, but I'm > >not sure. I'll post a follow-up on this in a sec. > > This also happens when you set 'install_dirs=vendor', but not 'core'. > > Config.pm is not setting 'installsiteman*dir' - at least not on my > machines. I don't know if this is something I've done wrong when > installing perl, but TBH I have fairly standard installs. installsiteman*dir and installvendorman*dir have only been introduced as Config variables in 5.8.1. Currently, 5.8.1 RC2 gets them slightly wrong. > More likely, we should be using one of the following for both 'site' > and 'vendor': > > installman*dir > man*dir > man*direxp Ideally, you'd want to follow the Config variables if present. If they're not present, what do you do? That's where things become a little fuzzy. Previous to the introduction of install(site|vendor)man*dir to Config, the installman*dir vars were used for everything by MakeMaker. Recently, I had it start guessing the value of installsiteman*dir and installvendorman*dir from siteprefix and vendorprefix. I'm somewhat convinced this is a good heuristic. I like the idea of core, site and vendor installations being totally seperate. Otherwise you could just fall back to the old behavior and use installman*dir if install(site|vendor)man*dir don't exist. -- It's Absinthe time! |
|
From: Steve P. <sp...@ep...> - 2003-07-18 18:24:54
|
On Friday, July 18, 2003, at 06:55 pm, Steve Purkis wrote: > However, there's one problem with this patch: > > % ./Build fakeinstall > ... > Can't figure out where to install things of type 'bindoc' at > /.../lib/Module/Build/Base.pm line 1551. > > I think it's a problem with which Config.pm vars we're using, but I'm > not sure. I'll post a follow-up on this in a sec. This also happens when you set 'install_dirs=vendor', but not 'core'. Config.pm is not setting 'installsiteman*dir' - at least not on my machines. I don't know if this is something I've done wrong when installing perl, but TBH I have fairly standard installs. More likely, we should be using one of the following for both 'site' and 'vendor': installman*dir man*dir man*direxp After reading the docs, I'd say use the first. Unfortunately I couldn't confirm this by looking through MakeMaker, and I'm outta time for today. Ideas? -Steve |
|
From: Steve P. <sp...@qu...> - 2003-07-18 18:17:26
|
On Friday, July 18, 2003, at 05:25 pm, Ken Williams wrote: > On Friday, July 18, 2003, at 11:08 AM, Ken Williams wrote: > >> On Friday, July 18, 2003, at 07:13 AM, Steve Purkis wrote: >> >>> Hiya, >>> >>> I figure this may be a known bug, but thought I'd report it anyway. >>> If I run: >>> >>> % perl -Mblib t/runthrough.t >>> >>> it fails - see below for the error. When I checked >>> ACTION_disttest(), I saw the line: >>> >>> # XXX doesn't propagate @INC >>> >>> which looks to me like the problem. Not a show-stopper, but >>> confusing in development. >> >> >> Hi Steve, >> >> This is a semi-known bug. =) Meaning that it's known, but not really >> understood yet. Ah, one of those eh? :) > So, maybe the patch below is all that's required. (Patch is against > current CVS.) That's done it. FYI: looks like cmdline arguments were not filtering through in $self->run_perl_script. Before I applied your patch, this worked: PERL5LIB=$PWD/blib/lib perl t/runthrough.t If this pops up somewhere else, it might be an idea to move the fix into run_perl_script()... Ta for that, -Steve |
|
From: Steve P. <sp...@ep...> - 2003-07-18 17:58:54
|
Hi,
I've attached the manifypods patch, as discussed. All tests pass on
darwin and linux. It would be good if someone could test it on other
platforms (esp. those where the manpage_separator differs - see below).
However, there's one problem with this patch:
% ./Build fakeinstall
...
Can't figure out where to install things of type 'bindoc' at
/.../lib/Module/Build/Base.pm line 1551.
I think it's a problem with which Config.pm vars we're using, but I'm
not sure. I'll post a follow-up on this in a sec.
Here's a summary of what's been done:
ok Move to Module::Build::Base
ok Bump up $VERSION to dev release.
ok Start using 'blib/libdoc' and 'blib/bindoc' (instead of man1 man3)
because that's what the rest of Module::Build uses.
ok In the manpage_name method, you can call File::Spec->canonpath on the
$file var before calling splitdir, and that should remove doubled
directory separators and other cruft.
ok Don't manify unless file contains pod.
ok Installation target - make sure it works
ok customizable $self->{properties}:
manify_bin_dirs => [qw( blib/scripts )]
manify_lib_dirs => [qw( blib/lib blib/arch )]
ok Add manifypods dependency to *install Actions.
ok Override manpage_separator() in OS-specific modules:
Default ::
Amiga ::
EBCDIC ::
MPEiX ::
MacOS ::
RiscOS ::
Unix ::
VMS __
VOS ::
Windows .
darwin ::
o I couldn't find Module::Build alternatives for these MakeMaker
modules:
MM_DOS __
MM_OS2 .
MM_UWIN .
Also, here's what I planned to do but didn't have time:
o Cache timestamps of files for each generated manpage, and check
them before re-generating to avoid unnecessary work.
o Don't generate man pages if installation dir is not set?
ala MakeMaker. Not sure if this is needed anymore - now the
user can set manify_*_dirs to an empty list. a 'no_manpages'
option would be a better bet at any rate...
o Refactor manify_lib|bin_pods() - they're pretty much the same.
hth,
-Steve
|
|
From: Ken W. <ke...@ma...> - 2003-07-18 16:26:09
|
On Friday, July 18, 2003, at 11:08 AM, Ken Williams wrote:
>
> On Friday, July 18, 2003, at 07:13 AM, Steve Purkis wrote:
>
>> Hiya,
>>
>> I figure this may be a known bug, but thought I'd report it anyway.
>> If I run:
>>
>> % perl -Mblib t/runthrough.t
>>
>> it fails - see below for the error. When I checked
>> ACTION_disttest(), I saw the line:
>>
>> # XXX doesn't propagate @INC
>>
>> which looks to me like the problem. Not a show-stopper, but
>> confusing in development.
>
>
> Hi Steve,
>
> This is a semi-known bug. =) Meaning that it's known, but not really
> understood yet.
So, maybe the patch below is all that's required. (Patch is against
current CVS.)
-Ken
Index: lib/Module/Build/Base.pm
===================================================================
RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v
retrieving revision 1.144
diff -u -r1.144 Base.pm
--- lib/Module/Build/Base.pm 14 Jul 2003 18:00:29 -0000 1.144
+++ lib/Module/Build/Base.pm 18 Jul 2003 16:24:19 -0000
@@ -1286,7 +1286,8 @@
my $dist_dir = $self->dist_dir;
chdir $dist_dir or die "Cannot chdir to $dist_dir: $!";
# XXX could be different names for scripts
- # XXX doesn't propagate @INC
+
+ local $ENV{'PERL5LIB'} = join $self->{config}{path_sep}, @INC;
$self->run_perl_script('Build.PL') or die "Error executing
'Build.PL' in dist directory: $!";
$self->run_perl_script('Build') or die "Error executing 'Build' in
dist directory: $!";
$self->run_perl_script('Build', [], ['test']) or die "Error
executing 'Build test' in dist directory";
===================================================================
|
|
From: Ken W. <ke...@ma...> - 2003-07-18 16:09:07
|
On Friday, July 18, 2003, at 07:13 AM, Steve Purkis wrote: > Hiya, > > I figure this may be a known bug, but thought I'd report it anyway. > If I run: > > % perl -Mblib t/runthrough.t > > it fails - see below for the error. When I checked ACTION_disttest(), > I saw the line: > > # XXX doesn't propagate @INC > > which looks to me like the problem. Not a show-stopper, but confusing > in development. Hi Steve, This is a semi-known bug. =) Meaning that it's known, but not really understood yet. I'm not sure why % perl -Mblib t/runthrough.t fails, but % perl Build test test_files=t/runthrough.t succeeds. Do you understand why? -Ken |
|
From: Steve P. <sp...@qu...> - 2003-07-18 12:13:52
|
Hiya,
I figure this may be a known bug, but thought I'd report it anyway. If
I run:
% perl -Mblib t/runthrough.t
it fails - see below for the error. When I checked ACTION_disttest(),
I saw the line:
# XXX doesn't propagate @INC
which looks to me like the problem. Not a show-stopper, but confusing
in development.
-Steve
Error output:
...
/usr/bin/perl Build test
test....NOK 2# Test 2 got: '/Library/Perl/Module/Build.pm' (test.pl at
line 11)
# Expected: qr{(?-xism:blib)}
test....FAILED test 2
Failed 1/2 tests, 50.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
------------------------------------------------------------------------
-------
test.pl 2 1 50.00% 2
Failed 1/1 test scripts, 0.00% okay. 1/2 subtests failed, 50.00% okay.
not ok 9
# Test 9 got: 'Error executing 'Build test' in dist directory at
/Users/spurkis/development/perl/Module-Build-0.19.orig/blib/lib/Module/
Build/Base.pm line 1277.
' (t/runthrough.t at line 58)
# Expected: ''
not ok 10
# Failed test 10 in t/runthrough.t at line 61
...
|
|
From: Ken W. <ke...@ma...> - 2003-07-16 14:48:36
|
On Wednesday, July 16, 2003, at 03:13 AM, Steve Purkis wrote:
> On Wednesday, July 16, 2003, at 12:26 am, Ken Williams wrote:
>>
>> Section 3 pods should probably be generated from blib/lib and
>> blib/arch, and section 1 pods should be generated from blib/script.
>> This is because theoretically, the process of copying lib/* to
>> blib/lib/* and the like can do all kinds of transformations on the
>> POD. For instance, in Mason we can transform some special P<> tags
>> to normal POD.
>
> Easy enough - I can just do an rscan of those dirs then. That also
> answers my concerns about checking for pod in .c, .xs, and other > files.
Yup.
>
> Should we also look in blib/bin for section 1 pods, or does that only
> ever contain binaries (ie: no shell scripts)?
That's a good question - I don't *think* it ever contains shell
scripts, but in truth I actually have no idea. We might have to punt
on this until we hear what the right behavior should be.
>
> Also, would it be a good idea to have a customizable set of dirs in
> say $self->{properties}{manify} ala:
>
> section1 => [qw( blib/scripts )]
> section3 => [qw( blib/lib blib/arch )]
>
> That way, if something gets missed at least the user can override it.
Yeah, that's a good idea.
-Ken
|
|
From: Steve P. <sp...@ep...> - 2003-07-16 08:13:58
|
On Wednesday, July 16, 2003, at 12:26 am, Ken Williams wrote:
> On Monday, July 14, 2003, at 04:15 PM, Dave Rolsky wrote:
>
>> On Mon, 14 Jul 2003, Steve Purkis wrote:
>> - Section 1 pods should be generated based on the files found by
>> $self->find_script_files, I think.
>>
>> - Section 3 pods should be generated based on $self->find_pod_files,
>> and
>> $self->find_pm_files. These are higher level than running
>> ->rscan_dir and
>> allow the module maintainer to specify which files to process. If you
>> just run rscan_dir yourself you'd be ignoring that.
>
>
> Section 3 pods should probably be generated from blib/lib and
> blib/arch, and section 1 pods should be generated from blib/script.
> This is because theoretically, the process of copying lib/* to
> blib/lib/* and the like can do all kinds of transformations on the
> POD. For instance, in Mason we can transform some special P<> tags to
> normal POD.
Easy enough - I can just do an rscan of those dirs then. That also
answers my concerns about checking for pod in .c, .xs, and other files.
Should we also look in blib/bin for section 1 pods, or does that only
ever contain binaries (ie: no shell scripts)?
Also, would it be a good idea to have a customizable set of dirs in say
$self->{properties}{manify} ala:
section1 => [qw( blib/scripts )]
section3 => [qw( blib/lib blib/arch )]
That way, if something gets missed at least the user can override it.
PS: patch half-written, but won't likely have time to finish 'till
Friday.
-Steve
|
|
From: Ken W. <ke...@ma...> - 2003-07-15 23:26:38
|
On Monday, July 14, 2003, at 04:15 PM, Dave Rolsky wrote: > On Mon, 14 Jul 2003, Steve Purkis wrote: > - Section 1 pods should be generated based on the files found by > $self->find_script_files, I think. > > - Section 3 pods should be generated based on $self->find_pod_files, > and > $self->find_pm_files. These are higher level than running ->rscan_dir > and > allow the module maintainer to specify which files to process. If you > just run rscan_dir yourself you'd be ignoring that. Section 3 pods should probably be generated from blib/lib and blib/arch, and section 1 pods should be generated from blib/script. This is because theoretically, the process of copying lib/* to blib/lib/* and the like can do all kinds of transformations on the POD. For instance, in Mason we can transform some special P<> tags to normal POD. -Ken |
|
From: Steve P. <sp...@ep...> - 2003-07-15 10:15:50
|
On Monday, July 14, 2003, at 10:31 pm, Michael G Schwern wrote: > Note the replace_manpage_separator overrides in MM_Cygwin, MM_DOS, > MM_OS2, > MM_UWIN etc... when determining how to translate a module name to a > man page > appropriate to the system. Oops.. I should've caught that. Thanks for pointing it out - will bung it in as well. -Steve |
|
From: Steve P. <sp...@ep...> - 2003-07-15 10:09:37
|
On Monday, July 14, 2003, at 10:15 pm, Dave Rolsky wrote: > On Mon, 14 Jul 2003, Steve Purkis wrote: > >> I've got a wee bit of experience with MakeMaker's manifypods target, >> and seeing as the manifypods Action isn't implemented yet and it's >> something I need before I can switch over, I decided to have a go at >> it. Hope I'm not stepping on anyone's toes... > > I was thinking of doing it, but I didn't really want to, so I'm happy > to > see your patch. Good-o.. I'm happy to be able to help :). >> I got as far as generating MAN3 pods - no installation or MAN1 pods >> yet, but it's getting late and I thought now might be a good time to >> stop and get some feedback. So I've attached a patch, comments are >> welcome. Will prolly finish it off later this week if people like the >> look of it.. > > A couple things: > > - This should be part of Module::Build::Base, not a separate file Yeah, it will do - I just find it easier to write tests & code together sometimes.. keeps me focused, & can be quicker. Once I think its done I move it where it belongs & see if it breaks anything else. > - Section 1 pods should be generated based on the files found by > $self->find_script_files, I think. If not, it'll do as a starting point. Is there a chance modules will have Pod in .xs or .c files, binaries, or maybe something like bin/foo.pod ? > - Section 3 pods should be generated based on $self->find_pod_files, > and > $self->find_pm_files. These are higher level than running ->rscan_dir > and > allow the module maintainer to specify which files to process. If you > just run rscan_dir yourself you'd be ignoring that. Good point - I'll switch that over. > - In the manpage_name method, you can call File::Spec->canonpath on the > $file var before calling splitdir, and that should remove doubled > directory separators and other cruft. Another good point; will roll that in. > Otherwise it looks good. For the install bits, I think it's as simple > as > the patch below my sig. A one-liner... is that really it? Well, I'm glad I stopped when I did otherwise I would've sat for hours trying to suss that out ;-). I'll roll all this together into a proper patch over the next few days. Ta for the comments, -Steve |
|
From: Michael G S. <sc...@po...> - 2003-07-14 22:04:40
|
Note the replace_manpage_separator overrides in MM_Cygwin, MM_DOS, MM_OS2,
MM_UWIN etc... when determining how to translate a module name to a man page
appropriate to the system.
--
Keep your stick on the ice.
-- Red Green
|
|
From: Dave R. <au...@ur...> - 2003-07-14 21:17:29
|
On Mon, 14 Jul 2003, Steve Purkis wrote: > I've got a wee bit of experience with MakeMaker's manifypods target, > and seeing as the manifypods Action isn't implemented yet and it's > something I need before I can switch over, I decided to have a go at > it. Hope I'm not stepping on anyone's toes... I was thinking of doing it, but I didn't really want to, so I'm happy to see your patch. > I got as far as generating MAN3 pods - no installation or MAN1 pods > yet, but it's getting late and I thought now might be a good time to > stop and get some feedback. So I've attached a patch, comments are > welcome. Will prolly finish it off later this week if people like the > look of it.. A couple things: - This should be part of Module::Build::Base, not a separate file - Section 1 pods should be generated based on the files found by $self->find_script_files, I think. - Section 3 pods should be generated based on $self->find_pod_files, and $self->find_pm_files. These are higher level than running ->rscan_dir and allow the module maintainer to specify which files to process. If you just run rscan_dir yourself you'd be ignoring that. - In the manpage_name method, you can call File::Spec->canonpath on the $file var before calling splitdir, and that should remove doubled directory separators and other cruft. Otherwise it looks good. For the install bits, I think it's as simple as the patch below my sig. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ --- Base.pm.~1.139.~ 2003-07-07 12:52:48.000000000 -0500 +++ Base.pm 2003-07-14 16:16:47.000000000 -0500 @@ -56,7 +56,7 @@ build_requires => {}, conflicts => {}, perl => $perl, - install_types => [qw(lib arch script)], + install_types => [qw(lib arch script man1 man3)], installdirs => 'site', include_dirs => [], %input, |
7 messages has been excluded from this view by a project administrator.
