Pros and cons of explicitly adding your unit names to Delphi's project source [duplicate]

Question

I've been using Delphi for years and years and each of my projects is compiled from source into the exe - no packages etc. If 'MyUnitA.pas' is used anywhere, it is simply declared in the interface or implementation section of another unit that requires it. This all works fine everywhere and means that in my project source (dpr) there are only frame definitions (which seem to be needed there else they dont show up in the frame list) and the 'odd' definition of a unit that must be called very early eg madExcept, FastMM etc.

I notice that XE baulks a bit sometimes at resolving stuff in the dpr until you actually compile it. In addition, when working with packages its a warning if stuff has to be implicitly pulled in without having been explicitly added to the package. This got me wondering whether we should be diligently adding ALL of our used units to our dpr (like the package definition) or right-click project and 'Add to project'. What do you do?

Answer 1

I personally have my search path blank and include all units in my .dpr files. The main advantages of this as I see it:

• I know precisely which files are included in my project.
• View Units (Ctrl+F12), View Forms (Shift+F12) offer all units and forms in the project.

I don't really see any significant disadvantages to this approach. Yes you have to add files to the .dpr file when you include a new 3rd party component, but in my experience that doesn't happen all that often for it to be a big burden.

Answer 2

(Test made on Delphi Xe3 Enterprise)
1 000 000 lines project, 1000 classes, 300 units

• First approach :
  • Search path contains only vcl sources paths
  • All files declared in project file with pathnames (around 300 files)
  • I had lots of troubles :
    • The Delphi Ide was hanging permanently, with "100% cpu" in the task manager
    • Lots of underlined code , mostly "identifiers not found"
    • Ctrl+Enter on symbols was not working most of the time
    • Project file very hard to edit, had to wait few seconds after each key stroke
      
      
• Second approach :
  • All search paths in project options (~50 paths)
  • All files declared in project file without any pathnames (around 300 files)
  • Results :
    • No more hangings in Delphi Ide
    • No more underlined identifiers in code
    • Project file much more responsive
    • Faster compile time (~ 10-15%)
    • My mother in law left the house
  • Cons :
    • "Find in files" for project file, unusable, I had to use the "Search in directories"
      options. But it will also scan files not from my project.
      For me it's not a big deal

Answer 3

I am with David on this one. We/I do exactly the same.

Dependency control is the main benefit. Explicitness in unit use has big advantages. I am never in doubt where the source for a project is coming from.

Another benefit is that we as a team we are never dependent upon search paths in the IDE. All our machines have empty search paths, only items in the debug search path if we are working on getting a control to do our bidding. We only add controls to our IDE when working on the GUI (which is a large in itself, but actually a small part of our software and we use mainly controls that ship with Delphi). And I often de-install them afterwards. Big advantage: when I need to work on a very old version, I can simply pull it from Perforce and build it with the right Delphi compiler. Everything else is taken care of in the dproj (or dof as we can still compile the versions that were based on D5).

Not relying on search paths in the IDE also means our build server doesn't need to be configured with any search paths. We have a utility that keeps the dproj's in line with the configured third party library versions for a version of our software. And we have a utility that creates a cfg file from the dproj/dof. This way, we can build each and every version of our software that is still in use anywhere in the world, regardless of the compiler and third party component versions it needs. And we can do it without changing a single thing in the build server's setup. In fact we build all "active" releases every night if a change was committed to its Perforce branch and don't even think about it.