Delphi Search path vs Library Path vs Browsing Path

Question

In Delphi, I can include a folder's source code by adding it to the project Search Path, or adding it to the Library Path. The Search Path applies only to the current project, while the Library Path applies to any project opened with the IDE.

Other than that, is there any functional difference between the Search and Library paths?

My reason for asking: I have a folder X with source used by project A. When I include that folder under Project A's search path, it says it cannot find a specific file in that folder. When I include it under the Library path, then project A compiles fine.

Until now, I was always under the impression that the only difference was that one was project-specific, and the other was global.

While we're on the topic (and at the risk of making a fool of myself): What is the functional difference between "library path" and "browsing path"?

Answer 1

Excerpt from my Delphi book:

The “Library path” field

This is the path where the compiler looks for files that it needs when it compiles our project.

There are three main categories of paths that we will find here:

1. On the first lines we can see listed Delphi’s own precompiled DCUs. We will talk about precompiled DCUs soon.

These paths are added here by Delphi’s installer. Don’t touch them, or you will fuckup the whole Delphi and you will have to reinstall - unless you have a backup of the appropriate registry key, which is: KEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\21.0\Library\

2. Next, if you installed 3rd party packages/libraries using their automatic installers, you will see their paths here. Usually, only the folder containing the DCU files (not the Pas files) will be listed here. Here are some examples:

These paths are automatically added by the above-mentioned installers. If you want to use 3rd party libraries (such as LightSaber) that don’t have an automatic installer, you will have to enter their path manually, as described below (point 3).

3. Finally, if we built our own library, we would want to manually put the path to this library here.

---

The “Browsing path” field

If we Ctrl+Click in the IDE on a routine (like Application.ProcessMessages), the IDE will take us to the source code of ProcessMessages which is in:

c:\Delphi\source\vcl\Vcl.Forms.pas

How can the IDE know where to look for Vcl.Forms.pas when the “c:\Delphi\source\vcl” folder is not in Library Path? This is done by Browsing Path. If we look into the “Browsing Path” we see that the VCL folder is already there:

When the IDE cannot find an identifier (function, variable, etc) in project’s “Search path” it starts to search in “Library path”. If the identifier is also not there, the IDE looks into the Browsing Folder.

It is critical to understand that the folders listed in the “Browsing Path” are accessible to the IDE (and also to the debugger, so we can step into the source code of our libraries while debugging) but not to the compiler.

So, in “Browsing Path” we add the folders that hold units that we want to be able to see/browse with Ctrl+Click in the IDE, but we don’t want to be found by the compiler.

I think Embarcadero team screwed up a bit here. They should have used “Compiler paths” instead of “Library paths” and “IDE paths” instead of “Browsing paths”.

---

The “Debug DCU path” field

The documentation says, “Specifies the path for the Delphi-compiled units used for debugging”. What it means is that it contains the folder where the Delphi’s debug DCUs are located (see the “Precompiled DCUs” section). We should not touch this.

Usually, we will only have a single folder listed here:

---

The “Debug source path” field

“Debug source path” is a less obvious place where we can enter paths. Here we enter paths to the Pas files that we have them precompiled to speed up the general compilation speed of your project. Note that this is located under the “Embarcadero debuggers” page and not under the “Library” page:

---

The “Use debug DCUs” field

Delphi’s units are coming precompiled in two “flavors”: the debug and the release flavor. So, one might be inclined to think that when we compile our application in Debug mode, the compiler will implicitly use the debug DCUs for RTL/VCL framework. It doesn’t. The compiler will use the debug DCUs for our code, but not the debug DCUs for the RTL/VCL library.

And we can test that easily: we simply build our application in Debug mode and put a breakpoint somewhere in its source code. We will speak about breakpoints and debugging soon. We will see that we can step into our routines when we press the F7 key. But if we try to step into a Delphi routine (let’s say Application.ProcessMessages), we simply can’t. The debugger won’t go in that routine because Delphi compiled the “release” version of Vcl.Forms.pas (the unit where ProcessMessages resides) even if our app was compiled in “Debug” mode.

To force the compiler to link the “debug” version of its VCL/RTL library, we need to activate the “Use Debug DCUs” check box in “Project options”. Careful here! I said, “Project options”, not Delphi’s “Global options”:

When to activate the “Use debug DCUs”?

If “Use Debug DCUs” option is not activated, and we debug our application, we can only single step through our own code. This is what we want in the most cases, because it is our code that is buggy, not Delphi’s code. It will be quite annoying to keep stepping into Delphi’s code.

We activate “Use Debug DCUs”: • If we want to see how Delphi is working internally – for example, when we want put a break point inside ProcessMessages to see when it is executed. • If we think we have found a bug in the RTL/VCL

Note: After we activate this option, we need to rebuild our project! For some changes it is enough to compile, but for others it is not enough. I haven't spent the time to make a list about which ones need to compile and which ones need to build. So, as any lazy person, I always Build, after changing project's options.