How to organize common divisions in modern Delphi?

Question

For more than ten years, I was intrigued by Delphi 6 and developed hundreds of thousands of lines of code in a logical (me) unit structure, where the project tends to be several hundred lines of code referring to the high-level working procedures in my "library". When I try to switch to XE5, I just cannot find a way to combine all my library units in one place in the search path, and then just use the project (and, if necessary, recompile), but dcus is turned off with the library source, and not with each individual project .

I am just starting to think that “Hello World” takes up 2.5 MB in XE5, and I cannot help but think that each library module must be separately compiled into dcus at the project level. In the "old" days, these dcus devices will sit next to the pas files and not recompile if nothing changes in the source file.

The obvious place to look is the project settings, but I cannot find the right setting to get the project to stop copies of each dcu.

I vaguely understand that multi-platform development will cause restructuring, but I cannot help but feel that there is some kind of compromise position.

There must be something big that I'm missing.

Answer 1

Starting with Delphi XE2, Delphi supports compilation for multiple platforms, as well as various layout configurations. Because of this, Delphi needs to create DCU files for each combination. For example, Win32 , Win64 and OS-X DCU files are saved in separate folders by default. Otherwise, if this were not the case, the DCU files would overwrite each other, which you should avoid (if you use different configurations / platforms).

These parameters can be changed in the project parameters in the very first section of the Delphi Compiler by changing the Unit output directory . This is the default .\$(Platform)\$(Config) , which creates a subfolder for the platform, and then another subfolder for the configuration, for example \Win32\Debug\ . Caution for Target at the very top, which is installed by default on your current platform / config. Usually you need to change it to All Configurations . If you completely clear this field of parameters, this will lead to the default behavior from older versions.

Looks like you should create a Package . This will allow you to group all your “library” units together in one place (BPL). This package can then be installed into your IDE, and if you have any components, these components can be installed in your pallet.

Or you can do without a package. All units from all these different projects should be moved to this central place, although there is one folder containing all your "libraries". Thus, it is less maintenance, and you can simply add this folder to your path to the global library.

If you put your files in a central folder and use these files from the project, the DCU files for the project and this "library" will be saved for this project. Delphi does not know that these files are a “library”, it just knows that you are using them, and since it cannot find an already compiled version of these units, it creates it in your project. If you want DCU files to be saved only once and in this central location, you will need a package.

Answer 2

First, let me thank all the respondents for this question - they all provided useful information. I experimented with various suggestions (including breaking XE5 so much that I had to reinstall), at least I studied some areas that you did not have to deal with.)

• It is important for me, but the well-known practice of bad coding is that separate projects edit shared libraries (only my own units - I did not ruin the code belonging to Delphi or to a third party). This is crucial for multiple applications to work on the same data, but in bite-sized chunks. the generic code allows me to make high-level applications available to other projects. There may be better ways (I would love to hear about them), but it worked for me for a long time.

• For a multi-platform model, the default dcu structure is required, so I will adapt to it. Share the source code, but accept multiple compilations for individual projects. JensG's good suggestion is simply to clean dcus when the project is not actively being processed. There should be a straightforward utility program.

• The transition D6 → XE5 (which will take several months for some less used areas) requires me to know which units compile successfully, so I will support one project whose function is to include all units and recompile them all. This will make it practical to map pas library files to dcu files.

• AnsiString / AnsiChar Problem ↔ String / Char is the main area of ​​migration issues. A simple change in the editing level can get the code past the compiler, but there is no guarantee that the code will work the same anyway. Particularly disturbing is the interface, which indicates calls to Windows, etc. My answer would be to compile units first, but then write test code for problem areas. It will take months - I need to do new things, as well as install old ones. I REALLY do not know if I can replace the XE5-compatible code back with Delphi 6 without another level of testing. I THINK that it should work, but it will check carefully.

• The second major migration issue is third-party code such as VCLZip. XE5 has its own zip support, but I have many places where I use VCLzip, and the conversion will not be trivial. For this particular library, it may be possible to find a source at the XE5 level and just work with it. There are other pieces of code derived from the Internet that I used, but never needed to really understand, which could cause significant problems.

Again - thanks to everyone. It was interesting 24 hours. Howard