Thread: [Module-build-general] Hello and manifypods
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Steve P. <sp...@ep...> - 2003-07-14 20:06:39
Attachments:
Module-Build-0.19-manifypods.patch
|
Hi list, I'm a Module::Build newbie - I've been playing with it the past couple of days and see a lot of potential with the project. Kudos to Ken for starting it up! 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 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.. Regards, -Steve |
|
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, |
|
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: 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: 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-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-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
|
Thanks for helping keep SourceForge clean.
X