Search code examples
delphidelphi-7delphi-2007

Delphi 2007 project library path

I have a Delphi 2007 project that uses several non-visual libraries (such as OmniXML, Synapse, some classes from TntUnicode) distributed as source code (.pas files).

I can add their paths in IDE to Tools -> Options -> Environment -> Delphi -> Library Win32 -> Library path but it doesn't look like a good way because these paths need to be set on each computer and all projects have to use the same library version.

Is there any way to add them to the project instead? As I understand it is possible in newer Delphi versions in Project Options How can I add a library path to a delphi project? but in 2007 I don't see such option.

I found only Search path in Directories/Conditionals, but it is separate for Release/Debug config and I don't know what macros work here except ${BDS}. Also I am not sure if it was intended for such use. Maybe there is a better option?

enter image description here

Solution

  • I prefer to have NO extra LIBRARY PATHS in Tools Options, in every Delphi version, and to have each project have its own search path.

    1. I prefer to have my settings exist and be the same for all build configurations. To do this, I make sure that I use the root nodes. This is unfortunately not as straightforward in Delphi 2007 since you have a Build = Debug setting and Build = Release setting, and if I remember correctly, there is no ROOT node in Delphi 2007.

    2. For you, in Delphi 2007, you may have to pay special attention to keeping the values in the debug and the release branch the SAME manually as I believe you can't do this automatically in Delphi 2007.

    3. To answer your question there is no need for a full path and generally no need to use $(PROJECTDIR). There is also no need for a full path. You need to use relative paths, like this: ..\Lib\Dir1;..\Lib\Dir2;..\Lib\Dir3 and so on. My goal for using relative paths is to satisfy the desire to check out code and build it anywhere. Code which can only be built when checked out to a certain directory (C:\YOURAPP) is sloppy, dare I say downright lazy, as well as impractical, and also so sadly common that you might think it was a best practice. Such sloppy no-effort codebases prevent proper continuous integration practices, prevents having multiple working copies that are at different branches or major versions, and so on, and is often worked around by keeping all the code barely building in some kind of virtual machine. Nobody even knows how to set their code up, so they shove it in a VM and let the mess moulder.

    4. When you absolutely CAN NOT use relative paths such as when you don't know where the other stuff is, you should set your OWN in house root folder variable, if your company was called ACME, I would call it ACMEROOT, and I would set it up myself. At my current company we have such a root variable we call it PS because our product's initial capitals are P and S. Then we use $(PS) similar to the way you see $(BDS) used in the library path.

    5. Sometimes I find it useful to have an external tool that I have written that will set up the environment variables for me, directly writing to the IDE the environment variables that I want, and I have a practice of checking out code from version control and running this tool to set up my environment. It so happens I can now check the code onto a fresh computer and run it without any manual effort to set up packages, install components, configure library paths, or projects, and everything just builds. Unfortunately the IDE does not provide everything you need for such a practice, but there are a variety of third party tools that can provide you with a portable clean easy to build codebase.