3.3. Coordinating Software Builds between Multiple Developers

To facilitate the work on large systems by distributing compiling and linking time to several developers, Elego ComPact offers the concept of package pools. Package pools contain one or more concrete versions of software packages, but only those elements that are needed for the building of other packages. For C, C++, and other compiled-language packages these are usually archives of object code files and the corresponding interface definitions or header files.

By default, ComPact distinguishes three different package pools for every developer: the local package pool, which is dedicated to the purposes of every single developer, the project package pool, which contains packages that are of interest to developers working together on a certain project, and the global package pool, which contains packages that may be useful for every developer. Two developers working with two different package pools can be seen in figure Figure 3-3.

Packages are compiled and archived in the local workspace, and may then be shipped to one of the package pools. Usually, the project and global package pools are shared by several developers. This is achieved by locating them on a distributed file system (like NFS or SMB). As files inside the package pools must be accessible by compilers, linkers etc., it is not possible to access the pools via a special protocol like the source code repository.

When the Elego ComPact Package Manager encounters an import-statement like import("fileio", 2.2.x), it searches the package pools in the following order for a matching package: first the local pool, second the project pool, last the global pool. So package versions in the local pool may override those in the project and global pool, and the versions in the project pool may override those contained in the global pool. This behaviour can be used as the base for very flexbile organizations of development work.