7.3. Building and Shipping Packages

The package oriented integrated build environment is one of the most important and useful additions of Elego ComPact to pure version control. It allows you to reliably build the actual products you want to deliver from the sources checked out from the repository. Here is a list of its features:

• It is language independent and can be used together with lots of different compilers from different vendors.

• It offers support for heterogeneous, multi-platform builds and caches. This is done by strictly separating all sources from the derived files in a platform-dependend directory named after the target-platform-configuration (TPC) currently in use.

• It supports explicit import and export of elements of packages, thus realizing the concept of information hiding at a package (subsystem) level.

• It consists of an easy-to-use front end which is used daily by every programmer, and a highly configurable and advanced backend for the implementation of the target-platform-configurations. So there is a clear separation between what is to be done and how it is implemented.

• It supports versioned imports of packages, thus minimizing the danger of including the wrong version of a package in a shipped product.

• It is very efficient, because it uses a set of caches with local, project-wide, and global scale, called pools.

• It can be used to build single packages as well as complete projects. The latter is described in detail in Section 8.3.

• It implements all the algorithms needed for version based package build management in a language and platform independent way.

• It can be embedded in a bigger build system (by simply using the command line package manager pkgm) as well as embed other (for example more customized) build procedures by providing several well-defined hooks.

This section describes the package-oriented commands of the build system. For a discussion of the project-scale build facilities see Section 8.3. It is also focused on the frontend of the build system, meaning the commands that are invoked to build a package, and the description of the elements of packages. ComPact uses so-called target-platform-configurations (TPC for the selection of a concrete backend of the build system, meaning which compilers, linkers, assemblers etc. are actually called and with what parameters. For a short introduction of the syntax and semantics of TPCs, see Section 9.3.

To learn more about the build system of Elego ComPact, you should also consult the chapters Build Management and Target/Platform Configuration Management of the ComPact Package Manager Manual.

• To Build a package means to create or update all derived files, like object files, libraries, executable files, and formatted documentation. Usually, dependency information is computed in a first step and stored in files, too.

• Depend re-creates the dependency information explicitly. You usually don't need to do this.

• Clean removes (almost) all files that Build creates, except the dependency information and some administrative data.

• Realclean removes all derived files that the build system knows of.

Depending on the build configuration you use, all the actions described above can be performed using make and makefiles. This will generally only be necessary for very special build environments, e.g. cross compilations.

Shipping a package means copying all exported files to a pool of packages that is used to cache the results of build runs and thus considerably speeds up compilation of big systems. The local pool is intended to be used by every single developer; project pools are intended for use by people working together on a project; and global pools are used for globally sharing build results. By default, ComPact uses exactly one local, project, and global pool at a time, which are configured by the corresponding entries in your compactrc configuration file.

Packages in pools are versioned, which means that different versions of a package may be contained in a pool at one time. If you ship a package to a pool, usually the current version is used. If local modifications have been made to the package which are not yet committed, this may be undesireable, so that ComPact allows you to ship a package as the next major, minor, or patch development version, or to specify an explicit version. This should be used with care, since it may violate shipping policies and effectively harm your build environment.