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

前端之家收集整理的这篇文章主要介绍了在项目中共享Delphi源文件的最佳方式是什么?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
在项目中共享Delphi源文件的最佳方式是什么?

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

正如我一直在调查这个问题一样,我已经考虑了几种不同的方法,但是我想知道你在做什么,以及如何找到你的方法.

重要情景:

>代码时间

>添加新的共享依赖关系应该需要明确的声明,以便管理共享.
>添加新的共享依赖关系应该还比较简单;它不应该需要一个复杂的过程.

>一个列出所有项目的“导入”文件(从外部)的文件将是不错的.

>编译时间

>所有项目应始终使用一个当前版本(当前来源同步状态加本地编辑)构建.

>(在不同的位置维护不同的版本应该使用文件分支,这不是这个主题).

>每个项目是否能够影响共享文件的编译与不同的编译器设置(包括标志)是有争议的.

>始终建立始终保持(即长期)源代码可以说更容易.
>如果所述更改的范围可以容易地限制在一个项目中,则可以更容易地进行维护修复(即短期).

>调试时间

>正确版本的源码应该自动打开,当进入例程或设置断点时.
>编辑显示的源将影响下一个构建.

>我们不想调试源的临时副本:我们可能会丢失代码,在混乱中.

注意事项:

>近期:

>什么方法最简单?

>长期:

>什么方法最简单的使用和维护?

谢谢,提前,为您的反馈!

马蒂亚斯

—更新—

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

我已经开始将共享文件放入一个“生产者”项目,并将编译文件列表导入到每个“消费者”项目中.这些项目与MSBuild联系在一起.一旦事情被确定下来,我会编辑这个问题和“图书馆计划”的答案,分享我所学到的知识.

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

解决方法

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

> Pro:如果SCM系统支持,可快速方便地进行设置.
> Pro / Con:每个消费者项目都可以独立影响编译时间.
> Con:没有官方位置,在当地的工作副本来源.

>这可能会导致混乱.

> Con:源代码更改不会反映在其他位置,直到签入并重新检索.

>为了正确验证其他项目,在签到之前,是可能的,但在对接的皇家痛苦.

Con:并不是所有的SCM系统都支持共享文件.

> Subversion最接近的功能文件夹级的svn:externals.

(编辑:重写这个以避免混淆,当然每个人都应该使用Source Control!:-))

猜你在找的Delphi相关文章