is there something similar to c++ precompiled headers in Delphi? - delphi

Question

One feature I miss in Delphi (I hope it is at all possible) is that I cannot have Units automatically include their dependent units. This is possible in c++ headers.
For example, in c++:
dependentHeader.h:
#include "baseHeader.h"
Any headers included in baseHeader.h are available in dependentHeader.h. Another example is the precompiled header, whatever I include in the precompiled header is available to all header files in the project. This is very useful for including frequently used headers throughout a project.
Now back to Delphi:
I have a Unit called DebugService
In order to use it other units are required: DependentUnit1, DependentUnit2.
So in every Unit I use DebugService I have to manually add all the other dependent units: DependentUnit1, DependentUnit2.
What I want is just to be able to specify DebugService as a dependency and have all its dependencies come along?
So, in other words I want:
uses
DebugService;
and NOT:
uses
DebugService, DependentUnit1, DependentUnit2;
Is this at all possible?
Thank you!

Answer 1

Ironic that you would ask this, when a better question would be, "Why doesn't C++ have modules yet, in the year 2013".
Delphi's compilation units are not normally split into duplicate .h and .cpp files. You may have noticed that Delphi units have an Interface and Implementation section. This in turn becomes a true module system, compiled .DCU files differ significantly from C++/C compiler ".obj" files because just the interface area can be read, very quickly, by a compiler, when a "uses UnitX" is encountered.
Recently, CLANG/LLVM compiler developers at Apple started adding the rudiments of true module support to the latest CLANG/LLVM C and Objective-C compilers. This means that precompiled header support in XCode is no longer the preferred manner of doing things, because true modules are better than precompiled headers. You could say that a precompiled header system is like having one module, and only one module, as a shabby kludge that you are happy to have, when you cannot have the real thing, which is called Modules. You may say, you are a windows developer, what do you care about CLANG/LLVM? Just that it is evidence that the world is slowly giving up on precompilation, and moving eventually, to modules. The C++ standardization comittee, working at its current rate will certainly deliver you a working C++ standard (but not an implementation) by 2113, at the latest.
In short we might say your question might be asking, if the Horseless Carriage is going to gain features allowing it to accelerate the caching and rapid deployment of Oats to the Equine Power Units.
We don't need that here. We have a real compiler with real module support. End of story. You may notice that Modules (in clang/llvm) are faster than precompiled headers. They are also less of a source of problems, than precompiled headers which are a nearly endless source of crazy problems.

Answer 2

Pre-compiled headers don't have any semantic meaning that differs from standard headers. They are simply an optimisation to improve compilation times. Typically Delphi compilation much faster than C++ compilers and so the optimisation is not needed.
You cannot use unit A and transitively use all of unit A's dependencies. If you want to use definitions from a unit, it must be listed in the uses clause.

Answer 3

There is no equivalent to pre-compiled headers in Delphi. Adding the additional uses references is required if DebugService uses declarations from DependantUnit1 and DependentUnit2 in its own declarations of its interface section, and its declarations are then used by other units, thus they are dependant on those other units. If you can design your units to reduce interface dependencies, using dependent units only in the implementation section instead, then you won't have to include DependantUnit1 and DependantUnit2 in other units' uses clauses anymore. But I understand that is not always possible.
If you need to share code amongst multiple units, it is best to move that code to its own unit/package.

Answer 4

#include "baseHeader.h"
is equivalent to
{$I baseHeader.pas}
you can put anything you like into that file. Even the whole Interface section.
an other alternative to your problem is the use of conditional defines.
in main project file
{$DEFINE debugMyApp}
in each unit you use
use
abc
{$IFDEF debugMyApp}
, additionalUNit1
, additionalUNit2
, etc
{$ENDIF}
;