Package Magician and Search Paths

Some people using Package Magician or evaluating it asked me to add some sort of search path handling. The usual scenario is that a library installed into the IDE via its setup also adjusts the global library path pointing to the necessary DCU files. Some libraries consist of quite a bunch of packages to be installed into the IDE and thus are not easy to be installed manually, so using the setup is a reasonable option.

Now assume f.i. you have access to the beta version of that library and want to test it with some of your projects, but you still need the release version for your production environment. Let’s further assume you have set up Package Magician to handle the loading and unloading of the respective packages depending on the current project. The problem now lies in the global library path still pointing to either the release DCUs of this library or the beta ones.

Let’s take one step back: Package Magician was built in the first place to handle different design time packages on a per project basis because the IDE is not capable to do this in a usable way. The settings are stored in a separate project specific file that should be under version control. I could as well have opted for storing the settings inside the DPROJ file, but that one is already cluttered with things not to be under version control and I didn’t want to complicate things further.

So while the IDE lacks proper handling of design packages on a per project basis, it already supports search paths on a per project basis, rendering a similar feature inside Package Magician rather obsolete. All you have to do is to put the correct search paths into the project options and these will take precedence over those in the global library paths. As the DPROJ is usually also under version control, its content should always match the Package Manager settings.

Let me close with a personal opinion: It might be convenient for the lazy ones of us to have all library paths set as global – I have to plead guilty for that myself in the past. New projects will compile immediately no matter which component you drop on a form or which library unit you use. On the other hand you are likely to loose oversight of which libraries your project depends on. In the last years I have formed the habit of removing all third-party entries from the global library path and add only those directly to the project that are actually needed. This will not hinder me to drop any component on a form or use any unit I want. Latest when the compiler complains when it cannot find one of those units I am reminded to think about whether it is worth to add this dependency or better use an intrinsic routine or something already used by the project. Ever so often I am able to find a built in solution in Delphi that lets me abandon some code I used in the past – often complete libraries are not required anymore at all.

Remark: It might be worth reading this of my answers at StackOverflow regarding the order of search paths, the problems with localized versions of Delphi and a way to workaround those.

About Uwe Raabe

Addicted to Pascal/Delphi since the late 70's
This entry was posted in Delphi, Programming. Bookmark the permalink.

5 Responses to Package Magician and Search Paths

  1. John says:

    How convenient is it to use the project search path all the time? Every time you create a new project (even for a quick test) you need to populate the path with all the paths of the components your IDE uses (and you may have 100s of them)

    • Uwe Raabe says:

      Well, I didn’t say to leave the global search path complete empty. It should indeed contain the standard search path to the Delphi library. I only vote for third party library to be put into the project search path only when actually needed.
      Of course, if you use a number of libraries in the majority of your projects, go ahead and put them into the global library path. That doesn’t invalidate my point made in the post. You can still put the necessary paths for each package handled by Package Magician into the project search path, leaving the global search path with the standard.
      I can still not see any need why Package Magician should fiddle around with global settings on a per project basis while it is already possible to make these settings directly in the project options.

  2. lb says:

    Does magician work in c++ builder?

    • Uwe Raabe says:

      Probably not as it is triggered especially by DPROJ files. I will put this on the TODO list for one of the future versions.

  3. John says:

    it definitely doesn’t invalidate your point. Looks like I am missing something with how to handle the library paths in the IDE. I will post a question on G+. Thanks Uwe

Comments are closed.