Free Pascal 能否受益于 Apache Maven 之类的东西？

Question

Apache Maven是Java开源生态圈中非常流行的构建和依赖管理工具。我做了一些测试，看看它是否可以处理编译的 Free Pascal / Delphi 单元，并发现它很容易实现。因此，可以

• 在公共 Maven 存储库中发布为 Free Pascal（或 Delphi）预编译的开源库，
• 包括此存储库中的元数据，其中包含依赖项信息，
• 在命令行上使用 Maven 从公共存储库下载开源库，并且自动解析所有依赖项
• 本地存储库作为代理，可用于缓存常用的二进制文件
• 自动校验和生成和验证（由 Maven 提供）将降低下载损坏的二进制文件源代码的风险
• ，甚至可以随二进制文件一起提供文档
• 文件可以提供或不提供调试信息
• 持续集成服务器，例如 Hudson、TeamCity 或 CruiseControl每当更改已提交到源代码控制系统时就构建项目，并通知开发人员有关构建错误的

依赖关系管理方式对于使用许多具有复杂依赖关系的第三方库的开源项目非常有益。它将避免因使用错误版本而引起的典型冲突。

对于开发人员来说，编辑和构建项目的工作流程将减少到最低限度：

• 从内部版本控制系统检出项目源
• 代码编辑源文件
• 运行mvn package以自动下载所有必需的第三方方库（预编译单元）（如果尚未在工作站的本地存储库中）
• 编译并运行

项目文件夹中所需的 Apache Maven 的唯一附加文件是包含项目信息的 POM.XML 文件。

编辑：虽然 Maven 可用于某些必需的任务，但在本机 Free Pascal 中实现像 Maven 这样的解决方案将具有一些优点：不需要 Java SDK、支持 Free Pascal 可用的所有开发平台、在 Pascal 中进行维护和插件开发。

使用类似 Maven 的工具仅对开源项目没有帮助 - 商业项目也可以以相同的方式访问和使用公共 Maven 存储库中的工件。

Maven 功能列于 http://maven.apache.org/maven-features.html

---

更新：

一个用例可能是 Lazarus 的构建，其中 Maven 将下载所有必需的库并使用必要的构建路径参数调用编译器。较低级别的依赖项的更改将自动传播到父构建。

可能的好处：

• 减少建立新工作所需的时间 站，无需手动安装 需要第三方库，
• 减少因错误库引起的错误 版本，版本检测 冲突（例如，如果两个 库依赖于不同的 第三个库的版本）
• 内部创建的工件 可以添加到本地maven 存储库并在之间共享 开发商和项目，中央 所有工件的存储 元数据
• 构建是可重现的，只需 使用相同的源和项目 元数据文件（pom.xml）
• 可以减少开发时间 提高项目稳定性

更新 #2：FPMake

Free Pascal 的 FPMake 构建系统似乎作为一个具有很大潜力的工具，在许多细节上它与 Maven 非常相似：

• FPMake 是一个基于 pascal 的构建系统，为 FPC 开发并随 FPC 一起分发。
• FPMake 通过定义一些限制（如标准目录）来标准化构建，
• 命令 fppkg < packagename> 将在数据库中查找包，将其解压缩，然后编译 fpmake.pp 并运行它，
• 它具有标准构建目标（clean、build、install，...），
• 它可以创建一个“清单”适合导入到存储库的文件（例如 mvn deploy 或 mvn install），清单是一个 XML 文件，看起来与 Maven 中的 pom.xml 非常相似：

FPMake清单文件：

      <packages>
        <package name="my-package">
          <version major="0" minor="7" micro="6" build="1"/>
          <filename>my-package-0.7.6-1.zip</filename>
          <author>my name</author>
          <license>GPL</license>
          <homepageurl>http://www.freepascal.org/</homepageurl>
          <email>[email protected]</email>
          <description>this is the package description</description>
          <dependencies>
            <dependency>
              <package packagename="rtl"/>
            </dependency>
          </dependencies>
        </package>    
      </packages>

Answer 1

Freepascal 一直致力于以 apt-get 和 freebsd ports 风格交叉的方式开发自己的软件包系统。 （自动下载源/构建/安装），称为 fppkg。
然而工作却陷入停滞。瓶颈在于投入时间的人，而不是想要选择工具的人。

就 Maven 而言，我不喜欢需要安装大量外部运行时的辅助工具。对于大型应用程序（例如 Open Office）来说这可能没问题，但对于实用程序则不然。

我还更喜欢专为 FPC 实际情况和工作流程设计的工具。
文档工具、构建工具、下载系统、测试套件系统都已经存在，只需要一个人投入大量时间即可实现。

在 FPC 等项目中引入新技术时的一些典型问题，以及为什么它倾向于制作自己的工具：

• 需要兼职培训 20 多名提交者。
• 您可以假设的唯一通用编程语言是 Free Pascal。即使是 Delphi 的内部工作原理也不能被视为理所当然地为人所知（许多提交者直接来到 FPC，甚至仍然通过 TP 或 Mac Pascal）
  • 显然，这会让使用不同语言的插件变得烦人。

  显然

• Bash 脚本紧随其后。 (g) 达到第三，但数量级已经小了。
• 所有服务器都是 *nix-like（FreeBSD、OS X、Linux），但并非所有服务器都运行 Apache。 （例如我的 FreeBSD 镜像运行 XSHTTPD）
• 最有知识的人必须是长期的专门维护者。修复问题、更新/迁移等。出于显而易见的原因，最好不止一个。
• 主要的痛苦是 Linux 发行版（程度较轻的 FreeBSD），大多数 *nix 软件包的维护者只能执行“./configure;make;make install”，并且必须用接近可构建的存储库和辅助文件来补充。
  • FPC/Lazarus 的分销包装一直很重要，而且还在不断增加
  • 所有发行版对于元数据、依赖性以及如何发布源都有自己的特殊规则。特别是 Debian/Ubuntu 非常官僚且缓慢。
  • 大多数人不喜欢在其系统之上安装第三方自动安装程序（因为这会绕过他们的依赖性控制）

这一切都导致了有效的实践，即在 Pascal 中拥有工具并使用最少的脚本工作效果最好。使用的一些工具：

• Gmake 主要用于在每个目录级别上参数化构建过程，后继者 fpcmake（尽管名称并非真正的 make 衍生品）已经开始，但迁移尚未完成。
• Latex 和 Latex 到 html 的转换（tex4ht，但 debian 使用 hevea）用于文档构建（非库文档）
• 社区站点（使用 TCL 脚本的 Netscape 社区服务器，一个重型复杂的应用程序服务器）一直是一个麻烦自从它开始以来，特别是最近，因为维护者变得不那么活跃了。
• Mantis 一直是一个问题（特别是电子邮件模块会因容量而导致服务器崩溃或瘫痪），但在连续的更新和几个 Lazarus 开发人员的努力工作中，它已经成型。目前它是一个不错的主力。
• lazarus.freepascal.org PHPBB 论坛 OTOH 相对来说比较轻松，因为很多年轻人都知道如何处理它。
• 颠覆也是如此（尽管更高级的规模需要一些调整，并不是每个人都深入了解合并跟踪的来龙去脉）

如果有人真的认真对待 Maven，我通常会问他：

• 批判调查该项目的用途。以非常具体的方式，包括时间表和时间估计。鸟瞰“一切皆有可能”的概述本质上是毫无价值的。
• 对所用技术的未来变化进行一些思考。在 18 年以上的项目中，每一项技术最终都会被取代，即使是内部技术。新技术不得使其他基础设施组件的迁移变得困难或复杂。终结所有新技术的新技术并不存在。
• 制定迁移计划。移民常常被低估和低估。
• 最后，总有一个100万欧元的问题，谁来做日常维护？

请记住，在公司中，您只需踢掉负责应用程序服务器的人员即可。但在非正式环境中，这要困难得多，尤其是长期而言，因为人们的生活、职业和花在项目上的时间各不相同。

Answer 2

听起来是一个有趣的计划，但 Delphi 社区（我想 FPC 更是如此！）将库作为源代码的价值远远超过预编译库。普遍的共识是，任何使用纯二进制库的人都是傻瓜，原因有两个：你无法修复在其中发现的任何错误，并且编译器的更改将破坏兼容性。