Discipulus, your recent chatterbox mention of this meditation reminded me that I'd never replied. You already linked to the main things I thought of as "tricks" in my Makefile.PL, so at the time, I didn't think I had anything to add. But on a re-read, I might have more to say.

Your link to overriding existing EU::MM builtin targets was one I hadn't noticed in the EU::MM docs, so that was useful. When I had wanted to accomplish the same goal, I was able to use the Double-Colon Rule syntax and add a second target with the same name, which will get run after the builtin version. In a situation like The drawbacks that I had found over time to that methodology include: 1) it only works on the targets that EU::MM defined with :: instead of : , so it cannot "add" to single-colon rules (like distdir appears to be); (2) it can only be run after the builtin version (the gnu make manual strongly recommends only using it for truly independent rules that you just want to run with the same name, so that order shouldn't matter); and (3) it doesn't allow adding extra dependencies to the builtin version of the rule. Now that I know about the builtin-target override feature in Makefile.PL, I think I can overcome all three of those limitations, which is great.

And with reference to my Makefile.PL, I might as well briefly describe the "tricks" behind them...

1. TEST_D - explained in my earlier post
2. realclean :: - this is my double-colon addition to the builtin realclean target, which deletes extra files that the builtin realclean doesn't
3. populateversion :: - this grabs the version from the main .pm file and propagates it to the other module files, so that all the modules in the dist will keep the same version
4. README.md :: , LICENSE :: , and docs :: - these automatically create the README.md from certain sections of the POD and the LICENSE file from appropriate sections of the POD, so that if I update the POD, the standalone files will match
5. all_msgs :: and following - these are rather specific to the project (they help me automate grabbing source files from Notepad++ so that when NPP updates its list of windows messages and similar, I can more easily incorporate those new messages into my project)

Like you said, you don't want to have to remember to run commands like gmake docs to update the document; I solve it in a less-automated way -- I have it in my how to release notes, to remind myself to update the documentation. I don't think I'm going to bundle it with gmake dist, because I want to make sure the docs are all up-to-date and committed to the repo before I generate my final distribution tarball. But each of us have our own workflow.

I've noticed that all of those customizations are on the authoring side. I'm curious whether anyone out there has customized anything from the end-user side (that would change the default behavior of the make/make-test/make-install idiom) -- I cannot think of anything widely practical from the end-user perspective, so I'd like to see if anyone has done something brilliant in that regard.