编写模块-ExtUtils :: MakeMaker(h2xs)或者Module :: Build的最佳框架是什么？

解决方案

回答

两者都有优点和缺点。这些天，我使用并推荐Module :: Build和Module :: Starter。

回答

EU :: MM似乎仍然是受到最广泛支持和最受欢迎的工具，但是Module :: Build正在赶上。另外，请查看Module :: Starter中可入门的模块。

回答

我还建议使用Module :: Build和Module :: Starter(带有TT2插件)。

回答

Module :: Build在任何方面都比较好，但是它的支持范围不如ExtUtils :: MakeMaker(更具体地说，较旧的Perl版本不支持)。这取决于需求。

回答

这里有两个问题。

首先，切勿使用h2xs。虽然我想如果我们实际上是想将头文件转换为XS代码，那么它已经过时了，但它可能很有用(我自己从来没有做过)。

2011年更新：我强烈建议我们看一下Dist :: Zilla，特别是如果我们认为自己将维护多个模块。

要创建新模块，请使用Module :: Starter。它的效果很好，并且有一些不错的插件可用于自定义输出。

其次，我们要询问应该使用哪种构建系统。这三个竞争者是ExtUtils :: MakeMaker(EUMM)，Module :: Build(MB)和Module :: Install(MI)。

EUMM是一件令人讨厌的令人讨厌的工作，但是它可以工作，而且如果我们根本不自定义构建过程，也可以正常工作。

MB是新手，它有它的缺点。最大的好处是，如果我们想大量自定义安装和构建过程，则很有可能使用MB明智地(以跨平台方式)执行此操作。使用EUMM实际上是不可能的。

最后，MI基本上是EUMM之上的声明性包装器。它还与发行版一起打包，以解决用户尝试使用旧工具链模块安装模块的问题。 " package self"技巧的缺点是，如果MI本身存在错误，则必须重新发布所有模块以进行修复。

就定制而言，有一些MI的插件，但是如果我们不打算使用它们，那么我们将回到处理Makefile和跨十几个平台构建工具的问题，因此它实际上无济于事在那个领域你太多了。

回答

我刚刚将Distribution :: Cooker上传到CPAN。这就是我用来制作新发行版的方式。这样做的好处是发行版可以随心所欲：我们只是在烹饪一些模板。我不在乎是否有人使用它。对我来说，这是简单的，技术含量低的程序，不会引起额外的问题。

我们可以从Module :: Starter之类的东西开始，制作入门模板，然后添加自己的样板和最喜欢的做事方式。我们不仅可以选择每个文件中想要的内容，还可以选择哪个文件显示在发行版中。在确定自己喜欢做的​​事情时，我们只需更新自己的模板。

至于Makemaker和Module :: Build，未来将是Module :: Build。只是我们使用Makemaker的老家伙了。 :)有几种方法可以同时使用(或者假装同时使用)。查看Module :: Build，Module :: Build :: Compat和Module :: Install文档。 Module :: Build已从Perl的标准库中剔除，并且前途未卜。它作为构建系统返回到Makemaker。

尽管这是一个解决之道，但尝试使用每种方法只是对每种方法都有一点经验。

回答

就个人而言，我建议使用Module :: Install，就像许多人一样，我知道Catalyst和Moose的人也喜欢使用它。

回答

以下是我希望回应的方向的一些澄清：

• 各种框架的优点/缺点
• 框架的兼容性/安装基础
• 内部(本地)与外部(CPAN)版本的适用性
• 不露面的"使用X"答案

Dave的答案提供了一些不错的专业知识。莱昂的答案暗示了兼容性，但并不明确。正如brian d foy所提到的，只有旧版本才使用EUMM，但是我不相信MB是用于CPAN的良好框架，因为它直到5.9才是核心。

回答

与Module :: Build兼容的唯一麻烦是，当用户尝试安装模块而不更新其CPAN客户端(CPAN.pm或者CPANPLUS.pm)时，如果他们是从CPAN安装模块，则可以轻松升级其客户端从同一面镜子。

如果我们不想在构建过程中做任何复杂的事情，请确保：使用EUMM。但是，如果我们在其他目标平台上存在构建问题，则可能会最终进入Makefile，这在每个make版本中都不同。

Module :: Build为我们提供了许多功能(如果我们对其进行扩展，可以想到的一切)，并且都是perl的，因此我们永远不会最终调试makefile。 Module :: Install为我们提供功能，但是我们必须将其捆绑在一起，然后最终所有内容都会通过" make"运行。

回答

注意此建议已过时。 Module :: Build已从Perl核心中删除，但仍作为CPAN模块存在。优点和缺点仍然存在，而我对MakeMaker的看法仍然存在。

作为ExtUtils :: MakeMaker的前维护者，我喜欢推荐Module :: Build，因为MakeMaker令人震惊。 Module :: Build更好地组合在一起。但这不是我们关心的问题，我将提出"给麻烦最少"的答案。

执行摘要：

因为在Perl的所有Perl中，Module :: Build的支持都不是100％可用，所以从MakeMaker开始。如果我们要进行任何自定义，请切换到Module :: Build。由于它们的基本布局，选项和界面几乎相同，因此将很轻松。看起来很诱人，请避免使用Module :: Install。

幸运的是，Module :: Build可以模拟MakeMaker，它可以帮助某些人，但是如果我们要进行任何自定义，则无济于事。参见Module :: Build :: Compat。

对于使用Module :: Build的CPAN版本，可以使用。现在，在CPAN上有足够的Module :: Build东西了，每个人都已经开始引导它了。

最后，新的configure_requires选项使CPAN外壳程序在开始构建模块之前就知道要安装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一无所知。

模块：：安装优点：

• 光滑的界面
• 捆绑包本身，我们有一个已知版本
• 一切都知道如何处理Makefile.PL

模块：：安装缺点：

• 需要做
• 始终使用捆绑版本，容易受到外部破坏
• 难以在其界面之外进行自定义
• 带有MakeMaker胆量的污点，因此新的MakeMaker版本最终会破坏它。
• 不知道如何使用v2 meta-spec生成META文件(使用较新工具的问题越来越多)

回答

我们可能还想看看Dist-Zilla，这是一个仅创建作者的新工具，用于创建发行版。因为它仅有助于构建发行版，所以它不随代码一起提供或者进行任何安装，因此可以执行许多强大的工作。