Loading Delphi designtime packages on a project base

Question

Is there a way to select designtime packages on a project bases?

Packages are very useful in large project to keep the build time acceptable, but they are a real pita in those large projects too. When one developer adds a new package, it breaks to build for all other until they install the new package on their machine. And then there is versioning of the packages ...

So has anyone a proper solution for this? (it has been bothering me for years now)

Answer 1

At my previous job I wrote a little tool to help us with versioning packages. I really should recreate that tool in my spare time and make it available. The tool was not hard to write though, so maybe you can implement something like it yourself.

Basically it worked like this:

• Subversion repo with all the packages in subfolders. Each package folder in the repo had the same subfolders: Lib (for DCUs), Source, Help (if needed)
• In the root folder of the repo sits the tool together with an XML file.
• The XML file specified all needed information for each package: which folder contained DCUs, which folder contained source, which command needed to be run for the help.
• The tool reads in the XML and displays a checklistbox of all the available packages. Installed packages (read from the BDS registry) are marked checked.
• The user can make a selection of which packages to install/uninstall.
• The tool adds/removes the necessary keys in the BDS registry. It adds the DCU/Lib folder into the search path of the IDE, it adds the source folder to the IDE browsing path, and it registers the help command with a custom IDE expert (This expert provides an extension to the default help menu to launch the help for all the installed packages)
• The tool would even check for conflicts and dependencies between packages. For example both version 3 and 4 of Raize Components were available which could not both be active at the same time. Dependencies checking was useful for in-house components that derived from TurboPower AsyncPro (lot of in-house components relied on serial communication via AsyncPro)

A possible extension would have been to be able to save/load the selection of packages and store that selection with each project so you can have only the packages loaded that are needed for a particular project.

I implemented all this when the company was moving from Delphi 5/7 to Delphi 2007. We had a lot of problems with package versioning before and wanted some way to version all the different packages.

This approach offered some nice advantages:

• When bugfixes had to be made or new versions of third-party packages were released, one person had to commit the changes to subversion. All the other devs could just do an update from subversion and have the latest version without any problems.
• When new component packages would be added to the environment, one person had to commit all the files, change the XML package list and then the other devs could do an subversion update and run the tool to integrate the package easily.
• All third-party and custom in-house components were now versioned easily.
• By including the DCUs (and other binaries) in the subversion repo, we ensured that all devs used the same compiled version. Before it was possible that different compilations used different settings which caused some components to behave differently.
• When all the other devs finally installed Delphi 2007, their packages were setup in less than 10 minutes (most of the time spent downloading everything from the subversion repo; the tool itself could install 20 packages in less than 2 seconds). Before, with the manual installation of all packages for Delphi5/7 it could take up to 2 days to get everything installed.

This wasn't just used for some in-house components alone, the repo also included some of the big component packages: Raize Components, JCL/JVCL (Using their installer instead of the tool though), DevExpress Quantum Grid 3 and 4, TurboPower AsyncPro

Answer 2

This is not easy too do. You can do it though, with the use of a custom registry hack, and a specific bds shortcut per configuration you are interested in:

To use, just create a new shortcut and modify the command line to pass e.g. -rMyAlternateBDSReg. Then after launching that once, the reg entry is created and they can configure that alternate registry all they want, deleting packages, etc, without worrying about messing up the default install.

From codegear

If you set up a configuration for each project, you can then start the appropriate shortcut for the given project. It's not automatic, but it is better than having everything there all the time.

A nice side effect is that the load times will be improved.

Answer 3

We put the source for our packages in source control along with a batchfile that rebuilds them. If there is a change in the tree for packages then we rebuild them. This doesn't address installing new packages, but there are registry hits that can take care of that, so it is possible that we could include .reg snippets maybe to handle that.