在我的 Delphi 中,每当我重建我的应用程序时,所有第 3 方组件的 DCU 文件都会在可执行文件所在的应用程序目录中生成。
我该如何改变这种行为?
这样第三方组件的 DCU 文件就不会在我的应用程序目录中生成。
2 回答
编译器生成的 .dcu 文件都是在同一个目录中创建的。因此,无法将生成的 .dcu 文件文件放入不同的目录,并将第三方库中的文件与源文件中的文件分开。
但是,将 .dcu 文件放在与源文件相同的目录中通常不是一个好主意。这只会让事情变得混乱。最佳做法是将 .dcu 文件放入项目的子目录中。编译器选项允许您执行此操作。打开编译器选项对话框并将目标下拉菜单更改为所有配置 - 所有平台。这是其他配置继承自的基本配置。对话框如下所示:
您需要更改的设置是Unit output directory。上图显示了 XE2 上新项目的默认设置。该值.\$(Platform)\$(Config)
由编译器扩展。因此,如果您正在构建针对 Win32 平台的调试配置,您的 .dcu 文件将输出到.\Win32\Debug
.
此处记录了编译器选项:http: //docwiki.embarcadero.com/RADStudio/en/Delphi_Compiler
单元输出目录的描述为:
指定一个单独的目录来包含
.dcu
.
另一个密切相关的选项是输出目录。这是放置已编译的可执行文件的位置。如果您面向多个平台,那么您确实需要将此可执行文件放在主项目目录以外的其他位置。否则自动化构建变得困难并且容易出错。当您实际上想要一个 64 位可执行文件时,很容易找到一个过时的 32 位可执行文件。
所以我给你的建议是使用默认值,.\$(Platform)\$(Config)
因为它是一个很好的默认值。
我通常在我的源存储库中创建一个 COMP\ 文件夹,我将在此处显示为文件夹树:
root
|
comp\
| |
| |-- TMS\ - TMS component set
| |
| |-- JEDI\ - Jedi VCL and JCL
| |
| |-- Something\ - Your other favorite component
|
app\ - My application source code.
在 comp\ 文件夹下,我创建了以下其他 DCU 文件夹:
comp\
|
LIB\
|
DXE4\
我所有的组件包(.dpk + .dproj)都被修改为构建并输出到comp\LIB\
xxx文件夹,其中xxx是一个短代码,指的是特定的 delphi 版本。
然后从我的 delphiroot\App\MyApp1
文件夹中,我有一个 APP\DCU\DXE4 文件夹,这是我的主应用程序项目的 DCU 文件所在的位置App.dproj
。Project Search Path
for拉App.Dproj
入已编译的 DCU、DFM 和 RES 文件,这些文件位于 comp\LIB\DXE4 中。这意味着 App\ 项目不会从其源代码文件重建我的组件。这加快了编译速度。
正如大卫指出的那样,每个项目只有一个OUTPUT
指定的 DCU 文件夹。因此,在我的应用程序 (.dpr+.dproj) 编译阶段,作为我的组件 .dpk 包编译的 DCU OUTPUT 文件夹的文件夹成为库 INPUT 文件夹。
因为我需要在 COMP\LIB\DXE4 文件夹中同时提供 .dfm、.res 和 .dcu 文件,所以我有一个批处理文件 (buildcomp.cmd),它执行所有构建,以及制作 LIB\DXE4 所需的副本文件夹包含它必须包含的所有内容。我不会将 LIB... 文件夹的内容检查到我的版本控制系统中。它们是我的组件构建阶段的二进制和输出产品。将组件构建阶段和应用程序构建完全分开对于更大的应用程序和更大的组件集来说是一种更具可扩展性的方法。
我选择将 BPL 和 DCP 文件保留在它们的默认位置(在 下%(BDSCOMMONDIR)\BPL
),但有些人选择将他们的 BPL 和 DCP 文件重定向到它们的COMP\LIB\DXE4
等效文件夹中。Delphi 开发人员之间没有统一的标准行为,每个开发人员或公司似乎都在做适合他们的事情。沼泽标准 Delphi 实践是完全忽略这些实践并尽可能地杂乱无章,所以你甚至开始问这样一个问题的事实说明了值得称赞的趋势,你必须注意到你可能希望有一些混乱强加某种结构,如果它有利于您或您的公司。