请描述您的应用程序类型(它是一个Web应用程序，它在服务器上运行，还是使用PAR或PerlApp捆绑，以便可以在perlless系统上运行)。
构建系统应提供的关键事项：
>图书馆控制。
>应该可以检查一个库分发到我的dev目录中，以便在我的构建中使用它。
>应该很容易使用将使用相应目录的@INC值来执行perl。
>应该可以得到源自系统perl安装的模块的列表。
> Makefile / Build集成
>通过只发出一个make测试或类似的命令，应该很容易对整个应用程序进行全局测试。
>版本控制友好
>结构不应干扰CVS，SVN等正常使用版本
控制系统。
>跨平台
>系统应至少在Win32和Unix派生系统上运行。
>理想情况下，工具应该在perl操作的所有地方相同地工作。
>单Perl安装
>作为设置环境的一部分，不必将perl安装到特殊目录中。
>轻松启动
>启动应用程序应该是一个主要是自动化的过程。沿着Module :: Starter或h2xs行的内容应该可用于布局基本结构并创建任何标准文件。
在Perlmonks交叉。
解决方法
>控制库 – 我创建我自己的版本的CPAN只有我想要的模块。最新版本的App::Cpan有几个功能，如-j选项加载一次性配置，以帮助这一点。一旦你有了这个，你可以分发它的拇指驱动器或CD的所有模块，CPAN.pm配置，和你需要的一切。有了一个小编程，你创建一个run_me脚本，使一切发生。
> Makefile / Build整合 – 我不整合Makefile。这是通往灾难的道路。相反，我做了与顶层应用程序模块的集成测试，它自动测试所有的依赖关系。 -t切换到cpan命令对于测试当前工作目录中的模块很有用：
cpan -t。
有各种隔离测试框架，你也可以使用。你将PERL5LIB设置为空(只有核心模块在硬编码的@INC目录中)，因此cpan必须从头开始安装。
>版本控制友好 – 这并不重要什么你使用。大多数事情有某种出口，你可以得到一切没有源控制的东西。 Git是非常好的，因为它在正常情况下只有最小的污染。
>跨平台 – 我提到的一切在Windows和Unix上都很好。
>单个Perl安装 – 这部分更棘手，我认为你会错误的方式。任何时候多个事情都需要依赖于同一个perl，有人会把它弄乱的其他人。我绝对建议不要使用系统Perl的应用程序开发，所以你不要搞砸系统的操作。至少，每个应用程序都应该将所有非核心模块安装到自己的目录中，这样它们就不会与其他应用程序竞争。
>轻松启动 – 这只是一个简单的编程问题。
奖金：我不使用Module :: Starter。这是错误的方式去，因为你必须依赖于Module :: Starter认为你应该做什么。我使用Distribution::Cooker，它只需要一个Template Toolkit模板的目录，并处理它们，以给他们您的分发目录。你可以做任何你喜欢的。如何获得初始模板取决于你。