Adding files to the DPR file vs project paths in Delphi 2010

Question

We are just migrating from D7 to D2010 and are having a debate about cleaning up the project paths. We have a number of directories with a large number of Pas files that are

Answer 1

Reasons to not include all files in the project:

• less time to open/close a project (forms and datamodules need extra time)
• faster file refactorings (renaming/moving of files and directories does not require to edit all projects)
• easier to find the units which are the core requirements and the entry point location for the application logic (uses MyInterfaces, MyTypes, MymMainUnit;)

And this QC entry:

Report No: 77687 (RAID: 273031)
Status: Open Editing in the .dpr source gets slower with more units in the project http://qc.embarcadero.com/wc/qcmain.aspx?d=77687

Update: Now I know that there are many ways to open the project file :) - But my point is that in a dpr with 500 unit references, it is hard to find the 'important' (or 'main') units, which are the starting point to drill down into the source - and it is easier to investigate code if it is a 'lightweight' project file which contains only the necessary unit references.

Answer 2

I'm in favor of separating "library units" from "project units" and keeping all "library units" in the search path, with all the "project units" in the project file. Here's why:

• Our line-of-business projects are large, almost million-LOC type of projects, but besides those there are literally hundreds of smaller projects for all sorts of tiny little things. Having the "library units" available on the search path makes it really easy to just use those units without adding them to the project: One less step that adds up!
• Using the search path makes moving PAS files around easier. This matters allot to me since I'm in the process of re-organizing our whole "build environment" to make better use of version control systems.
• When you change one of the shared units and it becomes dependent on yet an other shared unit, you don't need to updates lots of projects, they just work.
• I'd never consider adding third-party components (or VCL components) to my project, so why add my "library units" to the project? We need to draw the line somewhere, because if we'd add absolutely all files to the project hoping for faster compile times we'd end up with unmanageably large projects!
• Delphi automatically changes the name of the files in it's DPR file to be relative file names. Because of this you can't really move your project from it's current position. Now try "branching" and keeping two copies of the project alive at the same time, on the same machine (a "release" and a "work-in-progress"). (this is me tring preparing my build enviroment for GIT, with the sole purpose of being able to BRANCH).

For reference, my "library units" are those units that are used in unrelated projects (think: components and utilities).

Answer 3

The comments about speeding up Insights got me intrigued and I will give that a try but so far I never included shared units in the projects that used them. Instead I created packages for each library and added them to the project group (mostly for organizational purposes only, i.e. I never actually compile them as runtime packages). I found this easier to manage (especially with all the recent improvements in the project manager) than having all files in one project as the folder hierarchies inside the individual (package-)projects won't be as deep and especially there's no ".."-level that way.

Answer 4

I would argue in favor of including all files that the project uses in the project itself. This will improve performance of the "Insights" by ensuring that used units are part of the project. In addition, this will enable you to more easily manage your code inside the Project Manager. Having large complicated paths is fragile and can be hard to manage.

Answer 5

Having all your units explicitly in the dpr immensely improves compilation time, code completion, error insight and general navigation.
It does not prevent you from keeping your files organized in folders and sub-folders, but just don't rely on the different paths to find them.
On a big project with millions LOC, it makes a huge difference.