在项目中共享Delphi源文件的最佳方法是什么?
澄清:我们想在多个Delphi项目中使用单个源文件。我们一直在使用我们的SCM工具将相同的文件放入多个文件夹中,但这不是一种超级优雅的体验,我们也在考虑迁移到不支持此功能的工具。
正如我一直在研究这个问题,我考虑了一些不同的方法,但我想知道你在做什么以及如何找到你的方法。
重要方案:
考虑:
提前感谢您的反馈!
的Mattias
<小时/> ---更新---
感谢您的反馈,通过回答,评论和投票!
我已经开始将共享文件放入一个“生产者”项目并将编译文件列表导入每个“消费者”项目。这些项目与MSBuild链接在一起。一旦事情变得更加明确,我将编辑这个问题和“图书馆计划”的答案,分享我所学到的知识。
敬请期待! (但不要屏住呼吸;你会在几分钟内窒息!:P)
答案 0 :(得分:7)
使用源代码管理系统的文件共享功能
(编辑:重新命名以避免混淆。当然,每个人都应使用源代码管理!:-))
答案 1 :(得分:3)
使用图书馆计划
答案 2 :(得分:1)
我认为不需要特殊的解决方案。在我们的项目(几个共享大量代码的应用程序)中,我们使用以下方法:
在我们的例子中,我们无法控制导入文件的列表。但是,我们可以在parted构建中控制导入包的列表。较小的包意味着更好的粒度。如果有人向单元添加依赖项,位于搜索路径中不可用的文件夹中,并且包含此单元的程序包不在使用列表中,则parted构建失败。因此,需要显式操作(修改为分区构建生成CFG文件的MSBuild脚本)来添加依赖项。
P.S。我们使用的包不是为了控制依赖,而是因为Windows非NT版本运行大型应用程序的问题。因此,依赖控制是一种副作用。 Parted构建被视为“release”,monolith - 被视为“debug”配置。 Monolith应用程序仅用于编码和调试。开发人员使用整体应用程序,并将自己的更改引入项目配置,如附加VCL调试信息,打开和关闭范围检查错误,优化等。但是,在提交到SVN后,CC尝试进行分区构建。它忽略来自存储库的CFG文件,并使用MSBuild项目的特殊任务重新创建它们。因此,我们可以确定没有引入依赖项问题(并执行其他检查)。
只要我们不需要同时使用整体和分块构建,我们每个应用程序只有一个项目。如果要在MSBuild脚本中构建两个版本,只需添加一个目标,再重新创建一次CFG并再指定一个单元输出目录。当然,如果开发人员需要这两个版本,那么拥有更多项目会更方便。
答案 3 :(得分:1)
我不确定我是否理解了问题。无论如何,当构建应用程序套件(几个项目但很多公共代码)时,我们创建这样的文件夹结构:
\Main
\Project1
\Project2
...
\CommonUnits
我们向相关项目添加公共单位(无论它与项目文件不在同一文件夹中)。此外,有时使用项目级条件定义(Project | Options | Directories / Conditionals)更容易实现小代码差异。例如,Project1将定义类似“APP_PROJECT1”的内容,然后您可以使用常用单元中的$ IFDEF来编写特定代码。
重要的是:在这种情况下,最好为整个套件安装一个源控制存储库(root当然是\ Main)。
答案 4 :(得分:0)
复制上编译强>
答案 5 :(得分:0)
复制 - 编译 - 删除强>