Delphi 7 .dof 和 .cfg：我应该在版本控制下跟踪它们吗？
我当前的 Delphi 7 项目（名为 Project1.dpr）中有两个文件（Project1.dof 和 Project1.cfg），我和我的团队无法决定将其置于版本控制之下（顺便说一句，我们使用 Mercurial）。
问题是这样的：上面的两个文件中指示了一些与程序员所在系统相关的库、组件和扩展路径。
我的团队由一些使用 32 位 Windows XP 的人和一些使用 64 位 Windows 7 的人（包括我）组成。
因此这就提出了一个问题：因为在 64 位 Windows 7 上 Delphi 扩展、组件和库位于c:\program files (x86)\... 在 32 位 XP 上，它们只是在 c:\program files\... 下，提交对这些文件的更改文件会导致破坏其他同事的项目配置。
有人对这种情况有什么建议吗？
I have in my current Delphi 7 project (named, say, Project1.dpr), two files (Project1.dof and Project1.cfg) which my team and I can't decide to put under version control (we use Mercurial btw).
The matter is this: within the two files above are indicated some library, components and extensions paths which are related to the system the programmer is on.
My team is composed of some guys using 32-bit Windows XP and some guys (me included) using 64-bit Windows 7.
So this brings up the question: since on 64-bit Windows 7 Delphi extensions, components and libraries are located under c:\program files (x86)\... and on 32-bit XP they are simply under c:\program files\..., committing changes to those files would result in breaking other colleagues' project configurations.
Does somebody have some suggestion for a situation like this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
首先：我完全同意沃伦的建议。
如果您仍想保留当前系统，可以使用
$(ProgramFiles)作为库路径的前缀。这应该适用于两种操作系统版本。First of all: I fully agree with Warrens suggestions.
If you still want to stay with your current system, you can use
$(ProgramFiles)as a prefix for the library pathes. This should work on both OS flavours.如果您继续使用 Delphi 7，或者即使您不是，我建议您签入 .DOF 文件，但您也考虑不要依赖它们进行最终构建。 更新：OP 决定不签入 .DOF 文件，并使用最终构建器。
要求 64 位用户不要签入他们的 .DOF 更改也很容易。
即使他们有时忘记他们不应该进行“本地黑客”，也很容易制作一个小型实用程序来读取和修复本地案例的 .DOF 文件。每次从其他人的存储库中提取更改时都运行它。
第二个绝妙的想法是签入 .dofdefault 文件，并让 Build.Bat 文件将 project.dofdefault 复制到 project.def（如果它不存在）。问题解决了。
对于最终构建，并防止“构建因愚蠢的原因而中断”，我建议您查看 Final Builder，并将最终构建器脚本签入版本控制，并且仅发布给已通过 Final Builder 的客户构建。这样您就不必担心向客户发送您无法解释的神秘构建。
例如，您当前如何将精确的 Mercurial 变更集修订版（md5 十六进制值）与包含它的代码以及用于构建它的选项关联起来？
更明智的想法是放弃已有 10 多年历史的 Delphi 7，并考虑坚定地迈入 21 世纪。
If you're staying on Delphi 7, or even if you're not, I suggest that you check in your .DOF files, but that you also consider NOT relying on them for your final builds. Update: the OP decided not to check in .DOF files, and use final builder.
It is also trivially easy to ask your 64 bit people NOT TO CHECK IN THEIR .DOF CHANGES.
Even if they do sometimes forget that they should not commit "local hacks", It is easy enough to make a small utility to read and fix your .DOF files for your local case. Run it each time you pull changes from other peoples repositories.
Second brilliant idea is to check in a .dofdefault file, and have your Build.Bat file copy project.dofdefault to project.def if it does not exist. Problem solved.
For final builds, and to keep your "builds from breaking for stupid reasons", I suggest you look at Final Builder, and that you check your final builder scripts in to version control, and only release to customer builds that have been through Final Builder. That way you won't have to worry about sending your customers mystery builds that you cannot account for.
How for example do you currently associate exact mercurial changeset revisions (md5 hex values) with the code that contained it and the options used to build it?
An even smarter idea would be to drop Delphi 7, which is now over 10 years old, and consider moving solidly into the 21st century.
您可以使用某种路径重定向（例如 subst 或硬链接）来整合不同的安装。解决此问题后，我建议检查 dof 文件并使用例如。 Dof2cfg 生成用于命令行构建的 cfg 文件。
You could use some kind of path redirection like subst or hardlinks to consolidate the different installation. After this issue has been resolved, I suggest checking in the dof files and using eg. Dof2cfg to generate the cfg files for commandline builds.
我同意 Warren 升级到较新版本的 Delphi 的建议。过去十年中添加了许多真正有用的功能。您可能认为没有它们也能过得很好，但一旦开始使用它们，您就会开始想知道为什么等了这么久。
话虽如此，如果您无法升级，我建议将第三方组件从 Program Files 复制到项目树的子文件夹中。我在 Delphi 6 项目中做到了这一点，通过这样做，我发现并非每个人都使用相同版本的组件。
是否将 .dof 和 .cfg 包含在版本控制下是一个判断调用。如果您在发布版本中依赖它们，那么它们可能应该受到版本控制。它们可以包含正确编译所需的编译器设置和条件。所有开发人员在自己的机器上工作时都使用正确的设置也是有益的。
如果您的构建过程从命令行设置这些，那么这没什么大不了的。
巧合的是，Delphi 的更高版本通过将两者替换为可以包含多个配置的单个文件来解决此问题。他们还引入了一项称为选项集的功能，该功能可以链接到多个项目，以便所有项目都使用相同的设置。
I agree with Warren's suggestion to upgrade to a newer version of Delphi. There are so many really useful features that have been added over the past decade. You may think you've got along fine without them but once you start to use them you'll start wondering why you waited so long.
That being said, if you're not in a position to upgrade I would suggest copying the third party components out of Program Files and into a subfolder of the project tree. I did this with a Delphi 6 project and by doing so I discovered that not everyone was using the same version of the components.
Whether to include the .dof and .cfg under version control is a judgement call. If you rely on them for your release builds then they should probably be under version control. They can contain compiler settings and conditionals that are necessary for proper compilation. It's also beneficial that all the developers are using the correct settings when they're working on their own machines.
If your build process sets these from the command line then it's not as big a deal.
Coincidentally, later versions of Delphi solve this problem by replacing the two with a single file that can contain multiple configurations. They also introduced a feature called option sets that can be linked into multiple projects so all your projects use the same settings.