21

Delphi-6 有两个选项：构建和编译。

我知道当我运行一个程序时，它只编译已更改的文件，并将 DCU 用于未更改的文件。当我显然单击构建时，它会重建 DCU。

我一直想知道的是，当我制作一个发布程序（更改构建设置、条件变量等）时，我可以只编译，还是必须进行完整构建？

如果我不进行完整构建会发生什么，有什么后果吗？

4

4 回答 4

27

@Daisetsu，这是构建和编译之间的区别。

当源代码可用时， Build编译项目中所有使用的单元。

编译只编译更改的使用单位。

以我个人的经验，当您对编译器的配置进行更改时，您必须执行应用程序的构建，以便更改将反映在项目的所有单元中。

于 2010-07-13T02:38:45.113 回答
20

什么时候编译，什么时候编译？

仅当 .pas 源文件的日期时间戳更改 (1,2) 时，编译器才会自动重新编译单元。

在项目中的其他状态更改（指令、调试或其他编译器设置等）中，编译器不会自动重新编译。那是你需要强制构建的时候。

当 .inc 或其他包含的 ($I) 文件更改 (3) 时，您还需要强制重建，因为它们的日期时间戳未被检查。

所以总而言之，当单元 .pas 文件以外的任何内容发生更改时，您需要进行构建。

建筑中有一些奇怪的案例。大多数会导致“找不到单元 xxx”错误，而它似乎在那里

  1. 一种是项目中单元的路径错误，或者工作目录错误时使用相对路径。（参见Delphi 调试错误单元）
  2. （我对此并不完全确定，这是一个假设）由于 CRC (1) 而重新编译了 .dcu，但新编译的 dcu 被放置在不同的目录中。这对于当前编译来说不是问题（因为已经加载了正确的 dcu），但是在随后的编译（例如依赖包）中，旧的 dcu 文件又被找到了，并且源不是 -> 错误。 如有疑问，请始终通过递归删除所有 DCU 来清理您的构建目录
  3. 该单位在 .dpr 中的路径错误

(1) 如果 Delphi 像 FPC，.dcu 包含它所依赖的所有 dcu 的接口部分的 CRC。这可用于检查是否还需要重新编译。例如由于文件系统操作（移动 dcu）

(2) 对于专家来说，也看看 {$implicitbuild xx}

(3) 与 Delphi 不同，FPC 确实在 .inc 更改时重建。FPC 项目在内部大量使用 .inc 文件，这种更改已经可以追溯到 Delphi 支持之前。因此，将“defines”inc 文件复制到任何目录的包都不会使用 FPC 编译，因为它们的大小和 CRC 通常略有不同。Indy (10) 就是一个很好的例子。

于 2010-07-13T09:07:02.793 回答
3

更改设置时应始终构建。

之前编译的 DCU 文件可能已使用不同的设置进行编译，例如编译器定义。这可能导致同一项目中的两个单元使用不同的设置进行编译。

于 2010-07-13T02:34:13.530 回答
3

在准备发布时，您当然应该进行完整的构建。
没有理由不这样做，Delphi 的编译器足够快。

阐明可重复发布的重要性

  • 在准备发布时，您将拥有一个其他人将使用的产品版本。
  • 如果他们报告问题，您可能需要返回到该版本来测试和解决问题。
  • If you did not do a full build, but instead relied existing DCU's there is a chance that one of your source files did not get recompiled.
  • Even if that possibility is rather slim, that chance can seriously hamper your ability to resolve the issue quickly.
  • This problem gets worse as a system gets larger, has more inter-dependencies, and has more versions 'supported in the wild'.

For your own sanity, I strongly urge that you always do full build for a releasable version.
I regularly do full builds even for non-releasable versions.

于 2010-07-13T13:25:38.580 回答