In Delphi do you use include paths or explicity include all required files?

Question

Looking at our codebase some code is included in a project explicitly and is pulled in from the search path. Does anyone have an opinion as to which is best practise and why?

Update:

I thought I would clarify my question. All our paths are relatives, so we can have multiple branches that all refer to code within their branches. So I'm not asking about relative paths, but whether units should be in the .dpr or picked up using the search path, which is why the previously asked questions don't quite answer my needs. Thanks to everyone

Answer 1

i have a very basic way of determining this ... if the code is specific to the project (not used elsewhere) i include it explicitly. all shared code gets pulled from the library path.

best regards, don

Answer 2

The shared code vs specific code is a good rule.

I use VSSConnextion a lot, so files that I usually need to check out/in together, naturally belongs to the same project.

Answer 3

I don't think I can count the number of times I've helped someone who discovered that the compiler was finding a duplicate copy of a unit somewhere on their search path where they did not expect to find it. They couldn't understand why they were changing their code in the editor (on a copy of the units not found in the search path) and not seeing any change in the behavior of the application. Explicitly including the unit and not setting a search path means there can only be one copy of the unit found by the compiler.

Answer 4

• my libraries are in SVN, and I usually check them out for (branch them into) a project at ../libraries relative to the project. This keeps the scope of the includes dirs small and to the point.

• In the real source (.pas), paths are totally forbidden.

• I hate poluting source with hardcoded paths, so I usually have only a few units in the project, always with relative paths. Not the VSS w:\ drive substitutes hack please! Typically these are the units that pull in framework parts or are needed due to visual inheritance or form initialization.

• Unfortunately, relative paths can be dangerous with Delphi, because they are relative to the working directory, which can change according to Delphi dialogs (e.g. Open). The solution is simple, have an include file with an unique name in the main project.

Answer 5

After upgrading Delphi twice and moving my project to new computers twice, I've learned that hard-coded paths are evil because root directories tend to change. Doubly so if you're working on a shared project.

Answer 6

This has been covered here before:

• In Delphi, should I add shared units to my projects, to a shared package, or neither?
• What is the best way to share Delphi source files among projects?

My answer to the first question is also my answer to your question.

Answer 7

Hi,

I had the same problem. The blue-dots where not showing up in the gutter.

Simple solution (one of):

Menu > Project > Compiler > Build Configuration... set to DEBUG instead of release.

Delphi 2007

PS: well, I thought I was done coding. Someone had requested a new feature. :)