But AFAIK is makefile.pl only relevant when installing from CPAN on the client side.

AFAI-do, yes-and-no.

Makefile is my friend and assistant: it runs for me tests, benchmarks and, like Discipulus wants to do: creates a readme from pod in various formats. This is in the tradition of Autotools/automake. In which just one last target (of many): make dist will create a tarball of the project for distributing it to end-users with all dev-related files filtered out. (btw I usually add make push-git to spare me the grory task of interacting with that abomination called git.)

That means that, in this style, there are 2 makefiles, one for the developer and one for the end-user. The latter created automatically, so there is no need to maintain 2 makefiles actually. However, please correct me if I am wrong, but this is not the case with ExtUtils::MakeMaker which, as LanX points out, assumes or imposes that Makefile.PL is for the end-users' benefit only. Assuming that only *they* are the only lazy (or dumb or forgetfull) link in the project's development chain!

Now, if there was a competition for the most lazy developer I would lose it because I would be too busy crafting an automated system for submitting my entry with just make submit && make win ...

So, I claim back my right to laziness and chose to inflate Makefile.PL with targets that the end user will never want to use - (caveat: that entails the danger of exposing sensitive urls/passwords). Because I want to have a functional, development-stage, Makefile fit for my lazy lifestyle.

10 minutes EDIT: See Re: let Makefile.PL to do the Readme file for me -- new target? for an alternative which involves other tools.

bw, bliako