21

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

4

11 回答 11

49

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

作为 ExtUtils::MakeMaker 的前维护者，我喜欢推荐 Module::Build，因为 MakeMaker 是一个恐怖节目。Module::Build 放在一起要好得多。但这些不是你关心的问题，我会提出我的“对你来说最不麻烦”的答案。

执行摘要：

因为 Module::Build 支持并不是 100% 通过 Perl 实现的，所以从 MakeMaker 开始。如果您想进行任何自定义，请切换到 Module::Build。由于它们的基本布局、选项和界面几乎相同，这将是无痛的。尽管看起来很诱人，但请避免使用 Module::Install。

幸运的是，Module::Build 可以模拟 MakeMaker，这对某些人有帮助，但如果您要进行任何自定义，则无济于事。请参阅模块::Build::Compat。

对于使用 Module::Build 的 CPAN 版本很好。现在已经在 CPAN 上构建了足够多的 Module::Build 东西，每个人都已经开始着手处理它了。

最后，新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 工具链帮）讨厌它
  • 旧版本的 CPAN 客户端（包括 CPANPLUS）对 Module::Build 一无所知。

模块::安装优点：

  • 流畅的界面
  • 捆绑本身，你有一个已知的版本
  • 一切都知道如何处理 Makefile.PL

模块::安装缺点：

  • 需要制作
  • 一直使用捆绑版本，容易受到外部破坏
  • 难以在其界面之外进行自定义
  • 与 MakeMaker 的胆量混为一谈，因此新的 MakeMaker 版本最终将打破它。
  • 不知道如何使用 v2 元规范生成 META 文件（新工具越来越有问题）
于 2008-10-18T07:35:47.763 回答
35

这里有两个问题。

首先，永远不要使用 h2xs。这是旧的过时的肮脏，虽然我想如果你真的想把头文件变成 XS 代码，它可能很有用（我自己从来没有做过）。

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

要创建新模块，请使用 Module::Starter。它工作得很好，并且有一些很好的插件来自定义输出。

其次，你在问你应该使用什么构建系统。三个竞争者是 ExtUtils::MakeMaker (EUMM)、Module::Build (MB) 和 Module::Install (MI)。

EUMM 是一个可怕的讨厌的工作，但它确实有效，而且如果您根本不自定义构建过程，它就可以正常工作。

MB是新来的，它有它的批评者。最大的优点是，如果您想大量自定义安装和构建过程，使用 MB 完全有可能（并且以跨平台方式）完成此操作。使用 EUMM 真的是不可能的。

最后，MI 基本上是 EUMM 之上的声明性包装器。它还将自己与您的发行版打包在一起，试图解决用户尝试使用旧工具链模块安装模块的问题。“包自我”技巧的缺点是，如果 MI 本身存在错误，您必须重新发布所有模块才能修复它。

就定制而言，有一些 MI 插件，但如果你想超越它们，你将回到处理 Makefile 和跨十几个平台构建工具的问题，所以它真的无济于事你在那个领域太多了。

于 2008-09-16T16:25:07.080 回答
20

我刚刚将Distribution::Cooker上传到 CPAN。这是我用来制作新发行版的东西。它的好处是你的发行版可以是你喜欢的任何东西：你只是在做一些模板。我不在乎是否有人使用它。对我来说，它很简单，技术含量低，不会造成额外的问题。

您可以从Module::Starter之类的东西开始制作您的入门模板，然后添加您自己的样板和最喜欢的做事方式。您不仅可以选择每个文件中的任何内容，还可以选择发行版中显示的文件。当您弄清楚自己喜欢如何做事时，您只需更新自己的模板。

至于 Makemaker 和 Module::Build，未来是 Module::Build。现在只有我们这些老家伙在使用 Makemaker。:) 有办法同时使用两者（或假装同时使用两者）。查看 Module::Build、M​​odule::Build::Compat 和 Module::Install 文档。Module::Build 被踢出 Perl 的标准库，它的未来是不确定的。它回到了 Makemaker 作为构建系统。

虽然这是一个逃避的答案，但尝试使用每个只是为了获得一些经验。

于 2008-09-16T17:08:49.237 回答
14

您可能还想查看Dist-Zilla，它是一个新的作者专用工具，用于创建发行版。因为它只是帮助构建发行版，它不附带您的代码或进行任何安装，它可以做很多强大的东西。

于 2008-10-18T07:41:11.467 回答
7

关于 Module::Build 兼容性的唯一问题是当用户尝试安装模块而不更新他们的 CPAN 客户端（CPAN.pm 或 CPANPLUS.pm） 如果他们从 CPAN 安装您的模块，他们可以轻松升级他们的客户端来自同一个镜子。

如果您不想在构建过程中做任何复杂的事情，请确保：使用 EUMM。但是，如果您在不同的目标平台上遇到构建问题，您可能最终会出现在 Makefile 中，这在每个 make 变体中都不同。

Module::Build 为您提供了许多功能（如果您扩展它，您可以想到任何东西）并且都是 perl，因此您永远不会最终调试 makefile。Module::Install 为您提供功能，但您必须捆绑它，最后一切都通过“make”运行。

于 2008-09-17T05:12:16.847 回答
2

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

于 2008-09-16T15:58:29.203 回答
2

我还推荐 Module::Build 和 Module::Starter （使用TT2 插件）。

于 2008-09-16T16:13:02.973 回答
2

Module::Build 无论如何都更好，但它的支持不如 ExtUtils::MakeMaker 广泛（更具体地说，旧版本的 Perl 不支持开箱即用）。这取决于您的需求。

于 2008-09-16T16:17:54.647 回答
2

就个人而言，我推荐 Module::Install，我认识的很多人也这样做 - Catalyst 和 Moose 之类的人也使用它。

于 2008-09-16T17:32:14.250 回答
2

以下是我希望回应采取的方向的一点说明：

  • 各种框架的优缺点
  • 框架的兼容性/安装基础
  • 适用于内部（本地）与外部（CPAN）版本
  • 不是裸露的“使用X”答案

戴夫的回答有一些很好的赞成/反对信息。Leon 的回答暗示了兼容性，但并不明确。正如brian d foy 所提到的，只有旧帽子使用 EUMM，但我不相信 MB 是用于 CPAN 的良好框架，因为它直到 5.9 才成为核心的一部分。

于 2008-09-16T18:13:29.720 回答
0

EU::MM 似乎仍然是最广泛支持和最受欢迎的一种，但 Module::Build 正在迎头赶上。此外，请查看Module::Starter以获取有助于您入门的模块。

于 2008-09-16T16:00:01.163 回答