Should “Library path” point to the source files of packages?

9
votes

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?

6
delphi
If your packages are "global" put them in the library path. If to put source .pas to it's up to you, and depends on how you manage and use those packages, if you edit and compile them separately or not. Remember that if you don't use run-time packages, the compiled applications doesn't take care if a dcu is from a package or not - the linker will simply add the needed code to the executable, and the compiler will compile any .pas it needs to, if it can find it. – user160694

6 Answers

4
votes

The OP said in a comment:

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"

Not really. You need to create a Default Project Option. To make that, load Delphi (I'm talking of D2010 here, but same feature is available in, at least, D7) and make sure there is no loaded project in IDE.

After that, open a file (any file) and go to Project/Default Options/Delphi (or C++ Builder, you'll have the choice of personality). That will open a base Project Options screen. Configure it until you're happy and press OK.

Make a new project with File/New/VCL Forms Application and see your default settings applied.

EDIT: Since XE2, the Default Project was substituted by the Option Sets.

Help links: See http://docwiki.embarcadero.com/RADStudio/en/IDE_Changes_for_XE2#Default_Checkbox_Removed_from_Project_Options_Pages http://docwiki.embarcadero.com/RADStudio/en/Option_Sets_-

_Creating,_Applying,_Editing,_and_Deleting - See more at: http://codeverge.com/embarcadero.delphi.ide/project-options-default-xe2/1058015#sthash.oovBcggS.dpuf

7
votes

Where you point your library path is not half as important as where you point the output paths for the compiled files, both dcu/dcp files and exe/bpl files.

Every project should have its own output paths. If you do that, then even when you point your library path to the source files, the binaries will be in a project specific folder and therefore can never interfere with other projects.

Be careful using the global (environment options) library path. Mine is actually entirely empty. Not even the standard Delphi folders like $(BDS)\Lib are in there. Why? Because it ensures that each project needs to make its dependencies on libraries explicit in the dproj. And that means that you can load and build projects needing different versions of the same library without getting errors because your environment paths is pointing to a different version of the library than the version your project needs. Which also helps greatly when debugging because the debugger will always use the version your project says it needs, instead of what the global environment path happens to be pointing to.

If any of your libaries have visual components, you still don't need them on the global environment paths. You only need to make sure that the IDE uses the bpl's from the version that you use most. It really doesn't matter whether that is an old one or not (apart from the fact that it may cause changes to the contents of dfm's, but source version control should help with that). You only need the bpl's in the IDE so that it won't barf at you when you load a form. In fact my IDE's usually don't have any third party components installed (even though the projects use them), but then I do not do much dfm work and when I need to change code in a form's pas file I just tell the IDE to ignore all errors (but keep the references! in the form's unit) and revert any changes to the dfm's upon submit.

Oh, and I always compile from source. That way if I get a patch for a single file in a library, I do not have to go through an entire install process, I don't even have to re-compile the components packages. I can simply put the updated source file in the proper folder and continue like nothing has happened.

Also, I do use relative paths in all of my projects. I know some people have suffered with that, but I have never encountered a problem. Possibly because I never open any files by double clicking in the Windows Explorer, but always from within the IDE or possibly by drag-n-drop from the Explorer to view a (previous version of) file without making it part of a project. Relative paths make it loads and loads easier to make copies of a project, have any number of workspaces (Perforce), and switching between them without having to "fix" the paths in the dpr.

All of the above are practices I have picked up working with many different projects, regularly having to change back and forth between versions of our own code, which often involves switching between library versions as well.

2
votes

I suggest to use the "global" library path to point only to your "global" libraries. If .dcu are find before .pas, they will be used without recompiling the source code. Unless you modify your library source code often, I'd avoid it, and I would not "pollute" it with application-specific code. IMHO application-specific dcu should not be put in the "global" library path. You can easily use the "Unit output directory" to store dcu in a common directory per application

2
votes

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.

1
votes

I say no, because it is quicker to compile the application as the dcus are already compiled.

0
votes

Though the answers provided here are definitively good and correct (everybody receives a vote up), after experimenting a bit I decided to keep my previous (KISS) set up. It worked for years and it will work for many more. I know, it trades speed (recompiling the source code) for stability but it keeps the "paths, libraries, source, browsing and output folders" madness at bay. I just don't have to worry about settings paths anymore (except first time when I install Delphi but this can be automated) or to quit current DPR Delphi project and load a DPK library and compile it every time I add changes to it.