Would anyone recommend re-creating NEW projects and re-adding the source and why?

Question

We have a large SQL-based software system that has existed since Delphi 1. It uses the same project source files in all of its various projects. We recently started upgrading to Delphi XE2, and I pondered the idea of ​​creating new project files and re-adding the entire source - to make sure they got the recommended default values ​​for the new Delphi XE2 project.

Anyone recommend this? And what are the risks? Obviously, this is a difficult task, redefining the version number, project names / descriptions / company information, etc. But this is the size of the original projects that scare me. 3 main executable files plus many others, the total amount of which is probably about 3 million lines of code.

The main reason I think of is because I saw how new Delphi XE2 projects automatically create subdirectories for the platform and release (Win32, Win64, Debug, Release, etc.). Our projects are currently a mess, and I tried to clean it.

So, what would you say, the risks are in this? And why or why not is a good idea? Could there be some alternative "Reset" by default?

Answer 1

Re-creating the project file should not hurt, but it should also not add anything useful. I would seriously question your motivation, and I would decide to change only what needs to be changed:

Our projects are currently a mess, and I tried to clean it.

Anyone who has been around a large project probably thinks at some point. If there is a “mess” somewhere, this is not in the actual project file in the project source files (PAS, DFM). Refactoring should probably be the other way around. Reorganize the source files (if necessary), delete files that have been proven to be redundant, and the project file will immediately reflect the new found cleanliness.

Obviously, this is a difficult task, redefining the version number, project names / descriptions / company information, etc.

This is ALL on one page in the project settings. I honestly doubt that this will be the hardest thing you will need to do. You will most likely find hard-coded dependencies on third-party components and other proprietary projects. Those will be painful to track because you will hit ReBuild again and again, fixing the block that the compiler is complaining about.

The idea is that the files that make up the project are listed in the project file and includes a minimal set of compiler parameters and defines. If you re-create the project file, you will eventually add all the compiler options and define it back, and you will also add each one of the files back, one at a time, because this list is really encoded in the uses clauses of the files that make up your project . The only files that will NOT be returned are those that can be found on the search path, in the project folder and in those that are really redundant. If you want to delete redundant files, this is not the way to go. Better look at some kind of usage list parser.

The main reason I think of is because I saw how new Delphi XE2 projects automatically create subdirectories for each platform and release (Win32, Win64, Debug, Release, etc.)

No need to recreate the project file for this, just change the Output Directory and Unit Output Directory in your compiler options:

 .\$(Platform)\$(Config) 

Answer 2

One thing that you should be wary of if you are going to recreate .dpr is to make sure your units do not have hidden interdependencies that will be spring and will make your application incorrect. p>

In fact, we came across this recently. Avoiding the background of why this was done, one of my employees created a new project and again added all the current (obsolete) units of the project. After recovery, the new executable file threw access violations, and then placed a dialog box on the screen where it could not find the reason for its access.

It turns out that there are many dependencies between the elements (for example, the OnCreate form of the call methods in the datamodules) that called AV, and the irregular form was first created, which makes it the main form of the application. In the original project source, all elements are added in a specific order to ensure this. When he recreated the project, he added all the units from Explorer in his native order - in alphabetical order.

Now you can use this as an opportunity to reorganize your application to ensure that these problems and timing dependencies are not a problem and possibly turn off the creation of form machines, so the only forms that are active in your application are the ones you need at any given time. Or you can simply change the settings directly to match the new defaults if they make more sense to your project than the old ones.

Answer 3

Although this should not hurt, I’m not sure that you will win much.

The effort and time spent on such an idea seems to be a development project, and I see no use in it.

It is better to spend some time actually making a measurable improvement in your product. It can be a waste of time to try to recreate your projects.