You could store all of the documentation in a single file and access it using the core module Pod::Select. The following example reads the NAME POD section from a file and displays it on STDOUT:
#!/usr/bin/perl -w
use strict;
use Pod::Select;
my $parser = new Pod::Select();
$parser->select("NAME");
$parser->parse_from_file("Module.pm", "-");
__END__
However, the POD that is displayed is in raw format without any translation of the POD escapes. So you would probably have to write the data to an intermediary file, or IO::Scalar object, and massage the data.
In the end it may be simpler to create your own selection routine, perhaps via Pod::Parser or Pod::Simple.
--
John.
| [reply] [d/l] |
Here is one potential solution (just wrap it in a sub and
tweak a litle), if you insist on having a single master pod file for all your apps.
use Pod::POM;
use Pod::POM::View::Text;
my $view = Pod::POM::View::Text->new();
my $parser = Pod::POM->new();
# parse from text or file
my $pom = $parser->parse_file(__FILE__) || die $parser->error();
# examine any warnings raised
for my $warning ($parser->warnings()) {
warn $warning, "\n";
}
#use Data::Dumper; die Dumper $pom; # in case you wanna know what it l
+ooks like
for my $head1 ($pom->head1()) {
if( $head1->title() =~ /Popcorn app/i ) {
print $head1->present($view); # display as text
## same thing
# print $view->print($head1);
# print Pod::POM::View::Text->print($head1);
last;# bust out of the for loop
}
}
__DATA__
=head1 Butter app
Butter app does this'n'that, and this'n'this
=head2 Options
blah blah
=head1 Popcorn app
Popcorn app does this'n'that, and this'n'this
=head2 Options
blah blah
=head1 Fudge app
Fudge app does this'n'that, and this'n'this
=head2 Options
blah blah
=cut
It is important to note that Pod::POM has a few minor logic flaws, but for casual pod it doesn't matter.
Pod::POM does not handle =begin format/=end format correctly. It insists on searching the stuff in between for Formatting Codes, which it shouldn't do except in special circumstances. I rather like the module, and have contacted the author about this problem.
MJD says you
can't just make shit up and expect the computer to know what you mean, retardo!
** The Third rule of perl club is a statement of fact: pod is sexy.
|
| [reply] [d/l] |
There is an alternative approach that I have used in just such a situation that I think is worth considering.
You can place all your POD in a single file for documentation/admin and then have a script that creates the individual PODs for each script either as .POD or rewriting the original file.
This is a bit of a kludge and only really works with small groups of closely related files where updating one will directly impact another (ie if A requires B then B doc may say required by A). It is also nice for due diligence when you can extract an overview that maps to the spec and show how it maps all the way down to the code level.
You can also use this approach when starting a project if you have a clear functional/technical specification to auto create documented stubs for your packages or scripts.
Hope this is not too confused
UnderMine | [reply] |
This sounds like the perfect situation for the Pod::Usage module, which brother ybiC has conveniently written a tutorial for (in association with that other most marvellous module Getopt::Long).
HTH
_________ broquaint | [reply] |