I've run into this problem myself
Updated: 2013-01-30 Eastern Standard Time
Reason: reply by Anonymous monk
I have no acceptable* solution for preventing Module::Build from building Html from POD in the distribution. I have found, however, a way to prevent it from installing Html files when I issue the ./Build install command.
Reported based on installed Module::Build v0.38
I'm going to make the reader at least see this stuff, first, before I show how:
My development machine has been for 2 years, a netbook running M$WyyndWoes 7 on a Intel™ Atom™ CPU. I have lately been using a workflow in which I build and install any new module I snag from CPAN for both CygwinPerl and for StrawberryPerl, at the same time. For either of these, the building of the Html is stupendously slow. I hear you (you know who you are) ..."well get a real development machine!!!!!". Please. My observation is just an extreme instance of a representative kind of collateral damage arising from what seems to have been (or will continue to be?) pervasive assumptions on the part of a fullsome portion of the Perl community. The overall group of prominant contributors to modern Perl sometimes seems to include people who are unable to admit to adhering to false assumptions about the differences (lack thereof) between the platform they favor vs. the ones others use. These are the yous I was addressing. So my response is: "become a professional engineer" (who knows the principle that "Unchecked assumptions are Problem No. 1").
It shouldn't work this way.
The fact that a user cannot prevent Module::Build from building Html except by editing Config.pm* (one respondent's expectations were incorrect in this earlier reply and this other response by rhesa is partially correct) …demonstrates that there is some legitimacy to user complaints about Module::Build. This is not the kind of thing that ought to be taken out of the hands of the user.
I think (based on reading a fair amount of exchanges on various matters, on relevant mailing lists, etc.) that the mindset is "how could that ever be a real problem." And I expect that the mindset is so strong that even if told that it is a problem by some users, a stone wall will sit there being whatever stone is (apparently, deaf).
The solution as promised
Telling Module::Build that there is no place to install Html docs does no good. As a previous contributor cited, I tried (on several occasions, including an occasion tonight)$ perl Build.PL --install_path binhtml= --install_path libhtml=
The building of Html still happens. But I discovered (apparently, Geek Rage is the step-Mother of Invention) that one can sometimes fool Module::Build:$ ./Build install --install_path libhtml="/dev/null #" --install_path binhtml="/dev/null #"
Tested only on CygwinPerl. On M$WhyyndWoes /dev/null is NUL and # is not a shell comment character. Exercize is therefore left to the reader.
I'll show the results of trying some other things. Note that there is a null solution here. These flags still do not work.
$ perl Build.PL Checking whether your kit is complete... Looks good Checking prerequisites... Looks good Deleting MYMETA.yml Removed previous 'MYMETA.yml' Deleting MYMETA.json Removed previous 'MYMETA.json' Created MYMETA.yml and MYMETA.json Deleting Build Removed previous script 'Build' Creating new 'Build' script for 'Module-Runtime' version '0.013' $ ./Build fakeinstall Building Module-Runtime Copying lib/Module/Runtime.pm -> blib/lib/Module/Runtime.pm Manifying blib/lib/Module/Runtime.pm -> blib/libdoc/Module.Runtime.3pm Converting Pod to HTML with Pod::Html 1.11 HTMLifying blib/lib/Module/Runtime.pm -> blib/libhtml/site/lib/Module/ +Runtime.html P::H::pod2html --flush --title=Module::Runtime - runtime module handli +ng --podpath=lib/perl5/5.14:bin:lib/perl5/site_perl/5.14 --infile=bli +b/lib/Module/Runtime.pm --outfile=blib/libhtml/site/lib/Module/Runtim +e.tmp --podroot=/usr --htmlroot=../../.. --header --backlink=Back to +Top Installing /usr/local/lib/perl5/Module/Runtime.pm Installing /usr/local/share/man/man3perl/Module.Runtime.3pm Installing /usr/local/html/site/lib/Module/Runtime.html Writing /usr/local/lib/perl5/cygwin-thread-multi-64int/auto/Module/Run +time/.packlist $ printenv PERL_MB_OPT --verbose --install_base=/usr/local --install_path bindoc=/usr/local/s +hare/man/man1 --install_path libdoc=/usr/local/share/man/man3perl --c +onfig installhtmldir= --config installhtml1dir= installhtml3dir= --co +nfig installsitehtml1dir= installsitehtml3dir= $ exit
Notice the output line:
* Editing Config.pm is considerably unacceptable where a package manager is managing the perl installation (by upgrading with files created by a package-creation worker somewhere far, far away). As is the case for the vast majority of users of Perl ( /machines where perl is installed/ ) now.