Should “Library path” point to the source files of packages?
Delphi 7 documentation says yes. But other people say no: “The “Library” path should lead to compiled files (.dcp, .dcu) and (if needed) resource files (.res, .dfm) only”.
Update:
The thing is that if you DON’T add the path to your packages in the “Library path” then every single time you create a new DPR project you have to manually collect the path to your packages (many) and enter them into the Project’s Option “Browse” box, else you will get “file xxx.dcu not found”. This doesn’t sound that nice. For years I used to add all my paths in Library and never had to manually add the paths every time I created a new project.
- My packages are universal/global (not specific to a single project but to many projects).
- I use one single computer for programming so I don’t care about sharing the code.
- I have the PAS and DCU files in the same folder.
- I don’t mind recompiling the PAS files often. Compile takes 1-2 seconds, build takes 3-4 seconds.
- Relative paths ARE OUT OF QUESTION because “Delphi (all versions) seems to change the working directory sometimes on opening files, which in turn messes up relative paths (they are relative to the working dir, not the .dpr(oj) apparently). If I notice this, I open a file (using file->Open) in the working dir, and all is fine again.”
- I use to edit most of the packages a lot in a single day.
Delphi 7 is such a mess when about setting the paths and official documentation is 0. 🙁
UPDATE:
I have done the change. It works, but it not even by far perfect (or at least elegant): How to remove duplicate resources (RES, DFM) while using Delphi with non specific Library paths?
The technique I describe below works well for us because, for whatever version of Delphi we’re using, all projects use the same version of libraries.
For example, we have a branch that is built (and still actively developed) using Delphi 6. Our trunk was migrated to Delphi 2009 over a year ago, then migrated to 2010 a couple of months ago, and will soon be migrated to Delphi XE. But all projects in the trunk will use the same version of Delphi and the same version of our libraries.
Third-party component vendors like to install the source to a shared location and then use different output folders for the compiled code. I, on the other hand, prefer to install a separate copy of each third-party library for each version of Delphi installed. If I install an updated “version 5.4” of one of my favorite component libraries, I may not want that single install to apply to every version of Delphi I’m using. So each component library is installed separately for each version of Delphi installed. (This is a pain when the library uses a “typical” Windows installer, that doesn’t want to install the same product multiple times.)
Having said all of that, our global Library path in Tools|Options points to the OUTPUT folders of all third-party libraries. This way, every new project is ready to go without any extra work, and compiling any project doesn’t recompile the standard third-party library code that doesn’t change as a project changes.
On the rare instance we need a patch (source code override) to a third-party library, those go into a separate folder and are compiled each time the project is compiled. Once the third-party releases an update with the fix included, we remove our copy of the patch.
We use third-party libraries that contain a lot of source code, such as ReportBuilder, Raize Components, the TurboPower products, etc. I see no reason to recompile all of that code any time I “Build” my project.