perl – 我应该使用哪个框架来编写模块?

写入模块的最佳框架是什么 – ExtUtils::MakeMaker(h2xs)或 Module::Build

解决方法

注意此建议已过期。 Module::Build has been removed from the Perl core,但作为CPAN模块生活。利弊依然存在,我对MakeMaker的看法依然存在。

作为ExtUtils :: MakeMaker的前维护者,我喜欢推荐Module :: Build,因为MakeMaker是一个恐怖表演。模块::构建更好地整合在一起。但是,这些不是你的问题,我会给你“最不便宜的”答案。

执行摘要

因为模块::构建支持不是所有Perl的100%,所以从MakeMaker开始。如果要完成任何定制,请切换到Module :: Build。由于它们的基本布局,选项和界面几乎相同,这将是无痛的。看起来很诱人,避免使用Module :: Install。

幸运的是,Module :: Build可以模拟MakeMaker,它可以帮助一些,但是如果要进行任何定制,则不会有帮助。见Module::Build::Compat

对于使用Module :: Build的CPAN发行版是好的。在CPAN上有足够的模块::构建东西,现在所有人都已经处理了它的引导。

最后,新的configure_requires选项让CPAN shell知道安装Module :: Build,然后才能开始构建模块。不幸的是,只有最新的CPAN shell了解了configure_requires。

哦,无论你做什么都不要使用h2xs(除非你正在写XS代码,甚至想想)。

MakeMaker优点:

>与Perl配合使用,由Perl核心使用(因此它是积极的
维持并将保持如此永远)
>一切都知道如何做一个Makefile.PL。
>大多数模块创作文档将涵盖MakeMaker。
>使用make(知道make的人可以调试和修补构建
处理)

MakeMaker缺点:

>需要make(认为Windows)
>难以定制
>更难于定制和制作跨平台
>出现错误时难以进行调试(除非您了解make)

模块::构建优点:

>更容易定制/子类
>纯Perl
更容易调试(它是Perl)
>可以以多种方式模拟MakeMaker
> CPAN shell将为您安装Module :: Build

模块::构建缺点:

> Module :: Build维护者(实际上所有的Perl Toolchain Gang)都讨厌它
>旧版本的CPAN客户端(包括CPANPLUS)不了解Module :: Build的任何内容

模块::安装优点:

> Slick界面
>捆绑本身,你有一个已知的版本
>一切都知道如何处理一个Makefile.PL

模块::安装缺点:

>需要make>始终使用捆绑版本,易受外界破坏>界面难以定制> MakeMaker的内心呕吐,所以一个新的MakeMaker版本最终会破坏它。>不知道如何使用v2元规格生成Meta文件(越来越多的新工具出现问题)

相关文章

1. 如何去重 #!/usr/bin/perl use strict; my %hash; while(...
最近写了一个perl脚本,实现的功能是将表格中其中两列的数据...
表的数据字典格式如下:如果手动写MySQL建表语句,确认麻烦,...
巡检类工作经常会出具日报,最近在原有日报的基础上又新增了...
在实际生产环境中,常常需要从后台日志中截取报文,报文的形...
最近写的一个perl程序,通过关键词匹配统计其出现的频率,让...