On Wednesday, November 13, 2002, at 11:24 , Michael G Schwern wrote:
Ok, here's the manifypods() patch as I've put into MakeMaker. Its expanded
quite a bit, some due to my tinkering, but a lot due to considering the
non-Unix code. Its an interesting example of how patches go from submission
to acceptance in MakeMaker and why maintaining this module is so bloody
time-consuming.
- ExtUtils::Command::MM::pod2man
I decided to make it work as close to the pod2man utility as possible, so I
just stole the argument handling code out of pod2man. I fooled Getopt::Long
into working by placing pod2man()'s arguments into a local @ARGV. :)
Good solution. It's also a good way around the backwards compatibility problems you mentioned before.
I also decided the change in output dignostics (ie. from "Manifying*sniff!* :-)
$outfile" to "Manifying section...") wasn't necessary. I can be convinced
if you think its an improvement.
I do like that style of diagnostics - combined with indentation I find it
makes the output much easier to read. But I can appreciate that it does
not really fit in with MM style output. It would have to be applied across
MM to be of any real use.
- ExtUtils::MM_Unix::manifypodsWhich in turn should make the code I was working on originally a bit easier
I've eliminated the "make it a NOOP if there's no POD to convert" code
because this makes the Makefile less flexible (ie. if you override MAN3PODS
you have to rebuild the Makefile to get man pages to generate). Since
manifypods isn't groping around anymore to find pod2man, there's no real
cost in generating the complete command. pod2man will gracefully deal with
having no files to convert.
to manage. Glad I submitted that first patch ;-)
- ExtUtils::MM_Unix::manifypods_target
I've changed the output of manifypods_target. I decided, for the moment,
*_target methods should return *only* the target code and nothing else. No
macros, no additional targets. This makes overriding them easier.
Agreed.
manifypods() will simply combine the results from POD2MAN_EXE_macro() andYeah, I couldn't make up my mind between '_def' and '_var'. ATM I prefer
manifypods_target().
- ExtUtils::MM_Unix::pod2man_def is now POD2MAN_EXE_macro
AFAIK they're refered to as macros (or variables in the GNU make world, but
that's too confusing). I could be wrong.
'_var' because they remind me of environment variables. But _macro() does
the trick - I think it's more important to be consistent.
I felt it better if the method name exactly matched the macro name.
Also agreed - it will be much easier to override macros this way. Not to get ahead of the game, but it would be nice to see _target and _macro applied religiously throughout MM (bearing in mind backwards compatibility). Not that it would be any small task! But if would be consistent, and useful for overriding.
I've eliminated the POD2MAN macro and am simply using POD2MAN_EXE. I having two was redundant and leaving POD2MAN_EXE in place solves some backwards compat problems.
Fair enough.
- Eliminated MM_Cygwin::manifypods override
- Removed Cygwin tests for failing to find pod2man
- Eliminated MM_VMS::manifypods override
- Eliminated MM_Win32::manifypods override
- Removed Win32 and Netware specific tests for noop manifypods
- MM_Unix::manifypods, manifypods_target & POD2MAN_EXE_macro moved to MM_Any
Since all the manifypods() overrides have been eliminated I guess that makes
the new manifypods() portable. So it was moved out of MM_Unix and into
MM_Any.
Bonus! :)
You made lots of redundant code disappear. Not a bad day's work, Steven!Looks good - I'm glad I could help.
I've updated the snapshot on makemaker.org. Here's the patch as it went in.
Thanks for the ideas & suggestions, recognizing all the knock-on effects and
doing all the integration work. And maintaining that beast in the first place!
-Steve
