这是我之前关于开发 Perl 应用程序的问题的后续。假设我使用Module::Install. 现在我将代码上传到生产服务器，比如使用git push.，我想安装Makefile.PL. 如果我只是简单地运行cpan .，它会尝试像普通的 Perl 模块一样安装应用程序，即。开始将模块和文档复制到整个系统的标准 Perl 目录。
这是它应该的方式吗？您是否将应用程序安装到标准 Perl 目录中？我习惯于将我的 Perl 应用程序放在一个单独的目录中lib。否则，我似乎必须管理很多其他事情，比如将资源安装在路径上的某处等。如果我只想安装声明的 depsMakefile.PL并运行应用程序测试以确保一切正常，我该怎么办？
（这是否记录在某处？我的意思是，是否有部署和更新非平凡 Perl 应用程序的最佳实践之类的东西？或者每个人都以自己的方式做这件事？）
我可能会误解，但我认为你正在寻找的是
perl Makefile.PL
make installdeps
如果您使用的是Module::Install，那么您实际上是在幕后使用ExtUtils::MakeMaker 。您可以使用 MakeMaker 的所有功能及其提供的目标。尽管文档没有显示所有功能，但在生成的Makefile.
然而，MakeMaker这是旧消息，大多数人都要求圣诞老人让它消失。如果您想要更好的控制，包括创建自己的目标和流程，Module::Build更容易使用以及跨平台（即使这只是意味着不在同一个操作系统上使用不同make的, 或其他gmake在不同的盒子上）。如果您偏离正常的消费级安装过程，那么没有MakeMaker.
有些人欣赏Module::Install构建文件的简洁性，但是一旦构建完成，您就不会花费大量时间来处理您的构建文件，因此它并没有什么真正的好处。当你得到的一点点好处把你锁在MakeMaker里面时，这根本不是一场胜利。
A 2014 update: Module::Build has now fallen out of favor and needs a maintainer. It never quite got to the point where people could use it to build and distribute XS modules. It was deprecated in Perl v5.19 although you can still get it from CPAN.
您可以查看Module::ScanDeps以生成要安装的依赖模块列表。或Par::Packer将整个事物打包为“应用程序”。