[Delphi Library Path Vs Browsing Path
Stephanie Dejoode
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.
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.
Lets say that you have a thirdparty component that you use. You point the library path to the directory where the pre-compiled dcu-files of that component are. Your project will use these dcu-files when you compile. This is good, because it wont be recompiled every time you do a build.
But by including the compiled dcu files, you loose the possibility to debug the thirparty component. If you include the path to where the source files are in the browse path, the debugger will find the source, and allow you to step in to it.
Update: There are two different kind of search paths: Compiler search path and debugger search path. The first is there the compiler looks for files during compiling, and the second is where the debugger looks for source files during debugging.
The compiler will only find files in the Library path or the projects search path. The debugger will find identifiers in the compilers search path plus the browsing path, the debug source path for the project, and the global debug search path.
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.
I've been putting the path to the unit (.pas) file folders of our packages into the Delphi Library path but I'm beginning to wonder if this is a mistake! Take this problem for an example:
If the path to both package's unit folders are in the library path then there is the chance of me building HighLevelPackage before LowLevelPackage and HighLevelPackage will implicitedly contain LowLevelPackage's units (i think?).
I'm wondering if instead I should be putting the path to the DCUs of these packages into the Library Path. And maybe putting the path to the actual source units in the Browsing Path so we can still step into them when debugging.
Library Path Specifies search paths where compiler can find the source files for the package. The compiler can find only those files listed in the library path. If you try to build your package with a file not on the library path, you will receive a compiler error.
I'm not sure I agree with this as it means every package can see every other package's source units so if one package used another packages units and you built them out of order I believe there's potential for dependencies getting screwed up. Oh well, who am I to question Delphi Help, lol. ;)
I usually don't put any package sources into the library path at all. This is because all the 3rd party libraries a project uses go into a subdirectory (svn:external) of the project, so having them in the library path would result in the wrong sources being added to a project. Instead I add the relative paths to the project's search path.
+1 to Cesar, though I wasn't aware of a "Browsing Path" option... I'm pretty sure it wasn't there in D7. That would certainly save having to add PAS files to the Library Path in order to step through code.
I'm running into an issue where I pulled a project out of git into its own isolated folder tree and tried to build it. I'm getting compiler errors because there are hits on previously unknown conflicts in component libs I have in my system. Clearly there are some ordering differences in search paths.
Maybe a better question is ... how do you go about setting up projects so everybody can extract the source code from git and build each project, and they result in substantially equivalent EXEs? Right now I can't get this one project to even compile due to component library conflicts even though we supposedly have the same component libraries installed.
(In this particular instance, we've got an old library from D7 era that was brought forward into DX10.2 and cleaned up so it doesn't produce the tons of hints and warnings it used to. In attempting this build, I discovered that a 3rd-party component vendor has incorporated this exact same library into their own source tree, and the compiler is finding this copy rather than the older one that's isolated and installed as a component. This newly discovered code is the older version with all of the hints and warnings from D7 days -- it was never cleaned up for newer Delphi versions. It also has some errors that stop the build. I'm trying to figure out how this folder is even being included in the library search path, as it's not in MY global search paths that Delphi loads up.)
This is the Delphi global library path. The compiler can find only those files that exist on the Library path. If you try to build your package with a file that is not on the Library path, you receive a compiler error.
Specifies the directories where the Code Browsing feature of the Code Editor looks for unit files when it cannot find an identifier on the project search path or source path. The Code Editor searches for unit files used for code browsing in the following order:
I have a relatively new installation of Delphi 2007 at work, featuring
the December 2007 update. During last few days I've started noticing
that Ctrl+Click navigation doesn't work for anything that's declared
outside of project files (i.e. anything not included in the .DPR file
directly, but by project search path and global library path instead).Since this installation is only a few weeks old, I'm not really sure
whether it just started failing, or whether it never worked in the
first place.I've made sure that all source units are available to both compiler and
debugger by adding the appropriate directories to the project's search
path and the global browsing path. I've also added the same directories
to the global library path, just in case IDE expected them to be there.Sadly, it made no difference.Projects compile and build fine, and even the tooltip help works for
*all* identifiers. The Ctrl+Click and the Right-click+"Find
declaration", however, do nothing on those *same* identifiers.Needless to say, it's /a bit/ tedious having to hover over identifier,
wait for the tooltip, remember the unit name, go to the uses clause,
find it there, select "Open file at cursor", then search for identifier
with Ctrl+F, and repeat...To add insult to injury, I have a home installation of Delphi 2007,
where everything works as expected.I can't seem to find any difference in settings. I've disabled all IDE
experts, but that didn't help, either.I'm at a complete loss here, and Google seems unable to help me...What else is there beside the project library path, global library path,
and the global browsing path? What else affects the Ctrl+Click
navigation?--
Regards,
Aleksander Oven
Try to delete the projects .local files, I think the IDE caches some
identifier lookup information there and that may have become corrupted
or out of date.I have seen the same problems off and on, by the way. No rhyme or
reason, sometimes it happens, on the next start of the IDE with the
same project all works OK.
--
Peter Below (TeamB)
Don't be a vampire ( ),
use the newsgroup archives :
Hm, did you perhaps mean .identcache files?
I'll give it a try when I get back to office tomorrow morning. Thanks
for the idea!
I really wish some CodeGear dev would write a blog entry about the
inner workings of these misterious files and Delphi's symbol lookup in
general.A section of help dedicated to these kinds of semi-advanced topics would
be even better!
I also deleted .identcache files, .dsk files, and generally anything
else except .dproj, .pas and .dpr.It didn't help.Then I remembered that my projects at work are located under a directory
that is actually a NTFS reparse point (a junction) to another directory.
I immediately thought that might be the problem, as I've seen some
programs fail to recurse reparse points in the past.So I relocated the projects and tried again, but, sadly, the problem
persists.Any other ideas?--
Regards,
Aleksander Oven
Some people using Package Magician or evaluating it asked me to add some sort of search path handling. The usual scenario is that a library installed into the IDE via its setup also adjusts the global library path pointing to the necessary DCU files. Some libraries consist of quite a bunch of packages to be installed into the IDE and thus are not easy to be installed manually, so using the setup is a reasonable option.
So while the IDE lacks proper handling of design packages on a per project basis, it already supports search paths on a per project basis, rendering a similar feature inside Package Magician rather obsolete. All you have to do is to put the correct search paths into the project options and these will take precedence over those in the global library paths. As the DPROJ is usually also under version control, its content should always match the Package Manager settings.
Remark: It might be worth reading this of my answers at StackOverflow regarding the order of search paths, the problems with localized versions of Delphi and a way to workaround those.
How convenient is it to use the project search path all the time? Every time you create a new project (even for a quick test) you need to populate the path with all the paths of the components your IDE uses (and you may have 100s of them)
This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.
795a8134c1