Path for Delphi libraries

Question

Where do you guys store 3rd party (and your own) components?

Do you keep separate copies per Delphi version?

For years I've been using c:\program files\borland\delphi7\lib\, even for Delphi 2006, 2007, 2009 and 2010, like this:

c:\program files\borland\delphi7\lib\AggPas\
c:\program files\borland\delphi7\lib\DeHL\
c:\program files\borland\delphi7\lib\DevExpress\
c:\program files\borland\delphi7\lib\FastCode\
c:\program files\borland\delphi7\lib\FastMM\
c:\program files\borland\delphi7\lib\Fundamentals\
c:\program files\borland\delphi7\lib\Graphics32\
c:\program files\borland\delphi7\lib\JCL\
c:\program files\borland\delphi7\lib\JVCL\
c:\program files\borland\delphi7\lib\OmniThread\
c:\program files\borland\delphi7\lib\Raize\
c:\program files\borland\delphi7\lib\TeeChartPro\
c:\program files\borland\delphi7\lib\TurboPower\
c:\program files\borland\delphi7\lib\VirtualTreeView\
c:\program files\borland\delphi7\lib\Zeos\

However, nowadays I don't even use Delphi7 anymore (what can it do that 2010 can't?), so this path doesn't make much sense anymore. I'm about to install windows7 on my home machine, so I'm thinking on something like this:

c:\src\DelphiLib\

Any better ideas?

Answer 1

I've a directory where I do all my checkouts. Components (versioned) are just another checkout (**).

mysvndir\components                         (D7 components)
mysvndir\components2006                     (D2006 components)
mysvndir\components2009                     (D2009 components)
mysvndir\trunk                              (trunk of framework)
mysvndir\flex                               (check out of flex project that 
                                                is in a branch)

The delphi projects are all setup with relative paths. The component paths are hardcoded in delphi under options->environment.

mysvndir can be on different drives (or directory level) depending on the workstation. (most notably, on my laptop it is on D:). The ability to compile alternative checkouts (e.g. to check an older revision) is another strong motivation to keep everything relative.

This works reasonably well(*) for normal Delphi projects, but I'm now considering using hardcoded paths (or substitutes) for some projects. Mostly due to starting to use the ITE.

(*) 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) apparantly). If I notice this, I open a file (using file->Open) in the working dir, and all is fine again. I also make a habit of closing projects before opening new ones.

(**) I have a base set of designtime components that I use for all apps and don't use packages. I don't have designtime components specific to apps.

Answer 2

All my Delphi stuff is in subdirectories under C:\Delphi

Answer 3

My libraries are project specific and are stored in subdirectories under libs of the sources:

/src/project1/libs/library1
                   library2
              src/<source files of project1>
/src/project2/libs/library1
                   library2
              src/<source files of project2>

These libraries don't get added to the Delphi library path but rather to the projecet's search path, so I am sure I am using the correct library version for each project. (This is of course only for maintaining older versions of a project, current projects get updated to the latest library versions).

The libraries are stored in subversion and are linked to the projects as svn:externals.

Unfortunately Delphi does not support loading packages per project so I am stuck with either loading and unloading packages as needed or - what I do most of the time - just use the same designtime packages in the ide and rely on them to change only marginally between versions so it doesn't matter as long as I use the right sources when building the project.

Answer 4

Storing libraries in program files will cause many issues when using Vista and later. With those OSes is far better to use a separate directory outside those containing executables. But leave Delphi in a protected path, or set proper ACLs if you install it elsewhere. Remember that Windows in not secure because most users make it so. You can also set an environment variable to point to the library path, and then use it with the $() syntax within Delphi library paths. For example if you use C:\dev\lib\delphi, you can set a DLIB variable pointing there, and then use $(DLIB)\JCL in the library path. That also allows for switching among libraries simply setting the needed environment variable before launching Delphi. If library packages and directories are properly designed, there is no need to keep different copies for different Delphi versions, they will create subfolders for each version, but many aren't and could need separate copies.

Answer 5

If I install ready-to-use library - I install it into Delphi folder under Program Files (exact folder isn't important - it can be lib or sources).

This have great advantage for me (other people think about it as disadvantage though): on Vista and Win7 UAC will not allow you to mess with installed library files, in the same way as it do this for Delphi itself. You have your pas-files, you have your dcu, bpl, etc files - fine. Just use them. No need to recompile or change it.

If, however, I install library, that I plan to change - I install it into My Documents/RAD Studio folder, so it's not write-protected and I can mess with it.

Answer 6

I've always used a folder under the root such as d:\DelphiComponents with versioning (if needed) organized within each individual sub folder.

For example d:\DelphiComponents\MMTools have a Delphi6 and a Delphi7 folder. Since I do have some pretty old libraries in these folders, I avoid using spaces in the folder names.

Answer 7

I think that using sub-folders in root directory (like c:\src or c:\Delphi) isn't a good idea for security reasons. It looks like a hello from old days, when you don't really use security or proper folders structure.

You want writable folder? You have your My documents. And there is even RAD Studio subfolder. Don't like MyDocs? You have your AppData.

You want protected folder? There is All users or Program files.