我对整个 Delphi 生态系统非常陌生。我使用的是Rad Studio XE 2。
假设我有一个非常简单的案例。
项目A、B和C。C依赖于B。B依赖于A。
这也是我如何使用'项目依赖' IDE GUI设置依赖项的方法。
C是产生可执行文件的项目。它被设置为“当前项目”。
如果我修改了项目B中的一个文件并按下F5键（运行），我希望只有项目B和C可以编译。
然而，项目A总是被重新构建！！即使我在项目C中修改了一个源文件，情况也是如此。
我做错什么了吗？如果是的话，有什么想法吗？
或者这只是IDE的工作方式？
一个客户有一个大型的遗留代码库，并使用XE 2。目前，他们正在手动处理依赖项目的重新编译，方法是右键单击需要重新编译的最低项目，然后选择“从此处构建...”。
当我在XE 2中发现“项目管理”功能时，我认为这将是这个问题的解决方案。
- 编辑 *
好的。我会试着更好地解释这一点，因为我看到我的问题/关注并没有真正得到解决。
我有一个由许多BPL项目（据我所知输出DLL）和一个可执行项目组成的groupproject：C.exe。
C.exe引用所有BPL项目，包括A.BPL和B. BPL。现在，如果我修改任何BPL项目中的代码并执行'Run'，C.exe将启动，但我刚才所做的更改不会生效，因为BPL项目没有重新编译。这实际上是我的痛点。到目前为止，我使用的所有IDE也会重新编译依赖的dll。当然，假设项目设置正确。现在我的问题。我不知道该项目只是没有正确设置，或者这是IDE的限制。如果我右键单击修改后的BPL项目，选择“从这里编译”，然后执行“运行”，我的更改将生效。然而，必须这样做是相当烦人的当我习惯于只运行可执行文件而不必担心重新编译依赖关系时，这一点就很重要了。
如上所述，我确实尝试使用IDE的“依赖项”功能。然而，这种行为非常奇怪（对我来说）。即使源代码没有修改，它也会重新编译依赖项。
4条答案
按热度按时间ifsvaxew1#
你的期望是错误的。文件上说：
你看到的行为是故意的。
k75qkfdt2#
首先，你说“F5（运行）"。它是F9...
第二，你的系统可能有时间问题。DCU被一个进程触动或者类似的事情正在发生。
第三，你可能会把目录搞得一团糟。
字符串
另外，打开您的项目
型
看看你有没有问题。另外，试着从所有地方删除所有的DCU（也可参见临时目录等）。此外，如果您有DPKs，BPLs阿索.尝试通过创建一个名为“隐藏”的子文件夹来“隐藏”它们（或其他）。在此之后，如果需要，修复项目A、B和C的（输出）目录结构，并对所有内容进行全新的构建。在此之后，查看问题是否仍然存在。
第四，你可以有一个在C和A中都使用的单元。如果你“为项目C”改变它，当然它会触发A的重建。
祝你好运
rjee0c153#
对于具有复杂构建依赖项的项目，我通常只是简单地创建一个外部构建脚本，然后按照已知的工作顺序构建内容。也就是说，我不完全从IDE中工作，而是直接转到命令提示符，键入
build和一个批处理文件（build.cmd），负责清理以前的DCU，运行msbuild几次来构建所有我需要构建的东西，这样我就有了可重复的、易于构建的产品。在这些项目中进行开发时，我可能会在IDE中工作一段时间，但对于这些情况，我总是返回命令行构建。
Delphi IDE的依赖系统是一个可悲的小黑客。命令行构建不是一个真正的C风格的make系统，当 Delphi 参与进来时，它更像是一个每次都要完全重建的蛮力解决方案。然而，由于这就是持续集成（当在服务器上运行时）通常无论如何都会这样做，并且由于您可以在继续处理另一个项目的同时运行这样的命令行构建，我发现这是一种可行的方法，“不必再担心依赖关系问题和构建订单”，这是我的根本问题。
ibps3vxo4#
图书馆建筑
如何组织你的代码？
(with真实世界的例子）
如果你看一下LightSaber（www.GitHub.com/GabrielOnDelphi/Delphi-LightSaber），你会发现它实际上是一个分层库的集合，排列成一个自上而下的金字塔。
在金字塔的底部，我们有底层的Core库，它包含非常基本的功能，所有其他库都需要的功能，所以不能在层次结构中向上移动。因此，层次结构中的所有其他库都使用Core库，但Core库不使用更高级别的库。实际上，它甚至不知道它上面是什么（上面有多少个库）。
最重要的是Log，它负责捕获应用程序范围内的错误消息并将其显示在日志中。Log库需要Core库。我们如何知道Log库需要Core库？我们查看其DPK文件或其Project Inspector。
x1c 0d1x的数据
的
然后是Common库，它提供了更多的通用功能。最上面的是Translator库。它用于自动化翻译程序的GUI的过程。它依赖于Core和Common的功能。两个专门的库紧随其后：Internet和Graphics库。然后是许可库Proteus。最后一个库包含大量的可视化组件。
Translator和Proteus库在某种程度上是分开的，因为它们不需要更高级别的库。例如，Visual Controls库不需要Proteus库。
型
在最顶层的是使用所有这些库的 Delphi 项目。注意一个项目可以只使用底层的Core库，而其他项目可以只使用Proteus（以及下面的所有库）。项目2使用可视化控件，它需要下面的所有库（同样，除了Proteus和Translator）。
永远记住，高级库可以依赖于低级库中的函数，但不能反过来。
都是关于外星人和金字塔
我花了一段时间才找到LightSaber库的最佳布局。在2000-2005年的时候，关于如何构建一个复杂的库集合而不产生相互依赖的信息真的很可怕。但是一旦你理解了基本原理，并且买得起笔和纸来画一个像上面的“金字塔”一样的图表，它就不再那么困难了！
如果你的程序有超过10000行代码，都在一个DPR文件下，那么你应该考虑把你的代码拆分成库。我有很多关于单片代码的恐怖故事。如果你有两个程序使用一组公共函数，那么你必须把你的代码拆分成库！我有很多关于单片/坏结构化代码的恐怖故事。
一家公司雇佣我来建立一个库架构。他们从来没有建立过自己的库，他们有非常过时的代码。业务逻辑，而不是在自己的库中分开，都是和表单的代码混合在一起的。每当他们需要一些已经存在的代码时，他们只是复制/粘贴代码。每当他们在其中一个单元中发现一个bug时，他们需要找到他们复制/粘贴代码片段的每个示例来修复它。这不是编写代码的明智和可扩展的方式。结果，应用程序经常崩溃，并且花费在调试上的时间比开发时间多。
一个多层库解决了这个问题。我们慢慢地找到了所有重复的代码，并将其转移到专用单元中。
结论：
如果你的库架构是正确的，所有的都应该顺利地工作。只要使用金字塔底部的全部构建命令。就是这样。
隶属关系免责声明：这个答案是从“ Delphi 在其所有的荣耀”一书摘录。