9

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 是为 FPC 开发和分发的基于 Pascal 的构建系统
  • FPMake 通过定义一些限制（如标准目录）来标准化构建
  • 该命令fppkg <packagename>将在数据库中查找包，将其解压缩，然后编译 fpmake.pp 并运行它
  • 它有标准的构建目标（清理、构建、安装……）
  • 它可以创建一个适合导入存储库的“清单”文件（如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>myname@freepascal.org</email>
          <description>this is the package description</description>
          <dependencies>
            <dependency>
              <package packagename="rtl"/>
            </dependency>
          </dependencies>
        </package>    
      </packages>
4

2 回答 2

1

Freepascal 一直致力于开发自己的包系统，它介于 apt-get 和 freebsd 端口风格之间。（自动下载源代码/构建/安装），称为 fppkg。然而工作已经停滞。投资时间的人是瓶颈，而不是想选择工具的人。

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

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

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

  • 需要兼职培训 20 多个提交者。
  • 您可以假设的唯一通用编程语言是 Free Pascal。甚至 Delphi 的内部运作也不能被认为是理所当然的（许多提交者直接来到 FPC，甚至仍然通过 TP 或 Mac Pascal）
    • 显然，这使得使用不同语言的插件的东西很烦人。
  • Bash 脚本紧随其后。（g）排在第三位，但已经小了一个数量级。
  • 所有服务器都类似于 *nix（FreeBSD、OS X、Linux），但并非所有服务器都运行 Apache。（例如我的 FreeBSD 镜像运行 XSHTTPD）
  • 最有见识的人必须长期致力于维护。修复问题、更新/迁移等。出于显而易见的原因，最好不止一个。
  • 一个主要的痛点是 Linux 发行版（以及较小程度的 FreeBSD），大多数 *nix 软件包的维护者只能提供“./configure;make;make install”，并且必须提供一个几乎可构建的存储库和辅助文件.
    • FPC/Lazarus的分销内包装一直很重要，而且还在增加
    • 所有发行版都有自己的关于元数据、依赖关系以及必须如何发布源的特殊规则。特别是 Debian/Ubuntu 非常官僚且缓慢。
    • 大多数人不喜欢在他们的系统上安装第三方自动安装程序（因为它绕过了他们的依赖控制）

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

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

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

  • 批判性地调查项目的用途。以一种非常具体的方式，包括时间表和时间估计。鸟瞰“一切皆有可能”的概述基本上毫无价值。
  • 考虑一下使用技术的未来变化。在 18 年以上的项目中，每项技术最终都会被替换，甚至是内部技术。新技术不得使其他基础设施组件的迁移变得困难或涉及。终结所有新技术的新技术并不存在。
  • 制定迁移计划。移民往往被低估和低估。
  • 而到头来，总是有100万欧的问题，谁来做日常维护？

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

于 2009-12-12T14:43:47.087 回答
0

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

于 2009-12-12T13:52:22.390 回答