像Apache这样的东西能给Pascal带来好处吗？
阿帕奇·马文是Java开源生态圈中一个非常流行的构建和依赖管理工具。我做了一些测试，看看它是否能够处理编译过的自由帕斯卡 / Delphi单元，并发现它很容易实现。所以有可能
- 发布为公共Maven存储库中的免费Pascal (或Delphi)预编译的开源库
- 在此存储库中包含元数据，其中包含依赖项信息。
- 使用命令行上的Maven从公共存储库下载开放源码库，并自动解决所有依赖关系
- 本地存储库可用作代理，用于缓存经常使用的二进制文件。
- 自动校验和生成和验证(由Maven提供)将降低下载损坏二进制文件的风险。
- 二进制文件可以提供源代码，甚至文档文件。
- 二进制文件可以提供调试信息，也可以不提供调试信息。
- 只要向源代码管理系统提交了更改，就可以使用哈德森、TeamCity或CruiseControl等连续集成服务器来构建项目，并将生成错误通知开发人员。
这种依赖管理方式对于开源项目非常有利，因为开源项目使用了许多具有复杂依赖关系的第三方库。它将避免使用错误版本所造成的典型冲突。
对于开发人员来说，编辑和构建项目的工作流将减少到最低限度：
- 从内部版本控制系统检查项目源
- 编辑源文件
- 运行
mvn package以自动下载所有所需的第三方库(预编译单元)，如果它们尚未在工作站的本地存储库中 - 编译和运行
项目文件夹中需要的Apache的唯一附加文件是包含项目信息的POM.XML文件。
编辑:虽然Maven可以用于某些必需的任务，但是在本地免费Pascal中实现类似Maven这样的解决方案有一些优点:不需要Java，支持所有可用的开发平台，在Pascal中进行维护和插件开发。
使用类似Maven的工具无助于开放源码项目--商业项目也可以以同样的方式访问和使用公共Maven存储库中的工件。
Maven特性在http://maven.apache.org/maven-features.html中列出
更新：
一个用例可以是构建Lazarus，其中Maven将下载所有必需的库，并使用必要的构建路径参数调用编译器。较低级别上的依赖项的更改将自动传播到父生成。
可能的好处：
- 建立新工作站所需时间较少，无需手动安装第三方图书馆
- 减少由错误的库版本引起的错误，检测版本冲突(例如，如果两个库依赖于第三个库的不同版本)
- 内部创建的工件可以添加到本地maven存储库中，并在开发人员和项目之间共享，并使用元数据集中存储所有工件。
- 构建是可重复的，只需使用相同的源元数据文件和项目元数据文件(pom.xml)。
- 可以缩短开发时间，增加项目稳定性。
更新#2: FPMake
用于自由Pascal的FPMake构建系统似乎是一个很有潜力的工具，在许多细节上它与Maven非常相似：
- FPMake是一个基于pascal的构建系统，它是为FPC开发和分发的。
- FPMake通过定义一些限制来标准化建筑，比如标准目录。
- 命令
fppkg <packagename>将查找包的数据库，解压它，然后编译fpmake.pp并运行它。 - 它有标准的构建目标(清洁，构建，安装，.)
- 它可以创建一个适合导入存储库的“清单”文件(如
mvn deploy或mvn install)，清单是一个与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>回答 2
Stack Overflow用户
发布于 2009-12-12 14:43:47
Freepascal一直致力于在apt-get和freebsd端口风格的交叉中开发自己的包系统。(自动下载源代码/构建/安装)，称为fppkg。然而，工作停滞不前。人们投资时间是瓶颈，而不是那些想选择工具的人。
就Maven而言，我不喜欢需要安装大量外部运行时的辅助工具。对于一个大型应用程序(比如Office)来说，这可能是可以接受的，但对于一个实用程序来说则不然。
我也喜欢一个工具，是设计的FPC现实和工作流程。文档工具、构建工具、下载系统、测试套件系统都已经存在，它只需要一个专门投入大量时间来实现它的人。
在像FPC这样的项目中引入新技术时的一些典型问题，以及为什么它倾向于制造自己的工具：
- 需要对20+提交者进行兼职培训。
- 您可以假设的唯一通用编程语言是Free。即使德尔菲内部的工作方式也不能被认为是理所当然的(许多提交者直接进入FPC，甚至仍然通过TP或Mac Pascal) 。
- 显然，这会使用不同语言的插件产生一些烦人的效果。
- Bash脚本是第二个。(G)第三次，但已经减少了一次。
- 所有服务器都类似于*nix (FreeBSD、OS、Linux)，但并不是所有服务器都运行Apache。(例如，我的FreeBSD镜像运行XSHTTPD)
- 一些最有知识的人必须是长期敬业的维护者。修复问题，更新/执行迁移等等。由于明显的原因，可能不止一个。
- 一个主要的问题是Linux发行版(和较小程度上的FreeBSD )，大多数*nix包的维护人员不能超过“./配置；make；make”，并且必须使用一个几乎可构建的存储库和辅助文件来填充。
- FPC/Lazarus的分销包装一直很重要，而且还在不断增加。
- 所有发行版都有自己的特殊规则，涉及元数据、退学究以及必须如何发布源。尤其是Debian/Ubuntu非常官僚和缓慢。
- 大多数人不喜欢第三方自动安装程序在他们的系统之上(因为这绕过了他们的依赖控制)
这一切都导致了在Pascal中使用最少脚本工作的工具最有效的实践。使用的一些工具：
- Gmake主要用于在每个目录级别上参数化构建过程，后续的fpcmake (尽管名称并不是make派生程序)已经开始，但迁移尚未完成。
- 在文档构建(非库文档)中使用了乳胶和乳胶到html的转换(tex4ht，但debian使用了hevea)。
- 社区站点(netscape社区服务器，它使用TCL脚本，这是一个沉重的复杂应用服务器)从一开始就一直是一个麻烦，但最近特别是因为维护人员变得不那么活跃。
- 螳螂一直是一个问题(特别是电子邮件模块会崩溃或瘫痪服务器，因为数量)，但它已经形成了在连续更新和努力工作的几个lazarus的发展。目前，它是一匹体面的工作马。
- lazarus.freepascal.org PHPBB论坛OTOH相对来说是无痛的，因为很多年轻人知道如何处理它。
- 颠覆也是如此(虽然更高级的规模需要一些调整，但并不是每个人都深入到合并跟踪的内部和外部)。
如果有人真的认真对待Maven，我通常会问他：
- 对项目的使用情况进行批评调查。以一种非常具体的方式，有时间表和时间估计。鸟眼级的“一切皆有可能”的概观本质上毫无价值。
- 对现有技术的未来变化进行了一些思考。在18个year+项目中，每项技术最终都被取代，甚至内部技术也是如此。一项新技术绝不能使其他基础设施组件的迁移变得困难或牵涉其中。结束所有新技术的新技术并不存在。
- 制定移民计划。移徙往往被低估和低估。
- 最后，总有一个1000000欧元的问题，谁来做日常维护？
记住，在一家公司里，你只是踢了负责应用服务器的人。但在非正式环境中，这要困难得多，特别是长期而言，因为人们的生活、职业和花费在项目上的时间各不相同。
Stack Overflow用户
发布于 2009-12-12 13:52:22
听起来是个有趣的计划，但是Delphi社区(而且FPC更是如此，我可以想象！)将库作为源的值远远大于预编译的库。普遍的共识是，任何使用只使用二进制库的人都是傻瓜，原因有两个:您无法修复在其中发现的任何bug，而编译器的更改将破坏兼容性。
https://stackoverflow.com/questions/1893469
复制相似问题
腾讯云开发者
