delphi – 可以像Apache Maven一样免费获得Pascal的好处吗?

前端之家收集整理的这篇文章主要介绍了delphi – 可以像Apache Maven一样免费获得Pascal的好处吗?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
Apache Maven是Java开源生态圈中非常流行的构建和依赖管理工具.我做了一些测试,以确定它是否可以处理已编译的 Free Pascal / Delphi单元,并且发现它易于实现.所以有可能

>在公共Maven存储库中发布为Pascal(或Delphi)预编译的开源库
>在此存储库中包含元数据,其中包含依赖项信息
>在命令行上使用Maven从公共存储库下载开源库,并自动解析所有依赖项
>作为代理工作的本地存储库可用于缓存经常使用的二进制文件
>自动校验和生成和验证(由Maven提供)将降低下载损坏的二进制文件的风险
>二进制文件可以提供源代码甚至文档文件
>可以提供带有或不带调试信息的二进制文件
>只要将更改提交到源控制系统并通知开发人员有关构建错误的信息,就可以使用Hudson,TeamCityCruiseControl等持续集成服务器来构建项目

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

对于开发人员,编辑和构建项目的工作流程将降至最低:

>从内部版本控制系统签出项目源
>编辑源文件
>运行mvn包以自动下载所有必需的第三方库(预编译单元),如果它们尚未在工作站的本地存储库中
>编译并运行

项目文件夹中唯一需要的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开发和分发
> 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>

解决方法

Freepascal一直致力于在apt-get和freebsd端口之间交叉的自己的包系统. (自动下载source / build / install),名为fppkg.
然而,工作停滞不前.投资时间的人是瓶颈,而不是人们想要选择工具.

就Maven而言,我不喜欢需要安装巨大外部运行时的辅助工具.它可能适用于大型主要应用程序(如Open Office),但不适用于util.

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

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

>需要在兼职培训20名提交者.
>您可以假设唯一的COMMON编程语言是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的配送包装一直很重要,而且还在不断增加
>所有发行版都有自己的特殊规则,包括元数据,depedancies以及必须如何发布源代码.特别是Debian / Ubuntu非常官僚和缓慢.
>大多数人不喜欢他们系统上的第三方自动安装程序(因为它绕过了他们的依赖控制)

这一切都导致了有效的实践,在Pascal中拥有最少编写脚本的工具.使用的一些工具:

> Gmake主要用于在每个目录级别参数化构建过程,后继者,fpcmake(尽管名称不是真正的衍生品)已经开始,但迁移尚未完成.
>文档构建中使用了Latex和一个到html转换的乳胶(tex4ht,但是debian使用了hevea)(非库文档)
>社区站点(使用TCL脚本的netscape社区服务器,一个繁重的复杂应用程序服务器)自启动以来一直是一个麻烦,但特别是最近,因为维护者变得不那么活跃.
> Mantis一直是个问题(特别是电子邮件模块会因为音量而崩溃或瘫痪服务器),但是在连续更新和几个lazarus级别的艰苦工作中它已经被塑造了.目前它是一个体面的主力.
> lazarus.freepascal.org PHPBB论坛OTOH相对无痛,因为很多年轻人都知道如何处理它.
>对于颠覆来说也是如此(虽然更先进的规模需要一些调整,但不是每个人都深入到合并跟踪的来龙去脉)

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

>以重要方式调查项目的使用情况.以非常具体的方式,具有时间表和时间估计.鸟瞰水平“一切皆有可能”的概述基本上是毫无价值的.
>考虑未来使用技术的变化.在18年的项目中,每项技术最终都会被替换,甚至是内部技术.新技术不得使其他基础设施组件的迁移变得困难或涉及.结束所有新技术的新技术并不存在.
>制定迁移计划.移民往往被低估和低估.
>最后,总会有100万欧元的问题,谁来做日常维护?

请记住,在公司中,您只需启动应用程序服务器负责人.但在非正式的环境中,这种方式更加困难,特别是长期,因为人们的生活,职业和花在项目上的时间各不相同.

猜你在找的Delphi相关文章