14

在项目之间共享 Delphi 源文件的最佳方式是什么？

澄清：我们想在多个 Delphi 项目中使用单个源文件。我们一直在使用我们的 SCM 工具将同一个文件放入多个文件夹，但这并不是一种超级优雅的体验，我们也在考虑迁移到不支持此功能的工具。

当我一直在调查这个问题时，我考虑了几种不同的方法，但我想知道你在做什么以及你是如何找到你的方法的。

重要场景​​：

  • 代码时间
    • 添加新的共享依赖项应该需要显式声明，以便管理共享。
    • 添加一个新的共享依赖应该还是比较简单的；它不应该需要一个复杂的过程。
      • 一个列出所有项目“导入”文件（从外部）的文件会很好。
  • 编译时
    • 所有项目都应始终使用一个当前版本（源同步状态的当前版本加上本地编辑）构建。
      • （在不同位置维护不同版本应该使用文件分支，这里不做主题。）
    • 每个项目是否应该能够使用不同的编译器设置（包括标志）影响共享文件的编译是有争议的。
      • 可以说维护（即长期）始终一致构建的源代码更容易。
      • 如果可以轻松地将所述更改的范围限制在一个项目中，那么进行维护修复（即短期）可能会更容易。
  • 调试时
    • 在进入例程或设置断点时，应自动打开正确版本的源代码。
    • 编辑显示的源应该会影响下一个构建。
      • 我们不想针对源的临时副本进行调试：我们可能会在混乱中丢失代码。

注意事项：

  • 短期：
    • 什么方法最容易实施？
  • 长期：
    • 哪种方法最易于使用和维护？

提前感谢您的反馈！

马蒂亚斯

- - 更新 - -

感谢您通过回答、评论和投票提供反馈！

我已经开始了将共享文件放入一个“生产者”项目并将已编译文件列表导入每个“消费者”项目的路径。这些项目正在与 MSBuild 链接在一起。一旦事情更加明确，我将编辑这个问题和“图书馆项目”的答案，分享我学到的东西。

敬请关注！（但不要屏住呼吸；你会在几分钟内窒息！：P）

4

6 回答 6

7

使用源代码管理系统的文件共享功能

  • 优点：如果 SCM 系统支持，设置快速且容易。
  • Pro/Con：每个消费者项目都可以独立影响编译时间。
  • 缺点：在本地工作副本中没有官方位置。
    • 这可能会导致混乱。
  • 缺点：在签入和重新检索之前，源更改不会反映在其他位置。
    • 在签入之前正确验证其他项目是可能的，但非常麻烦。
  • 缺点：并非所有 SCM 系统都支持共享文件。
    • Subversion 最接近的特性是文件夹级别的 svn:externals。

（编辑：重命名以避免混淆。 当然，每个人都应该使用源代码管理！:-)）

于 2008-11-03T19:39:03.650 回答
3

使用图书馆项目

  • 优点：每个文件只有一个副本可以编辑。
  • Pro：每个源文件只有一个编译。
    • 编译时间更短。
    • 依赖项目之间的一致编译。
    • 自然增量构建。
  • 优点：调试器自然链接到正确的源。
    • 待办事项：确认。
  • 优缺点：消费者项目不能独立影响编译时间。
  • 缺点：可能难以管理逐个文件级别的共享。
    • 待办事项：调查。
  • 缺点：可能需要花费大量精力来设置。
    • MSBuild 项目的设置。
    • 必须集中所需的项目设置，并且必须验证这些更改。
于 2008-11-03T19:42:58.883 回答
1

我认为不需要特殊的解决方案。在我们的项目（共享大量代码的几个应用程序）中，我们使用以下方法：

  1. 将源代码拆分到文件夹。
  2. 为共享代码的逻辑单元创建包。
  3. 支持单体（不使用包）和分块构建。
  4. Monolith 构建用于编码和调试。每个应用程序都有自己的 Unit 输出目录，因此它们都是独立构建的。
  5. 依赖限制由项目的搜索路径强制执行。
  6. Parted 构建是自动创建的（我们使用 CruiseControl 服务器和 MSBuild 项目）。自动构建会在构建之前清除所有临时文件夹，因此连续构建之间没有依赖关系。

在我们的例子中，我们无法控制导入文件的列表。但是，我们可以在分部构建中控制导入包的列表。更小的包意味着更好的粒度。如果有人正在向该单元添加依赖项，该单元位于搜索路径中不可用的文件夹中，并且包含该单元的包不在使用列表中，则 parted 构建失败。因此，需要显式操作（修改为 parted 构建生成 CFG 文件的 MSBuild 脚本）来添加依赖项。

PS 我们使用包不是为了控制依赖关系，而是因为 Windows 非 NT 版本运行大型应用程序的问题。所以，依赖控制是一个副作用。分开的构建被认为是“发布”，而单体——作为“调试”配置。Monolith 应用程序仅用于编码和调试。开发人员使用单体应用程序，并在项目配置中引入他们自己的更改，例如附加 VCL 调试信息、开关范围检查错误、优化等。然而，在提交到 SVN 后，CC 尝试进行部分构建。它忽略存储库中的 CFG 文件并使用 MSBuild 项目的特殊任务重新创建它们。因此，我们可以确定没有引入依赖项问题（并执行其他检查）。

就我们不需要同时构建单体和分块构建而言，我们每个应用程序只有一个项目。如果您想在 MSBuild 脚本中构建这两个版本，您可以简单地再添加一个目标，再重新创建一次 CFG，然后再指定一个 Unit 输出目录。当然，如果开发者都需要这两个版本，项目多一些会更方便。

于 2008-11-04T09:27:34.633 回答
1

我不确定我是否正确理解了问题。无论如何，在构建应用程序套件（几个项目但有很多通用代码）时，我们会创建如下文件夹结构：

\Main
   \Project1
   \Project2
   ...
   \CommonUnits

我们将常用单元添加到相关项目中（不管它与项目文件不在同一个文件夹中）。此外，有时更容易使用项目级别的条件定义（项目|选项|目录/条件）来处理小的代码差异。例如，Project1 将定义类似“APP_PROJECT1”的内容，然后您可以在通用单元中使用 $IFDEF 来编写特定代码。

重要的是：在这种情况下，最好为整个套件拥有一个源代码控制存储库（当然，根目录是 \Main）。

于 2008-11-17T11:02:41.730 回答
0

编译时复制

  • 优点：文件共享可以逐个文件进行管理。
  • Pro/Con：每个消费者项目都可以独立影响编译时间。
  • 缺点：调试器将链接到临时副本，而不是正式版本。
    • TODO：看看是否有办法改变这一点。
  • 缺点：可能需要一些工作来设置 MSBuild 项目。
  • 缺点：增量构建共享文件可能很困难。
    • 可能涉及重写一些 Delphi 的 MSBuild 规则。
于 2008-11-03T19:40:30.980 回答
0

复制-编译-删除

  • 亲：每个文件只有一份正式副本，可以编辑。
  • 优点：调试器不会链接到临时副本，因为它已被调试时删除。
    • TODO：验证调试器是否会找到原始源，如果我们将它放在“浏览路径”中。
  • 优点：文件共享可以逐个文件进行管理。
  • Pro/Con：每个消费者项目都可以独立影响编译时间。
  • 缺点：可能需要一些工作来设置 MSBuild 项目。
  • 缺点：增量构建共享文件可能很困难/不可能。
    • 可能涉及重写一些 Delphi 的 MSBuild 规则。
于 2008-11-03T19:41:36.297 回答