“库路径”应该指向包的源文件吗？ Delphi 7文档说是。但是其他人说不：“The Library”路径应该只导致编译文件（.dcp，.dcu）和（如果需要）资源文件（.res，.dfm）“。
更新：
问题是，如果你不在“库路径”中添加包的路径，那么每次创建一个新的DPR项目时，你必须手动收集包的路径（很多）并将它们输入到项目中选项“浏览”框，否则您将收到“找不到文件xxx.dcu”。听起来不太好听。多年来，我曾经在库中添加了所有路径，并且每次创建新项目时都不必手动添加路径。
当设置路径和官方文档是0时，Delphi 7是如此混乱。:(
更新：
我做了改变。它有效，但它甚至不是完美的（或至少是优雅的）：How to remove duplicate resources (RES, DFM) while using Delphi with non specific Library paths?
答案 0 :(得分：6)
您指向库路径的位置并不是指向编译文件（dcu / dcp文件和exe / bpl文件）的输出路径的重要性的一半。
每个项目都应该有自己的输出路径。如果您这样做，那么即使您将库路径指向源文件，二进制文件也将位于项目特定的文件夹中，因此永远不会干扰其他项目。
使用全局（环境选项）库路径时要小心。我实际上是空的。甚至没有像$（BDS）\ Lib这样的标准Delphi文件夹。为什么？因为它确保每个项目都需要在dproj中显式地依赖库。这意味着您可以加载和构建需要同一库的不同版本的项目，而不会出现错误，因为您的环境路径指向的库版本不同于项目所需的版本。这在调试时也有很大帮助，因为调试器将始终使用项目所需的版本，而不是全局环境路径所指向的版本。
如果您的任何图书馆都有可视组件，您仍然不需要它们在全球环境路径。您只需要确保IDE使用您最常用的版本中的bpl。这是否是旧的无关紧要（除了它可能导致dfm的内容发生变化这一事实，但源版本控制应该有帮助）。您只需要IDE中的bpl，以便在加载表单时不会对您进行barf。实际上我的IDE通常没有安装任何第三方组件（即使项目使用它们），但是我没有做很多dfm工作，当我需要在表单的pas文件中更改代码时我只告诉IDE忽略所有错误（但保留表单单元中的引用！）并在提交时恢复对dfm的任何更改。
哦，我总是从源代码编译。这样，如果我得到一个库中的单个文件的补丁，我不必经历整个安装过程，我甚至不必重新编译组件包。我可以简单地将更新后的源文件放在正确的文件夹中，并继续发生任何事情。
此外，我在所有项目中使用相对路径。我知道有些人遭受了这种痛苦，但我从未遇到过问题。可能是因为我从未在Windows资源管理器中双击打开任何文件，但总是从IDE中或者可能通过从资源管理器中拖放来查看（以前版本的）文件而不使其成为项目的一部分。相对路径使得负载和负载更容易制作项目副本，具有任意数量的工作空间（Perforce），并在它们之间切换而无需“修复”dpr中的路径。
以上所有都是我在许多不同项目中工作的习惯，经常需要在我们自己的代码版本之间来回切换，这通常也涉及在库版本之间切换。
答案 1 :(得分：4)
问题是，如果您不在“库路径”中添加包的路径，那么每次创建新的DPR项目时，您都必须手动收集包的路径（很多）并输入它们进入项目的选项“浏览”框，否则你将得到“找不到文件xxx.dcu”
不是真的。您需要创建默认项目选项。为了做到这一点，加载Delphi（我在这里谈论D2010，但至少可以使用D7中的相同功能）并确保IDE中没有加载的项目。
之后，打开一个文件（任何文件）并转到Project / Default Options / Delphi（或C ++ Builder，你可以选择个性）。这将打开一个基本项目选项屏幕。配置它直到你开心并按OK。
使用文件/新建/ VCL表单应用程序创建一个新项目，并查看应用的默认设置。
编辑：自XE2以来，默认项目被Option Sets取代。
帮助链接： 请参阅http://docwiki.embarcadero.com/RADStudio/en/IDE_Changes_for_XE2#Default_Checkbox_Removed_from_Project_Options_Pages http://docwiki.embarcadero.com/RADStudio/en/Option_Sets_-
_Creating，_Applying，_Editing，_and_Deleting - 详情请见：http://codeverge.com/embarcadero.delphi.ide/project-options-default-xe2/1058015#sthash.oovBcggS.dpuf
答案 2 :(得分：2)
我建议使用“全局”库路径指向您的“全局”库。如果在.pas之前找到.dcu，则无需重新编译源代码即可使用它们。除非您经常修改库源代码，否则我会避免使用它，并且我不会使用特定于应用程序的代码“污染”它。 IMHO特定于应用程序的dcu不应放在“全局”库路径中。您可以轻松使用“单位输出目录”将dcu存储在每个应用程序的公共目录中
答案 3 :(得分：2)
我在下面描述的技术对我们很有用，因为无论我们使用的是什么版本的Delphi，所有项目都使用相同版本的库。
例如，我们有一个使用Delphi 6构建（并且仍在积极开发）的分支。我们的主干在一年前迁移到Delphi 2009，然后在几个月前迁移到2010，很快就会迁移到Delphi XE。但是主干中的所有项目都将使用相同版本的Delphi和相同版本的库。
第三方组件供应商喜欢将源安装到共享位置，然后对编译的代码使用不同的输出文件夹。另一方面，我更喜欢为每个安装的Delphi版本安装每个第三方库的单独副本。如果我安装了我最喜欢的组件库之一的更新“版本5.4”，我可能不希望将单个安装应用于我正在使用的每个版本的Delphi。因此，为每个安装的Delphi版本单独安装每个组件库。 （当库使用“典型”Windows安装程序时，这是一种痛苦，它不想多次安装同一产品。）
说完所有这些之后，我们在工具|选项中的全局库路径指向所有第三方库的OUTPUT文件夹。这样，每个新项目都可以在没有任何额外工作的情况下完成，并且编译任何项目都不会重新编译在项目更改时不会更改的标准第三方库代码。
在极少数情况下，我们需要一个补丁（源代码覆盖）到第三方库，这些补丁进入一个单独的文件夹，并在每次编译项目时编译。一旦第三方发布包含修复程序的更新，我们将删除该修补程序的副本。
我们使用包含大量源代码的第三方库，例如ReportBuilder，Raize Components，TurboPower产品等。我认为没有理由在“构建”项目时重新编译所有代码。< / p>
答案 4 :(得分：1)
我说不，因为编译应用程序的速度更快，因为dcus已经编译好了。
答案 5 :(得分：0)
虽然这里提供的答案肯定是好的和正确的（每个人都得到了投票），经过实验后我决定保留我之前的（KISS）设置。它工作了多年，它将工作更多。我知道，它交易速度（重新编译源代码）的稳定性，但它保持“路径，库，源，浏览和输出文件夹”疯狂。我不再需要担心设置路径（除了我第一次安装Delphi但这可以自动化）或退出当前的DPR Delphi项目并加载DPK库并在每次添加更改时编译它。 / p>