Delphi 7 .dof and .cfg's: should I track them under version control?

Question

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?

Galloping

In what part of your .dof and .cfg files do paths to 3rd party components appear? What is your build process? I hope you are not building from IDE. – Birdwell

Yes, I'm building from IDE. BTW I'll edit my post to include these info asap. – Galloping

Answer 1

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.

Coleslaw

@Warren P: thanks for your suggestions, we finally decided to exclude .dof and .cfg from our normal scm workflow, and to move the compilation process to a server machine, with proper .dof settings. – Galloping

@Warren P: we'd like pretty much to fully move to 21st century with Delphi XE2, which we just bought some weeks ago, but one of our company's major products is still built with D7, my team can't do anything against this. We are now preparing to deliver version 3 of our product; version 3.5 is scheduled for XE2 porting. May the Force be with us. – Galloping

My employer has a shipping version in Delphi7, with many active customers, and our latest internal versions are in XE, and the move up created many problems and difficulties that took a long time to sort out. It's a big job. I understand. – Coleslaw

Answer 2

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.

Inscrutable

I thought that is the same as %PROGRAMFILES% in a batch file, which means "32 bit program files on a 32 bit system and 64 bit program files on a 64 bit system". Even the environment variable name changes to %ProgramFiles(x86)% aka $(ProgramFiles(x86)). – Coleslaw

@Warren, in a 64 bit application %PROGRAMFILES% points to the 64 bit folder, while a 32 bit application (like the IDE) sees the x86 folder. You can check this in XE2 by inspecting the built in environment variables. The %ProgramFiles(x86)% variable is only of use in a 64 bit application. – Inscrutable

@Warren, the OP claims that on 32 bit systems the path should say c:\program files\, while on 64 bit systems it should say c:\program files (x86)\. That is exactly the content of $(ProgramFiles) as seen from inside the IDE running on both OS flavors. – Inscrutable

@Warren For a 32 bit process the value of the environment variable PROGRAMFILES is C:\Program Files (x86). That's nothing do with Delphi, that's how the underlying system works. – Birdwell

@David, thanks for pointing out. The reason it works is because Delphi is a 32-bit process. After reading my stuff I realize I didn't make it clear enough. – Inscrutable

Answer 3

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.

Ceylon

And they added MSBUILD integration, which makes building from the command line MUCH easier. – Coleslaw

Answer 4

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.

Devisal