在我的Delphi 7项目（例如Project1.dpr）中，有两个文件（Project1.dof和Project1.cfg），我和我的团队不能决定将它们放入版本控制（我们使用Mercurial）。问题在于：上述两个文件中指定了一些库、组件和扩展路径，这些路径与程序员所在的系统相关。我团队由一些使用32位Windows XP的人和一些使用64位Windows 7的人组成。这就引出了一个问题：由于在64位Windows 7上，Delphi扩展、组件和库位于下，在32位XP上它们只是位于下，将更改提交到这些文件将导致其他同事的项目配置被破坏。有人对这种情况有建议吗？
Delphi 7的.dof和.cfg文件：我应该在版本控制下跟踪它们吗？
5
- Federico Zancan
2
1你的 .dof 和 .cfg 文件的哪个部分包含第三方组件的路径？你的构建过程是什么？希望你不是从集成开发环境 (IDE) 进行构建。 - David Heffernan
1是的，我正在使用集成开发环境进行构建。顺便说一句，我会尽快编辑我的帖子以包含这些信息。 - Federico Zancan
4个回答
7
首先：我完全同意Warren的建议。
如果你仍然想要保留你当前的系统，你可以使用$(ProgramFiles)作为库路径的前缀。这应该适用于两种操作系统。
- Uwe Raabe
5
我认为在批处理文件中，这与%PROGRAMFILES%相同，意思是“32位系统上的32位程序文件和64位系统上的64位程序文件”。即使环境变量名称更改为%ProgramFiles（x86）%，也称为$（ProgramFiles（x86））。 - Warren P
@Warren，在64位应用程序中，%PROGRAMFILES%指向64位文件夹，而32位应用程序（如IDE）则看到x86文件夹。您可以通过检查XE2中的内置环境变量来进行检查。%ProgramFiles(x86)%变量仅在64位应用程序中有用。 - Uwe Raabe
@Warren，原帖作者声称在32位系统上，路径应该写成c:\program files\，而在64位系统上则应该写成c:\program files (x86)\。这正是在两种操作系统下运行的IDE中看到的 $(ProgramFiles) 的内容。 - Uwe Raabe
@Warren 对于32位进程，环境变量
PROGRAMFILES的值为C:\Program Files (x86)。这与Delphi无关，这是底层系统的工作方式。 - David Heffernan1@David，感谢你指出。它能够工作的原因是因为Delphi是一个32位进程。在阅读我的内容后，我意识到我没有表述清楚。 - Uwe Raabe
4
如果您使用Delphi 7，或者即使您不使用它，我建议您检查您的.DOF文件，但也考虑不依赖它们进行最终构建。更新：OP决定不检查.DOF文件，并使用Final Builder。
另外，向您的64位开发人员要求他们不要检入他们的.DOF更改非常容易。
即使他们有时会忘记不提交“本地修改”，为您的本地情况编写一个小型工具来读取和修复您的.DOF文件也很容易。每次从其他人的存储库拉取更改时运行它。
第二个绝妙的想法是检入一个dofdefault文件，并让您的Build.Bat文件将project.dofdefault复制到project.def（如果不存在）。问题解决了。
对于最终构建，并为了避免因愚蠢原因而导致“构建失败”，我建议您查看Final Builder，并将您的Final Builder脚本检入版本控制，仅发布通过Final Builder构建的客户端构建。这样，您就不必担心发送给客户端无法解释的神秘构建。
例如，您目前如何将确切的Mercurial变更集修订（MD5十六进制值）与包含它和用于构建它的选项相关联？
更聪明的想法是放弃已经过去10年的Delphi 7，并考虑坚实地迈入21世纪。
第二个绝妙的想法是检入一个dofdefault文件，并让您的Build.Bat文件将project.dofdefault复制到project.def（如果不存在）。问题解决了。
对于最终构建，并为了避免因愚蠢原因而导致“构建失败”，我建议您查看Final Builder，并将您的Final Builder脚本检入版本控制，仅发布通过Final Builder构建的客户端构建。这样，您就不必担心发送给客户端无法解释的神秘构建。
例如，您目前如何将确切的Mercurial变更集修订（MD5十六进制值）与包含它和用于构建它的选项相关联？
更聪明的想法是放弃已经过去10年的Delphi 7，并考虑坚实地迈入21世纪。
- Warren P
3
@Warren P：感谢您的建议，我们最终决定将 .dof 和 .cfg 从我们的正常 scm 工作流程中排除，并将编译过程移至服务器机器上，使用适当的 .dof 设置。 - Federico Zancan
@Warren P：我们希望尽快使用Delphi XE2步入 21世纪，我们几周前刚刚购买了它，但我们公司的主要产品之一仍在使用D7构建，我的团队对此无能为力。我们现在正在准备交付我们产品的第3版；第3.5版计划移植到XE2。愿原力与我们同在。 - Federico Zancan
我的雇主在Delphi7中有一个运送版本，有许多活跃的客户，我们最新的内部版本是XE，升级带来了许多问题和困难，需要很长时间来解决。这是一项艰巨的工作。我理解。 - Warren P
0
我同意Warren的建议，升级到更新的Delphi版本。在过去十年中，已经添加了许多非常有用的功能。你可能认为没有它们也能很好地工作，但一旦开始使用它们，你会开始想知道为什么等了这么久。
话虽如此，如果你没有升级的条件，我建议将第三方组件从Program Files复制到项目树的子文件夹中。我曾在一个Delphi 6项目中这样做，通过这样做，我发现并不是每个人都在使用相同版本的组件。
是否将.dof和.cfg包含在版本控制下是一个判断性的问题。如果你依赖它们进行发布构建，那么它们应该被纳入版本控制。它们可以包含编译器设置和条件语句，这些对于正确编译是必要的。当开发人员在自己的机器上工作时，使用正确的设置也是有益的。
如果你的构建过程从命令行设置这些内容，那么这不是一个大问题。
巧合的是，Delphi的后续版本通过用一个单一文件替换这两个文件来解决了这个问题，该文件可以包含多个配置。他们还引入了一个名为“选项集”的功能，可以链接到多个项目中，以便所有项目使用相同的设置。
- Kenneth Cochran
1
他们还添加了MSBUILD集成，这使得从命令行构建变得更加容易。 - Warren P
0
您可以使用某种路径重定向，例如subst或hardlinks来合并不同的安装。解决此问题后，建议检入dof文件，并使用例如Dof2cfg生成命令行构建的cfg文件。
- dummzeuch
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接