On Mon, Mar 12, 2012 at 12:38 AM, Michael Roberts <mich...@vivtek.com>wrote:
> On 3/12/2012 12:43 AM, David Oswald wrote:
> >> Perhaps I should look (at some point) at moving some of the
> >> configuration logic out of Makefile.PL and into a CPP.pm.PL file for
> >> Inline::CPP. CPP.pm.PL could read the existing CPP.pm and write out
> >> the changes much like the way Makefile.PL does it, but under the
> >> direction of ExtUtils::MakeMaker instead of directly under
> >> Makefile.PL.
> I'm going to have to try this out, but I worry about make getting
> confused if X.pm.PL reads from, then writes to, X.pm. That would be my
> favorite way to organize things (not least because it wouldn't break the
> CPAN documentation system), but I'm not sure it'll work correctly.
>
First, CPAN looks for pod in *all* files and indexes them. And more
specifically to your point, it even lists documentation found in files like
Module.pm.PL as Modules, not Documentation. (This is one reason why I wish
PDL would move away from the custom .pd file extension and use .pm.PL. But
I digress.) This means that this documentation will properly show up:
------------%<------------Module.pm.PL------------%<------------
open my $fh, '>', 'Module.pm';
print $fh <<DOCS
=head1 NAME
Module.pm - my fancy module!
=cut
DOCS
------------>%------------>%------------
Second, there's no reason you couldn't have a Module.pm file that is edited
by any sort of script at build time, and in which you have special
placeholders. This might lead to a codebase that is more legible than the
standard heredoc-based .pm.PL files.
------------%<------------Module.pm------------%<------------
=head1 NAME
Module.pm - my fancy module!
=cut
sub boring_function {
# blah
}
## BEGIN_DYNAMIC_CONTENT_FANCY_FUNCTION
# Stuff in here gets replaced with code generated during the build phase
sub fancy_function {
die "This function is dynamically generated!\n"
. "You must build this module using the standard Perl Makefile.PL
process.";
}
## END_DYNAMIC_CONTENT_FANCY_FUNCTION
------------>%------------>%------------
This is Perl, so there are (too?) many ways to do it. :-)
> >> That reminds me, there's another solution to the OP's question. His
> >> module could be adapted to simply read a configuration file on
> >> startup, and that config file could be built at configuration/install
> >> time. Config::General could help to avoid rolling a new solution.
> I thought of that, but it seems inelegant. I'd much rather configure
> the PM directly during installation. I'm actually pretty excited about
> this mechanism; it's neat!
>
> Michael
>
>
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
