2

Coming from a .NET background, now working with Delphi. In .NET, I used to have a separate library project with many classes seperated into distinct files. When I compiled this project, I got a single DLL file.

However, I am not able to do that in Delphi. I have many classes, each in their own file with their own unit name (I did not find a way to have multiple files with the same unit name). When I compile my project, I have one DCU file (I believe this is the equivalent of a .NET DLL?) for each unit in my project.

The problem is that I don't want to have that many files! I would like to have only one DCU file for all of my classes that are in distinct units. Is there a way to achieve what I want to do? How do you deal with these DCUs?

marco-fiset
  • 1,933
  • 1
  • 19
  • 31
  • Don't mind dcus. Hover over the 'dcu' tag on your question to find out what it is. – Sertac Akyuz Nov 08 '12 at 20:38
  • So you're saying these files are useless? What will happen when I want to use my custom component in another project? I thought I needed that dcu file for that. – marco-fiset Nov 08 '12 at 20:40
  • They're not useless, the compiler needs/produces them. You install your component into a *package* ([link](http://docwiki.embarcadero.com/RADStudio/XE3/en/Introduction_to_component_creation_Index)). – Sertac Akyuz Nov 08 '12 at 20:42
  • Then my team must be doing something wrong... We maintain a huge list of DCU files in a specific folder in SVN so we can use them in multiple projects... – marco-fiset Nov 08 '12 at 20:50
  • 1
    As long as the source file exists, the existence of dcus only help reduce compile time. – Sertac Akyuz Nov 08 '12 at 20:55
  • You don't store dcu's in source control. The sources are all you need. A dcu is just an intermediate file. It is true that you have one dcu per unit. That's because they are Delphi Compiled *Units*. – GolezTrol Nov 08 '12 at 21:12
  • 1
    Yep, your team is almost certainly doing it wrong. – David Heffernan Nov 08 '12 at 22:25
  • While I wish there was a true equivalent of .LIB files in Delphi, there isn't. DCP files are close, but no cigar. – Warren P Nov 09 '12 at 13:26

2 Answers2

14

.DCU (Delphi Compiled Unit) files are binary files that are used between compiling source (text) and linking the executable. They're created by the compiler, joined together in memory, combined with the startup code and put into an actual executable (.EXE/.DLL/.BPL) by the linker.

.DCU files are not .DLL (Dynamic Link Library) files, although Delphi can combine one or more .dcu file and link to a .DLL.

The number of .dcu files is meaningless most of the time; it's the .pas source files you need to be concerned about, and there is one of them for each source unit you create. They're re-created as needed if the source file is changed, or used in their compiled state if the source isn't changed for link speed. There is always one .dcu file per .pas file in your uses clause, plus one for your own source being compiled.

When you install a component into the Component Palette in the IDE, the .dcu is placed in a .BPL (Borland Package Library), which is a special type of DLL; that BPL, or package, file is then loaded as executing code into the IDE. This is how a button is visually displayed on a form at designtime; the code executing in the BPL actually creates a button and allows it to be displayed and manipulated in the Form Editor.

When you build an executable (and don't use runtime packages), the DCU file is linked into your application, and once the executable (.EXE) file is created neither the original .pas file or the .dcu is needed any longer. (Until, that is, you need to make changes to the executable, in which case the .pas file is modified, the compiler creates a new .dcu, and the linker combines them to create a new .exe.)

Ken White
  • 123,280
  • 14
  • 225
  • 444
  • Ok so I guess I will just live with it and ignore these files. – marco-fiset Nov 08 '12 at 20:58
  • If you purchase third-party components without source code, you often get dcu files. Remember that they usually are not useful across compiler versions, hence never put yourself into that situation. – LU RD Nov 08 '12 at 21:01
  • If you have the source, you don't need to check your .DCU files into SVN, BTW. Just check the source files in; checking them out and recompiling them will create the .DCU again, and versioning text source files is much easier (and occupies less space in the repo). If you save the .dpr and .dproj files in SVN as well, it stores the compiler settings so the .dcu can be regenerated with exactly the same settings. If you have third-party components w/o source, you have to save the DCUs, but you should never allow that to happen, as @LURD said in his comment above. – Ken White Nov 08 '12 at 21:03
2

.DCU files are intermediate files used during the development process.

.DCU files are not shipped with the final executable .EXE file

Yes, its posible to build a .DLL with Delphi and make a (Delphi-made) .EXE use it. A regular C/C++ .EXE can also use a Delphi .DLL if certain conventions are followed.

If you want to ship a collection of procedures/classes to a library, a .DLL or (a more Delphi native) .BPL can be made.

Every time a .PAS file is modified and recompiled it's correspondant .DCU file is also rebuild.

In certain development environments, .DCU files are supplied to the developers instead of the source .PAS files, when they don't want to diclose the source code.

Daniel Luyo
  • 1,326
  • 13
  • 19