组织的搜索路径

我们通过“工具|选项|环境变量”创建变量这样的：组织的搜索路径

$(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

但这自德尔福2009年以来已经破裂（同时固定），因为这些变量不再被完全评估（见QC#73276）。所以编译器找不到目录中的文件。解决方法：仅使用环境变量中的完整目录。

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

我们没有任何东西在我们的全局库路径中（Delphi默认值除外），因为这不在版本控制中，并且不会反映在其他开发人员或构建机器上。

一个问题是：如果$（OurLib）中的一个单位决定在另一个新路径中包含另一个新单元，则所有项目都会因为没有找到此新单元而中断。然后我们必须通过所有项目并添加搜索路径。（顺便说一句：我真的很讨厌的搜索路径编辑器......不会是一个简单的备注字段更好的编辑比这个替换/添加/删除逻辑？）

我们做的不是加入许多单位的另一件事情我们项目。尤其是来自$（OurLib）的所有内容，但我们经常拥有像插件这样的单元，只有通过包含它们才能添加功能。对于我们产品的不同版本，我们希望包含不同的单位。由于Delphi总是在.dpr的uses子句中混淆$ IFDEFs，因此我们通过包含名为“IncludePlugins”的单元来帮助我们，这些单元包含依赖于IFDEF的单元。但是不包括项目中的单位导致痛苦。单位不会出现在项目中，他们没有按Ctrl + 12（显示单元）发现，他们不是在代码完成显示等

大家有更好的方法来解决这些问题？

来源

2009-04-23 Steffen Binas

我们只使用相对路径，任何图书馆总是库子目录之下，而项目的源代码驻留在src子目录。因此，我们的搜索路径总是如下所示：

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

等

所有库添加为SVN：外部的每一个项目，所以检查出的项目会自动检查出库，以及与搜索路径总是指向正确版本的库为该项目。

并不完美，但它工作的大部分时间。

我不得不承认有关的搜索路径编辑器，它是更糟糕的相对路径，因为你不能使用“...”按钮，否则Delphi将插入一个绝对路径。

来源

2009-04-23 09:45:21 dummzeuch

我们使用标准的驱动器映射。

我们目前的项目总是在W上：不管它是网络驱动器还是替代品。

This works great。

当您需要处理不同的项目时，请交换W：然后您可以继续。

来源

2009-04-23 09:00:43

事实上，我们就此别过。我们的构建机器将$（Sources）映射到S：并将得到的二进制文件放在T：创建设置的地方。我们的工具链的所有应用程序都不支持更改根目录。 – 2009-04-23 09:08:12

您可以复制出来的搜索路径编辑，修改，然后将其复制回来。

来源

2009-04-23 13:33:57

您的搜索路径太大了。它应该包含只有你想要Delphi重新编译你的项目的东西。你真的不想每天重新编译Jedi VCL，是吗？

我创建一个单独的目录，所有编制单位去。说，C：\ dcu。将其指定为包中的“单元输出目录”全部为包。我的“搜索路径”，那么，是总是只是这样的：

$(Delphi)\Lib;C:\dcu

编译器发现它所需要的一切，和它从来没有发现任何的源代码。它所见到的唯一源代码是直接属于我正在编译的任何项目的文件。项目自己的源代码目录不需要在搜索路径上，因为所有这些文件都是项目的直接成员。编译器确切地知道它们在哪里。

对我来说，所有项目的源文件走在一个单一的目录中。如果你想为不同的部分单独的目录，如核心和GUI，然后我把这些分开包装，所以我可以对他们的工作，并分别编译它们。即使最终的程序不使用生成的BPL，程序包仍然是分割项目和定义依赖关系的好方法。

在编制单位，一个项目不会自动编译单位的所有其他项目，你不得不改变活动项目。这需要你花一点时间，但它也提醒你，你也在“换帽子”。

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

我不明白您对插件和项目的不同版本的一部分。当你说“插件”时，我假设你正在讨论单独的可执行模块，如DLL或包，客户可以选择包含或不包含。难道你不能将你的不同版本的功能变成插件模块，而这些插件模块不包含在较小的版本中？那么你不必担心条件编译你的项目;只需要几个不同的安装程序打包工具来抓取不同的插件集。

来源

2009-04-23 15:08:49

一个DCU目录：我记得我们已经考虑过这个，但我认为有重复单元名称的问题。但我会重新考虑这一点。插件：有些东西很难通过“真实”插件（DLLs/Packages）进行区分，例如，该应用程序的试用版。由于我们不使用软件包，因此包括例如一个TFrame后代通过一个DLL，因为我们将不得不接口这个。 – 2009-04-23 16:19:53

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

作为一种替代方案，它可以创建一个有趣的项目来创建一个Delphi应用程序，该应用程序允许用户以高级方式“重构”其库安装。您可以指定系统上的哪些文件夹包含源代码或编译组件或任何您想要保留源文件或编译单元的位置，在更新Delphi环境时打开Go并重新安排系统，以便在启动Delphi时找到它应该的一切。

来源

2009-04-23 16:28:02 jrodenhi

我刚刚发现了一种在delphi中使用XE6构建项目特定环境变量的方法，它不像C中那样充分发挥了#define的作用，但至少我现在可以在多个项目并创建一些共享选项集。

我所做的是以与原始海报相同的方式设置环境变量，然后在dproj或optionset中覆盖它们。

的BuildPaths.optset添加到项目中看起来像

<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>

来源

2016-04-29 02:04:56

这是一个工作答案或没有？ – Mostafiz 2016-04-29 02:22:27

组织的搜索路径

回答

相关问题