Should "Library path" point to the source files of packages?

Question

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?

Answer 1

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.

Answer 2

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