Delphi 组织搜索路径

Delphi 组织搜索路径,delphi,delphi-2009,Delphi,Delphi 2009,我们通过“工具|选项|环境变量”创建如下变量: $(Sources) = D:\Sources\Delphi $(OurLib) = $(Sources)\OurLib\Src $(OurApp1) = $(Sources)\Applications\App1\3.x $(ThirdParty) = $(Sources)\ThirdPartyComponents 我们在项目搜索路径中使用以下变量: ($OurApp1)\Src\Core;($OurApp1)\Src\GUI;($OurApp1

我们通过“工具|选项|环境变量”创建如下变量:

$(Sources) = D:\Sources\Delphi
$(OurLib) = $(Sources)\OurLib\Src
$(OurApp1) = $(Sources)\Applications\App1\3.x
$(ThirdParty) = $(Sources)\ThirdPartyComponents
我们在项目搜索路径中使用以下变量:

($OurApp1)\Src\Core;($OurApp1)\Src\GUI;($OurApp1)\Src\Plugins;$(ThirdParty)\JVCL
但自Delphi 2009年以来,这一点被打破(同时被修复),因为这些变量不再被完全评估(参见)。因此,编译器找不到目录中的文件。解决方法:仅在环境变量中使用完整的目录

我们使用这种方法是因为在所有开发人员机器和构建服务器上都可以找到文件,我们只需将$(Sources)指向正确的位置

我们的全局库路径中没有任何内容(Delphi默认值除外),因为它不在版本控制中,也不会反映在其他开发人员或构建机器上

一个问题是:如果$(OurLib)中的一个单元决定在新路径中包含另一个新单元,那么所有项目都会中断,因为它们找不到这个新单元。然后我们必须遍历所有项目并添加搜索路径。(顺便说一句:我真的很讨厌搜索路径编辑器…一个简单的备忘录字段是否比这个替换/添加/删除逻辑好得多?)

我们要做的另一件事是不要在我们的项目中增加很多单元。尤其是从$(OurLib)开始的所有内容,但我们通常有插件之类的单元,它们只通过包含它们来添加功能。对于我们产品的不同版本,我们希望包括不同的单元。由于Delphi总是在.dpr的uses子句中弄乱$IFDEFs,我们通过包含名为“IncludePlugins”的单元来帮助我们,然后根据IFDEFs包含这些单元。 但在项目中不包括单元会让导航变得很痛苦。这些单位不会出现在项目中,它们不会通过Ctrl+12(显示单位)找到,它们不会显示在代码完成等中


有谁有更好的方法来处理这些问题吗?

我们使用标准驱动器映射

我们当前的项目总是在W:无论它是网络驱动器还是替代品

这很有效


当您需要处理另一个项目时,交换W:即可继续。

我们仅使用相对路径,当项目源代码位于src子目录时,任何库始终位于libs子目录下。因此,我们的搜索路径始终如下所示:

..\libs\library1\libs\library2\common

等等

所有库都作为svn:external添加到每个项目中,因此签出项目也将自动签出库,并且搜索路径将始终指向该项目库的正确版本

虽然不完美,但它在大多数情况下都有效


我必须同意搜索路径编辑器,相对路径更糟糕,因为您不能使用“…”按钮,否则Delphi将插入一个绝对路径。

您可以将搜索路径复制到编辑器,修改它,然后再复制回来。

您的搜索路径太大了。它应该只包含您希望Delphi在项目中重新编译的内容。你不是真的想每天重新编译绝地VCL吧

我创建了一个目录,所有编译的单元都在其中。比如说,C:\dcu。将其指定为所有包中的“单元输出目录”。因此,我的“搜索路径”总是这样:

$(Delphi)\Lib;C:\dcu

编译器会找到它所需要的一切,但它永远也找不到任何源代码。它所看到的唯一源代码是直接属于我正在编译的任何项目的文件。项目自己的源目录不需要位于搜索路径上,因为所有这些文件都已经是项目的直接成员。编译器确切地知道它们在哪里

对我来说,项目的所有源文件都放在一个目录中。如果您希望为不同的部分(如Core和GUI)提供单独的目录,那么我会将它们放在单独的包中,这样我就可以处理它们并分别编译它们。即使最终的程序不使用生成的BPL,包仍然是分割项目和定义依赖关系的好方法

当为一个项目编译单位时,不会自动为所有其他项目编译单位,您将被迫更改活动项目。这需要你花一点时间,但它也会提醒你,你也在“换帽子”

尽管您只生产一个产品,但这并不意味着您应该在Delphi中只有一个项目。对于产品中的每个可执行模块(EXE、DLL、BPL),应该至少有一个项目。使用项目组在单个IDE会话中管理多个项目。任何单位都不应是一个以上项目的成员



我不理解你关于插件和项目不同版本的部分。当你说“插件”时,我假设你说的是独立的可执行模块,比如DLL或包,客户可以选择是否包含这些模块。难道你不能把不同版本的特性转换成插件模块,而这些插件模块根本不包含在较低版本中吗?这样,您就不必担心项目的条件编译;只是有几个不同的安装程序包可以获取不同的插件集。

我总是觉得奇怪,这一点从来没有得到充分的解决。我最近向David I建议,Delphi应该允许用户设置某种首选开发结构,并且可以让第三方库发布商知道这一点,以便他们能够自动调整安装程序,以便在首选开发框架中正确安装。如果首选开发结构存储在XML文件或类似文件中,则可以在开发团队中将其从一台计算机复制到另一台计算机

另一种选择是,创建一个Delphi应用程序,允许用户以高层次的方式“重构”他们的库安装,这将是一个有趣的项目。您可以指定系统上的哪些文件夹包含源组件或已编译组件
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PropertyGroup>
        <SVN_Root>..\..\..</SVN_Root>
        <SVN_Riemann>$(SVN_Root)\Riemann</SVN_Riemann>
        <SVN_Library>$(SVN_Root)\Library</SVN_Library>
        <SVN_ThirdParty>$(SVN_Library)\Third Party</SVN_ThirdParty>
    </PropertyGroup>
    <ProjectExtensions>
        <Borland.Personality>Delphi.Personality.12</Borland.Personality>
        <Borland.ProjectType>OptionSet</Borland.ProjectType>
        <BorlandProject>
            <Delphi.Personality/>
        </BorlandProject>
        <ProjectFileVersion>12</ProjectFileVersion>
    </ProjectExtensions>
</Project>