in reply to VERSION section in POD

I wrote 1119138 to generate a pod file for my Perl programs and modules. I have since updated it to include a new kind of Perl6 comment. (as LanX pointed out, where there is both a Module.pm and Module.pod perldoc will use Module.pod (same is true for metacpan.org))

Among other things, it parses the $VERSION = 1.23; statement to generate the VERSION section in the pod file.

It can also parse the package statement to generate the NAME section.

Replies are listed 'Best First'.
Re^2: VERSION section in POD
by polettix (Vicar) on May 19, 2016 at 07:37 UTC
    Getting the version number to put in the POD is not a problem, as it's already available in Dist::Zilla/Milla when I call the transformation script in dist.ini (that's %v inside the Run::AfterBuild section): 
    abstract = Text and data canalising

[CopyFilesFromRelease/Tubergen]
filename = script/tubergen

[@Milla]
Git::Check.allow_dirty = script/tubergen
Git::Commit.allow_dirty = script/tubergen

[Run::AfterBuild]
run = support/podversion.pl "%d" "%v"
run = support/tubergen-bundle.pl "%d" "%v"

[PruneFiles]
filename = cpanfile.snapshot
match = ^support/

    [download]

    Good to know that others see value in the VERSION section, anyway, so thanks for taking the time!

    perl -ple'$_=reverse' <<<ti.xittelop@oivalf

    Io ho capito... ma tu che hai detto?
[reply]
[d/l]
[select]

      The reason I wrote the "documentation comments" to POD converter was POD, in Perl5, requires repeating a lot of information that is already present in the code. In Perl6, Pod has an enhanced syntax that allows to referring to information in the surrounding code. Though I didn't know that when I wrote my converter.

      The reason I chose to convert from Doxygen style comments was that I already use Doxygen for producing the "low level" design documentation in C/C++, which is what is used at many companies producing electronic control modules. Advantages of doing this include most of the function prototypes and data structures are in place by the time the design is approved, and all of the (text of the) documentation is in the comments of the code, so is much easier to keep the docs and code in sync as changes get made. And, of course, no repeating information that's already in the code (unless you count the descriptions of what the code is supposed to do as repeating the code).

[reply]

In Section Seekers of Perl Wisdom