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

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

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

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

重要场景：

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

注意事项：

• 近期：
  • 最简单的方法是什么
• 长期：
  • 使用和维护最简单的方法是什么

提前感谢您的反馈

马蒂亚斯

---

---更新---

感谢您的反馈，通过答案、评论和投票

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

---

请继续收看！（但不要屏住呼吸；几分钟内你就会窒息！：P）

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

• Pro：如果SCM系统支持，则设置快速且容易
• 赞成/反对：每个用户项目都可以独立地影响编译时间
• 缺点：没有正式的地点，在当地的工作副本的来源。
  • 这可能导致混乱
• 缺点：在签入并重新检索之前，源更改不会反映在其他位置。
  • 在签入之前，正确地验证其他项目是可能的，但这是一个巨大的麻烦
• 缺点：并非所有SCM系统都支持共享文件。
  • Subversion最接近的功能是文件夹级别的svn:externals

---

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

编译时复制

• 赞成：文件共享可以逐个文件管理
• 赞成/反对：每个用户项目都可以独立地影响编译时间
• 缺点：调试器将链接到临时副本，而不是正式版本。
  • TODO:看看是否有办法改变这一点
• 缺点：设置MSBuild项目可能需要一些工作
• 缺点：以增量方式构建共享文件可能很困难。
  • 可能涉及重写Delphi的一些MSBuild规则

---

复制编译删除

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

---

使用图书馆项目
• 赞成：每个文件只有一个副本可以编辑
• Pro：每个源文件只编译一次。
  • 更少的编译时间
  • 相关项目之间的一致编译
  • 自然增量构建
• 赞成：调试器自然链接到正确的源代码。
  • TODO:确认
• 赞成/反对：消费者项目不能独立地影响编译时间
• 缺点：在一个文件一个文件的级别上管理共享可能很困难。
  • TODO:调查
• 缺点：可能需要花费大量的精力来建立。
  • MSBuild项目的设置
  • 必须集中所需的项目设置，并且必须验证这些更改

---

我认为不需要特殊的解决方案。在我们的项目（多个应用程序共享大量代码）中，我们使用以下方法：
• 将源代码拆分为文件夹
• 为共享的逻辑单元创建包

  \Main
     \Project1
     \Project2
     ...
     \CommonUnits