这个问题类似于this one，但不重复，因为我问的问题没有讨论过。
我在Delphi 7中有一个客户端 - 服务器项目，具有以下目录结构：
\MyApp
\MyClientApp
\MyServerApp
\lib
有2个实际的Delphi项目（.dpr），MyClientApp和MyServerApp文件夹各有一个。
lib文件夹的.pas单元具有客户端和服务器应用程序的公共代码。我想知道的是我是否应该在客户端和服务器项目中包含那些.pas文件？或者我应该在包含这些单位的lib文件夹中创建一个包？或者我应该将.pas文件保留在lib文件夹中，而不是将它们添加到任何应用程序/包中？
每种方法的优点/缺点是什么？哪种方式“最好”？将lib文件夹中的那些单元包含在多个项目中是否存在任何问题？
现在，lib文件夹中的单元不是任何app / package的一部分。这样做的一个缺点是，当我在Delphi中打开我的客户端应用程序时，我想在项目中的所有文件中搜索某些东西，它也不会搜索lib文件夹中的单元。我通过打开这些单元并在所有打开的文件中查找或使用grep搜索（但我更喜欢更好的解决方案）来解决这个问题。
我也非常喜欢一个解决方案，我不必去打开一些单独的包并在我对lib文件夹中的那些文件进行更改时重新编译它（这是我应该使用项目组吗？）。 / p>
答案 0 :(得分：8)
应用程序之间共享单元始终存在在一个应用程序中完成不兼容更改的风险，这些更改会破坏另一个应用程序另一方面，制作这些单元的副本更加糟糕，因此将它们移动到自己的子目录中的方法至少会增加一个心理障碍来改变它们而不考虑其他程序。
至于将它们添加到项目文件中：我通常会添加一些我经常访问的单元（用于扩展或供参考）从IDE到项目，并留下其他单元供编译器使用搜索路径进行选择。我是按项目进行的，这意味着，有些单位可能是几个项目的一部分，为什么不呢？
如果你真的想要创建一个基于包的应用程序，那么将它们放入包只是有意义的，否则，为什么要这么麻烦呢？
有关我如何组织项目和库的更多信息，请参阅http://www.dummzeuch.de/delphi/subversion/english.html
答案 1 :(得分：5)
我不喜欢项目共享的文件。很多时候，你会想要编辑其中一个共享文件，你要么在其他项目中破坏某些东西，要么忘记你必须重建另一个项目。
当共享文件被分成他们自己的库（包）时，编辑它们会有一些额外的障碍。我认为这是一件好事。这将提醒您，您正在从项目特定代码切换到共享代码。您可以使用项目组让您在一个IDE实例中保持每个组合。在可执行项目之前安排库项目。 “build all”命令将按顺序构建所有内容，从第一个项目开始。
将您的DCU文件与PAS文件分开。您可以通过设置“DCU输出目录”项目选项将包裹的单位发送到其他位置，从而轻松完成此操作。然后将该目标目录放在其他项目的“搜索路径”上。他们会找到DCU，但他们找不到PAS文件，因此没有其他项目会意外重新编译一个真正不属于其成员的单元。
拥有单独的包也不鼓励使用特定于项目的条件定义。当你在项目之间共享单元时，这会导致各种麻烦。找到一种方法，将所有项目特定的选项保留在相应的项目中。共享库不应要求特定于项目的修改。如果某个库需要根据谁使用它而采取不同的行为，那么采用库回放函数等技术，库用户可以设置这些函数来修改库的行为。
答案 2 :(得分：4)
我需要有一个很好的理由将共享代码添加到包中。如果你只有一些共享文件将它们全部放在名为Shared的目录中。这应该很明显，文件在项目之间共享。
还可以使用一个好的构建工具来进行自动构建，这样如果你破坏了某些东西，你很快就会发现它。
.bpl文件适用于组件，但除非你有大量的共享文件，否则会给这类事情带来严重的复杂性。
答案 3 :(得分：3)
我通常使用所有共享单元创建一个包，只需使用单位。 如果您没有明确标记“使用运行时软件包构建”，则软件包内容（所有使用的dcu）将与任何其他单元链接到您的项目。
答案 4 :(得分：2)
如果你实际上有两个应该在同一台物理机器上运行并且共享一些代码的二进制文件，我只会使用运行时包。请记住，运行时包主要是一种全有或全无的方法。一旦您决定使用它们，您也将无法再将RTL和VCL单元直接链接到您的项目中，而是必须单独部署它们。
但是，与项目组结合使用时，软件包可能仍然是一个很好的解决方案，这正是我正在做的事情。我讨厌在多个项目中包含共享单元。将包中的共享单元包括在内（但不包括使用运行时包编译实际项目）允许您将该包添加到项目组中，这样您（以及IDE！）将始终可以轻松访问它们，并且与项目特定的内容完全分离码。严格来说，你甚至不必编译这些包。他们只能作为项目经理的组织单位。
请注意，对于“在文件中查找”，您还可以指定“在项目组中的所有文件中”