我目前的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\...下，提交对这些文件的更改会导致打破其他同事的项目配置。
有人对这种情况有什么建议吗？
答案 0 :(得分：5)
首先：我完全同意Warrens的建议。
如果您仍想使用当前系统，可以使用$(ProgramFiles)作为库路径的前缀。这应该适用于两种操作系统风格。
答案 1 :(得分：2)
如果您继续使用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世纪。
答案 2 :(得分：0)
我同意Warren建议升级到更新版本的Delphi。过去十年中添加了许多非常有用的功能。如果没有他们，你可能会认为你已经相处得很好但是一旦你开始使用它们，你就会开始想知道为什么你等了这么久。
话虽如此，如果您无法升级，我建议将第三方组件从Program Files复制到项目树的子文件夹中。我使用Delphi 6项目完成了这项工作，通过这样做，我发现不是每个人都使用相同版本的组件。
是否在版本控制下包含.dof和.cfg是判断调用。如果您依赖它们来发布版本，那么它们可能应该受版本控制。它们可以包含正确编译所必需的编译器设置和条件。所有开发人员在他们自己的机器上工作时都使用正确的设置也是有益的。
如果您的构建过程从命令行设置这些，那么它就没那么大了。
巧合的是，后来的Delphi版本通过将两个文件替换为可包含多个配置的单个文件来解决此问题。他们还引入了一个名为选项集的功能，可以链接到多个项目中，因此所有项目都使用相同的设置。
答案 3 :(得分：0)
您可以使用某种路径重定向（如subst或hardlink）来合并不同的安装。此问题解决后，我建议检查自由文件并使用例如。 Dof2cfg为命令行构建生成cfg文件。