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).