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

Question

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

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

正如我一直在研究这个问题,我考虑过几种不同的方法,但我想知道你在做什么以及如何找到你的方法.

重要场景​​:

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

注意事项:

• 短期:
  • 最简单的方法是什么？
• 长期:
  • 什么方法最简单易用？

在此先感谢您的反馈!

马蒂亚斯

---

---更新---

感谢您的反馈,通过答案,评论和投票!

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

敬请关注!(但不要屏住呼吸;你会在几分钟内窒息!:P)

Answer 1

使用源控制系统的文件共享功能

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

(编辑:重新命名为避免混淆. 当然,每个人都应该使用 Source Control!:-))