在项目中共享Delphi源文件的最佳方法是什么？

Question

在项目中共享Delphi源文件的最佳方法是什么？

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

正如我一直在研究这个问题，我考虑了一些不同的方法，但我想知道你在做什么以及如何找到你的方法。

重要方案：

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

考虑：

• 近期限：
  • 最简单的方法是什么？
• 长期：
  • 哪种方法最简单易用？

提前感谢您的反馈！

的Mattias

<小时/> ---更新---

感谢您的反馈，通过回答，评论和投票！

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

敬请期待！ （但不要屏住呼吸;你会在几分钟内窒息！：P）

Answer 1

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

• Pro：如果SCM系统支持，可以快速轻松地进行设置。
• Pro / Con：每个消费者项目都可以独立影响编译时间。
• Con：当地的工作副本中没有官方位置。
  • 这可能导致混淆。
• Con：在签入并重新检索之前，源更改不会反映在其他位置。
  • 在签到之前，为了正确验证其他项目，可能会对枪托造成严重的痛苦。
• Con：并非所有SCM系统都支持共享文件。
  • Subversion最接近的功能是文件夹级别的svn：externals。

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

Answer 2

使用图书馆计划

• Pro：每个文件只能复制一次，以便进行编辑。
• Pro：每个源文件只有一个编译。
  • 减少编译时间。
  • 依赖项目之间的一致编译。
  • 自然增量构建。
• Pro：调试器自然链接到正确的源。
  • TODO：确认。
• Pro / Con：消费者项目不能独立影响编译时。
• Con：可能难以在逐个文件级别管理共享。
  • TODO：调查。
• Con：可能需要付出很大的努力来设置。
  • 设置MSBuild项目。
  • 必须集中所需的项目设置，并且必须验证这些更改。

Answer 3

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

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

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

P.S。我们使用的包不是为了控制依赖，而是因为Windows非NT版本运行大型应用程序的问题。因此，依赖控制是一种副作用。 Parted构建被视为“release”，monolith - 被视为“debug”配置。 Monolith应用程序仅用于编码和调试。开发人员使用整体应用程序，并将自己的更改引入项目配置，如附加VCL调试信息，打开和关闭范围检查错误，优化等。但是，在提交到SVN后，CC尝试进行分区构建。它忽略来自存储库的CFG文件，并使用MSBuild项目的特殊任务重新创建它们。因此，我们可以确定没有引入依赖项问题（并执行其他检查）。

只要我们不需要同时使用整体和分块构建，我们每个应用程序只有一个项目。如果要在MSBuild脚本中构建两个版本，只需添加一个目标，再重新创建一次CFG并再指定一个单元输出目录。当然，如果开发人员需要这两个版本，那么拥有更多项目会更方便。

Answer 4

我不确定我是否理解了问题。无论如何，当构建应用程序套件（几个项目但很多公共代码）时，我们创建这样的文件夹结构：

\Main
   \Project1
   \Project2
   ...
   \CommonUnits

我们向相关项目添加公共单位（无论它与项目文件不在同一文件夹中）。此外，有时使用项目级条件定义（Project | Options | Directories / Conditionals）更容易实现小代码差异。例如，Project1将定义类似“APP_PROJECT1”的内容，然后您可以使用常用单元中的$ IFDEF来编写特定代码。

重要的是：在这种情况下，最好为整个套件安装一个源控制存储库（root当然是\ Main）。

Answer 5

复制上编译

• Pro：文件共享可以逐个文件管理。
• Pro / Con：每个消费者项目都可以独立影响编译时间。
• Con：调试器将链接到临时副本，而不是正式版本。
  • TODO：看看是否有办法改变这种状况。
• Con：可能需要一些工作来设置MSBuild项目。
• Con：可能难以逐步构建共享文件。
  • 可能涉及重写一些Delphi的MSBuild规则。

Answer 6

复制 - 编译 - 删除

• Pro：每个文件的正式副本只能编辑。
• Pro：调试器不会链接到临时副本，因为它已被调试时删除。
  • TODO：如果我们将调试器放在“浏览路径”中，请验证调试器是否会找到原始源。
• Pro：文件共享可以逐个文件管理。
• Pro / Con：每个消费者项目都可以独立影响编译时间。
• Con：可能需要一些工作来设置MSBuild项目。
• Con：可能很难/无法逐步构建共享文件。
  • 可能涉及重写一些Delphi的MSBuild规则。