Never-build package 'XXXX' requires always-build package 'EhLib70'

本文介绍了解决Delphi中因程序包依赖导致的编译错误的具体步骤。当一个程序包A依赖于另一个程序包B时,若两者的编译控制设置不匹配,则会引发编译错误。文章详细解释了不同编译控制选项的作用,并提供了调整设置以解决问题的方法。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >


控件包使用了DbGridEh。Requies也加入了ehlib70.dcp就是编译时不通过,提示:   
  Never-build   package   'XXXX'   requires   always-build   package   'EhLib70'  

最后解决了,需要在Project->Options里的Description里将BuildControl 选项设置成Rebuild as needed

这是程序包的互相依赖是的问题,假如程序包A依赖程序包B,如果B改变了A如何办?这就看你在编译程序包时候的Build   Control如何选择,如果选择Rebuild   as   needed那么这个包所依赖的任何单元只要一个改变它就会重新编译,如果选择Explicit   rebuild那么只有你选择重编译时候才会重建,一般情况下程序包比较稳定所以一般都选择这个选项。你这种情况就是B选择了Rebuild   as   need,A选择了Explicit   rebuild,这样B依赖的单元一改变B就被重建,但A间接依赖B所依赖的单元不被重建不符合逻辑,所以编译器禁止这样做,你只要把所有的程序包都设置为Explicit   rebuild就可以了


Delphi 出现Never-build package 'a' requires always-build package 'b'错误的解决方法:

1、原理:

两个BPL包,如果A包requires B包,那么A包与B包的Build Control 必须一致,或者A包为Rebuild as needed(Always-build),B包为Explicit rebuild(Never-build)。原因是:如果A包为Explicit rebuild,B包为Rebuild as needed,就是说A包是很稳定的,不需要编译,但A包requires的B包却是常变的,要经常编译的。那么,当B包改变的时候,理应要更新,而A包是Explicit rebuild,所以A包还是不编译,那么造成A包的内容是旧的,最终造成包的更新失败,如果,当应用程序调用A包的时候,就出错了。所以在A包requires B包的情况下,不允许出现“A包为Explicit rebuild,B包为Rebuild as needed”这种组合。Delphi就提示Never-build package 'a' requires always-build package 'b'这个Error了。

2、解决方法:

要把两个包的 Project-> Option 里的 Description 面板里的 Build Control设在一致,一般情况下是 Rebuild as needed



### 使用 `rpm-build` 和 `fpm` 进行打 #### 背景介绍 `fpm` 是一种用于轻松创建平台原生的工具,支持多种格式(如 `.deb`, `.rpm`),而无需深入了解底层命令或复杂配置文件[^1]。通过 `fpm` 的帮助,可以简化基于 RPM 或 DEB 打的过程。然而,在某些情况下,可能需要更细粒度地控制 RPM 的内容和结构,这时就需要结合 `rpm-build` 工具。 #### 安装依赖项 为了使用 `fpm` 创建 RPM ,首先需要安装必要的开发环境和支持库。以下是针对不同操作系统的安装指南: 对于 CentOS/RHEL 系统: ```bash sudo yum install -y rpm-build redhat-rpm-config ``` 如果是在较旧版本的操作系统上运行,则需先启用 EPEL 存储库[^4]: ```bash sudo rpm -Uvh http://dl.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm sudo yum install -y rpm-build redhat-rpm-config ``` 对于 Ubuntu/Debian 系统: ```bash sudo apt-get update && sudo apt-get install -y rpm ruby-dev make gcc gem install fpm --no-document ``` #### 配置工作目录 在开始构建之前,建议设置清晰的工作目录结构以便管理源码和其他资源文件。通常的做法是将项目分为以下几个部分: - **SOURCES**: 放置原始代码或其他输入材料的地方。 - **SPEC**: 含描述软件元数据以及如何编译它的 spec 文件的位置。 例如: ```bash mkdir -p ~/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS} echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros ``` #### 利用 `fpm` 构建 RPM 一旦准备工作完成,就可以利用 `fpm` 来生成目标 RPM 文件了。下面是一个简单的例子展示如何执行此操作: 假设有一个名为 `myapp` 的应用程序位于 `/path/to/myapp` 中,并希望将其转换成一个 RPM 。 ```bash cd /path/to/myapp tar czvf myapp-source.tar.gz . mv myapp-source.tar.gz ~/rpmbuild/SOURCES/ cat <<EOF >~/rpmbuild/SPECS/myapp.spec Name: myapp Version: 1.0 Release: 1%{?dist} Summary: My custom application. License: GPLv3+ URL: https://example.com/myapp Source0: %{name}-%{version}.tar.gz BuildRequires: gcc Requires: bash %description This is a description of myapp. %prep %setup -q %build make %install rm -rf \$RPM_BUILD_ROOT mkdir -p \$RPM_BUILD_ROOT/usr/bin cp bin/* \$RPM_BUILD_ROOT/usr/bin/ %files /usr/bin/* %changelog * Mon Jan 01 2023 John Doe <john.doe@example.com> - 1.0-1 - Initial package. EOF fpm \ -s dir \ -t rpm \ -n myapp \ -v 1.0 \ --iteration 1.el7 \ -C ~/rpmbuild/BUILD/root-myapp \ usr/bin/ ``` 这段脚本会自动读取指定路径下的二进制可执行程序并封装到最终产物之中。 #### 结合 `rpm-build` 提升定制能力 虽然上面的方法已经能够满足大部分需求,但如果想进一步调整行为或者加入额外逻辑的话,则可以通过编写完整的 SPEC 文件来实现更加复杂的场景处理。此时可以直接调用 rpmbuild 命令代替 fpm ,从而获得更大的灵活性。 例如修改后的流程如下所示: ```bash rpmbuild -ba ~/rpmbuild/SPECS/myapp.spec ``` 这样不仅可以定义更为详尽的构建阶段指令集 (%pre/%post),还可以引入外部宏定义或者其他辅助脚本来增强功能特性[^3]。 --- ###
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值