Free Pascal是否能从类似Apache Maven的东西中受益？

Question

Free Pascal是否能从类似Apache Maven的东西中受益？

delphibuild-automationmavenfreepascalfpmake

9

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

发布已经编译好的开源库，适用于Free Pascal（或Delphi），并存放在公共Maven仓库中
在该仓库中包含元数据，其中包含依赖信息
使用命令行上的Maven从公共仓库中下载开源库，并自动解决所有依赖项
本地仓库可以作为代理使用，以缓存经常使用的二进制文件
Maven提供的自动生成和验证校验和功能可以减少下载损坏二进制文件的风险
可以与二进制文件一起提供源代码甚至文档文件
二进制文件可以带有或不带有调试信息
连续集成服务器如Hudson，TeamCity或CruiseControl可以在提交更改到源代码控制系统后构建项目，并通知开发人员有关构建错误的信息

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

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

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

在项目文件夹中所需的唯一附加文件是包含项目信息的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

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

FPMake是一个基于Pascal的构建系统，为FPC开发和分发
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>

- mjn

作为对更新的回应：我不明白这怎么可能会起作用。要么发布已经是预编译的，要么你必须处理一个版本矩阵（每年两个项目数千个修订版本）使得预构建二进制文件成为不可能。 - Marco van de Voort

在Maven术语中，当前版本是一个“快照”版本，可以与Subversion中的主干（或头部）修订进行比较。在成功构建结束时，所有构件都将被部署到Maven存储库中，版本号为“0.9-SNAPSHOT”，直到版本0.9稳定。然后它将只被部署一次作为0.9，并开始使用0.9.1-SNAPSHOT。因此，在存储库中只会有非常少量的版本，每个稳定（已标记）发布一个版本和当前开发版本的一个快照。 - mjn

太好了，我喜欢这个想法！我可以在哪里找到更多的细节资料呢？ - Semanino

2个回答

0

听起来是个有趣的计划，但Delphi社区（我想FPC更是如此！）更注重源代码库而不是预编译库。普遍共识是，使用仅限二进制库的人是愚蠢的，原因有两个：你无法修复发现的任何错误，编译器更改将破坏兼容性。

- Mason Wheeler

请查看我的编辑 - 源代码和文档可在存储库中获得，二进制文件可以提供两个版本（带或不带调试信息）。用户可以选择下载包含或不包含源代码的构件（仅用于构建）。 - mjn

考虑到FPC编译器相对于Delphi来说速度较慢，我假设预构建库是减少FPC开发者工作周期的一种常见方法。 - mjn

请注意，FPC在Linux/Freebsd上的速度几乎是Windows的两倍。 FPC主要更适合于处理多文件I/O和二进制启动时间，这在*nix系统上大约快了一倍。二进制文件的问题更多地涉及到目标矩阵以及可用的硬件。自1995-6年以来，每天都已经构建了Windows和Linux的快照。 - Marco van de Voort

在例如Linux上，使用FPC + Lazarus构建只需要大约3分钟（Core2 2GHz+）。 - Marco van de Voort

从源代码构建需要3分钟 - 使用预编译库构建速度有多快？这个想法是尽可能地使用预编译库，以减少构建时间。另一个可行的选择是使用存档文件来减少I/O操作的数量。 - mjn

预编译的东西是版本相关的，并且会使二进制矩阵增加数量级。发布已经以预编译形式发布，不需要更新工具。此外，核心 FPC 和 Lazarus SVN 是大型的（每个都有数百万行），其余的软件包都可以在几秒钟内编译完成。 - Marco van de Voort

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Marco van de Voort · Accepted Answer

FreePascal一直在开发自己的软件包系统，类似于apt-get和freebsd ports风格的交叉平台系统（自动下载源代码/构建/安装），称为fppkg。然而，工作已经停滞不前。投入时间的人是瓶颈，而不是想要选择工具的人。

就Maven而言，我不喜欢需要安装庞大外部运行时的辅助工具。这对于一个大型主要应用程序（如Open Office）可能还可以接受，但对于一个小工具来说就不行了。

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

在引入FPC等新技术时，一些典型问题及其倾向于制作自己的工具：

需要兼职培训20多个提交者。
唯一可以假定的通用编程语言是Free Pascal。即使是Delphi的内部工作也不能保证被了解（许多提交者直接来到FPC，甚至仍然通过TP或Mac Pascal）。
- 显然，这使得使用其他语言的插件变得很麻烦。
Bash脚本是第二选择。（g）make排在第三位，但已经少了一个数量级。
所有服务器都类似于*nix（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论坛相对较为轻松，因为许多年轻人知道如何处理它。
同样适用于子版本控制（尽管更高级的规模需要一些调整，不是每个人都深入了解合并跟踪的内部情况）

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

对项目的使用进行严格的调查。以具体的方式，包括进度和时间估计。俯视一切“都有可能”的概览基本上毫无价值。
思考一下未来使用技术的变化。每一种技术最终都会被替代，即使是内部技术，在18年以上的项目中也是如此。新技术不能让其他基础设施组件的迁移变得困难或复杂。没有一种新技术可以终结所有新技术。
制定迁移计划。迁移往往被低估和低估了。
最后，还有一个重要问题，谁来进行日常维护？

请记住，在公司中，你只需要找负责应用服务器的人。但在非正式环境中，这要难得多，尤其是从长远来看，因为人们的生活、职业以及在项目上投入的时间各不相同。