http://qs321.pair.com?node_id=211153


in reply to Re: Pod::Master
in thread Pod::Master

Thanks!.

Oh yeah, I switched SYNOPSIS/DESCRIPTION, d'oh ;)

And the 2nd d'oh, I generated that page by hand , without the --header option, here's what it really looks like by default (d'oh).

Now, I am not subclassing Pod::Html, so whatever Pod::Html does, it does on its own (i myself like the toc)

What does Will this be handled in a generic POD way, or will it take advantage of that nifty INSTALLED MODULES format? mean?

What is a "generic POD way"? And how would I take advantage of "that nifty INSTALLED MODULES format?"

I kind of think DEPENDENCIES belong in the README/Makefile.PL, so that's why I didn't put it in the pod.

I'm pretty satisfied with Pod::Html and I don't plan on re-inventing it any time soon (i'm satisfied in writing patches ;)

____________________________________________________
** The Third rule of perl club is a statement of fact: pod is sexy.

Replies are listed 'Best First'.
Re: Re: Re: Pod::Master
by mojotoad (Monsignor) on Nov 07, 2002 at 18:00 UTC
    Don't get me wrong, I like the TOC as well -- it was just an issue of visually locating the name of the module immediately.

    By generic POD I just meant normal =head1 plus either items or a comma-separated list of dependencies. It wasn't really a clearly thought-out question, but it seemed you had more going on with the code that generated the INSTALLED MODULES than merely POD parsing. I guess I'm secretly desiring some tool, other than perl -c, that will recursively trace dependencies and present them in an outline format.

    You are right that lots of modules do indeed put the dependencies in README/Makefile.PL (as well as perhaps POD). A dependency-sniffer would no doubt get tripped up on optional dynamic dependencies as well. :(

    Matt