The central role of the package concept has become clear in the course of the previous chapters. Disregarding version control objects, the files that belong to a package fall into the following groups:
The mandatory package description file, PkgDesc.
Source files such as, for example, C/C++ headers or source code files.
Derived files such as, for example, libraries and programs.
They are organized according to the software package directory structure introduced in Chapter 2. As for the current chapter, Section 4.1 gives a more detailed overview what types possible package content a user must know of; Section 4.2 is concerned with package description.
ComPact can handle lots of different types of packages, usually used for different programming languages. These types of packages are referred to as package kinds, which are defined in a resource named PkgBase.DefaultData for historical reasons. This file contains definitions that describe the structure of packages (used to identify and create a package) and actions that may be applied to the package. The current default version of it contains definitions for the following package kinds:
COMPACT_SIMPLE_UNIX
DEC_SRC_M3_UNIX
CRITICAL_MASS_M3_UNIX
CRITICAL_MASS_M3_WIN32
COMPACT_CC_UNIX
COMPACT_CC_WIN32
COMPACT_JAVA_UNIX
COMPACT_JAVA_WIN32
The suffixes _UNIX and _WIN32 are one means to distinguish the available command set on different platforms and can be ignored until later. So there are four different package kinds for three supported languages (Modula-3, C++, Java). And, like every other resource used by ComPact, you can easily change and extend the default definitions of this file and define your own package kinds and package structure.
For the purposes of introduction the different package kinds are ignored in the following sections, and COMPACT_CC is used for all examples. This will make it considerably easier to grasp the concepts and learn the use of packages and package description files. Later, we will have a look at how Java packages differ from the C/C++ packages used as introduction.
The table below shows the types of mandatory or possible package content you may be required to touch. Of course, there is no way of ignoring the PkgDesc, so this file is, in fact, the only package element that is mandatory. Those elements that may be present are external C/C++ defines or various kinds of files, where the latter may be either source files or derived files. Naturally, no package will be of much use without at least one C/C++ source code file.
As for the table format, each cell without any entry is void. For example, the column titled ``source or derived'' does neither apply to the PkgDesc nor to external C/C++ defines. Morever,
such defines are located within the PkgDesc (second column),
the usual default extensions are associated with C/C++ header and source code files and C++ template files (fourth column), and
you can see what types of package content may be imported or exported (fifth and sixth columns). The default export strategy is such that documentation files, libraries, and programs are exported; all other exportable elements are hidden by default.
Table 4-1.
| file type | source or derived | location relative to the package root directory | default extension | importable | default export status |
|---|---|---|---|---|---|
| PkgDesc (mandatory) | . / | ||||
| C/C++ header files | s | inc / | h/hh | * | hidden |
| C/C++ source code files | s | src / | c/cc | * | hidden |
| C/C++ generic header files | s | inc / | gh/ghh | * | hidden |
| C/C++ generic source code files | s | src / | gc/gcc | * | hidden |
| C++ template files | s | inc / | thh | * | hidden |
| C/C++ defines | PkgDesc | * | hidden | ||
| assembler source code files | s | src | asm | hidden | |
| documentation files | s | doc / | exported | ||
| libraries | d | <TPC_name> / | * | exported | |
| programs | d | <TPC_name> / | exported |
You may override the default extensions. The means of that are described at the end of this chapter.
Generic files are not further elaborated here. The reason is that they are part of ComPact's built-in template mechanism, which is described in Chapter 8.
There is somewhat more to package structure than that what has been mentioned up until now. More specifically, elements other than the PkgDesc may be grouped together into TPC-dependent sections or so-called test sections. Because TPC-dependency is associated with TPC-management, this issue is dealt with in Chapter 6; test sections are explained below.
It is entirely possible to create sub-directories of the source code directory, for instance. In such cases, source code files etc. must be declared by stating paths rather than mere file names. The declaration syntax takes account of this requirement accordingly.