Question

We have a large SQL driven software system which has been around since Delphi 1. It uses the same original project files in all of its various projects. We’ve recently begun upgrading to Delphi XE2, and I’ve been contemplating the idea of creating NEW project files and re-adding all the source again – to make sure they get the recommended defaults of a new Delphi XE2 project.

Would anyone recommend this? And what are the risks? Obviously it’s a difficult task, re-defining version number, project names/description/company info, etc. But it’s the size of the original projects that scares me. 3 main executables plus many others, totaling in probably close to 3 million lines of code all together.

The main reason I’m thinking of doing this is because I’ve seen how new Delphi XE2 projects automatically create sub-directories per platform and release (Win32, Win64, Debug, Release, etc.). Our projects are currently a mess and I’ve been trying to clean it up.

So what would you say the risks are in this? And why or why not is this a good idea? Could there be some alternative to “Reset” the defaults?

Answer 1

Re-creating the project file shouldn’t hurt, yet it shouldn’t add anything useful either. I’d seriously question your motivation and I’d consider changing only what needs to be changed:

Our projects are currently a mess and I’ve been trying to clean it up.

Anyone that’s been around a big project probably thinks that at some point. If there truly is some “mess” somewhere, it’s in the project’s source files (PAS, DFM) not in the actual project file. Refactoring should probably go the other way around. Reorganize the source files (if needed), remove files that are proven to be redundant, and the project file will immediately reflect the new found cleanness.

Obviously it’s a difficult task, re-defining version number, project names/description/company info, etc.

That’s ALL on one page in the project’s options. I honestly doubt that’s going to be the most difficult thing you’ll need to do. You’re much more likely to discover hard-coded dependencies on 3rd party components and other in-house projects. Those will be a pain to track down, because you’ll hit ReBuild time and time again, fixing the one unit the compiler complains about.

The idea is that the project file lists the files that makes up the project and includes a minimal set of compiler options and defines. If you re-create the project file you’ll end up adding all the compiler options and defines back in, and you’ll also add every single one of the files back in, one at a time, because that list is actually coded in the uses clauses of the files that make up your project. The only files that will NOT make it back in are those that can be found on the search path, in the project’s folder and those that truly are redundant. If you want to remove redundant files, this is not the way to go. Better look into some sort of uses list analyzer.

The main reason I’m thinking of doing this is because I’ve seen how new Delphi XE2 projects automatically create sub-directories per platform and release (Win32, Win64, Debug, Release, etc.)

No need to re-create the project file for that, simply change the Output Directory and Unit Output Directory in your project’s Compiler Options to this:

.\$(Platform)\$(Config)