ComPact is based on a powerful yet simple concept of dividing source code, documentation, and data into packages. It is then possible to provide integrated support for compilation, linkage, installation, and development in heterogenous environments. So one may indeed consider the system a platform for Comprehensive Package Management.
Despite its support for software development as a whole, ComPact is fairly easy to use. Beginning to use it is particularly easy. This chapter leads you through that, proceeding in the following way: First, you learn how to get started if an installation exists; second, a small example makes you familiar with the very basics of software package usage; third, this example is slightly extended so as to give a first impression of version management with ComPact.
You should read this chapter to get a clear picture of ComPact and, at the same time, to acquire basic knowledge needed later on.
Presupposing that there is a ComPact installation on your system, we suggest you start with a small test, namely with typing pkgm -help. ComPact should respond by printing the online help text. Your next step should consist of giving the default command, pkgm -build (cf. Section 2.2), by typing pkgm
Note: The default command is to build the local package
Then you should see a warning to the effect that your current working directory does not belong to a software package, and an error message. In particular, the following combination is possible:
!!! warning: undefined package: no package root ### fatal: need PKG_CONFIGURATION from environment or from compactrc
Note: ComPact must be told what TPC it is to be working with.
The second line means that ComPact has not been told what target/platform configuration, TPC for short, it is to be working with. This information is made up of a processor type, an operating system, an object code format, a compiler, and zero or more compiler options. At this stage, however, you really do not have to worry about the specifics of that. All that you need to know is one or more TPC names supported by your installation, and where to put them. However, you might also want to read on if there was another error, which could mean that ComPact did find a valid name at a location it can recognize. We describe below a method for providing it with such information that you may have to use for other adjustments.
At the end of this section, further fundamental commands besides pkgm -help , pkgm -man and the general command format can be found.
Some typical settings of what resources have to be used for what TPC are hard-wired into pkgm. Chapter 6 describes how one overrides them or introduces entirely new ones. The installed program, then, hardly produces anything useful without any recognizable TPC name. Here, we assume that you are able to obtain a locally supported name from the distribution, some knowledgeable person, or in any other way. In case your technical environment is heterogenous, please make sure that it is supported on the machine that you use to run ComPact.
A typical example of a TPC name is i386-freebsd2-aout-gcc-debug,optimize As an aside, let us describe that what it specifies:
Table 2-1.
| i386-freebsd2 | The platform is the FreeBSD 2 operating system on an Intel 386-compatible processor. |
| aout | The object code format is a.out. |
| gcc | The compiler is the GNU C/C++ |
| compiler by the Free Software Foundation. | |
| optimize,debug | The compiler shall optimize. At the same time, code suitable for running a debugger is to be generated. |
Your actual string should have the same format modulo the possible lack of any compiler option.
Note: To set up ComPact in your work space, you may create a .compactrc file.
ComPact tries to read the TPC name from an initialization file. Its name must be .compactrc or compact/compactrc, the search path is
$HOME/.compactrc $HOME/compact/compactrc /usr/contrib/lib/compact/compactrc /usr/local/lib/compact/compactrcthe file format is
<variable> <value> <comment>
#----------------------------------------------------------------------------------
platform-suffix-mapping # using this mapping, a suffix to <regex> =>
# <platform-suffix> identify
# the platform is constructed
# The regular expression is matched against
# the string <tpc-hosttype>-<tpc-ostype>
pkgkind <kind> # preferred package kind for pkgm and prjm
# all environment and internal variable
# are substituted within <kind>. Especially
# useful may be the variable
# {?platform-suffix}
configuration <tpc-name> # the default configuration to be used
# (if no package kind mapping matches)
pkgkind-tpc-mapping <regex> => <tpc-name>
# One or more of these lines define the
# mapping from package kinds to backend
# configurations to be used. In <tpc-name>,
# environment variables of the form $name or
# ${name} will be substituted, as well as
# internal variables denoted by {:name},
# {!name}, or {?name}. Especially useful are
# the following ones: {!tpc-hosttype},
# {!tpc-ostype}, {!tpc-variant},
# {!tpc-compiler}, {!tpc-options}
configpath <path1>;..;<pathn># the configuration search
# path for resources as
# pkgbase.default.data and
# pkgconf.cbcl
poolprefix <path> # prefix for pools
localpool <path> # location of local pool
projectpool <path> # location of project pool
globalpool <path> # location of global pool
bindir <path> # location of installed programs
localbindir <path> # location of locally installed programs
projectbindir <path> # location of project-wide installed programs
globalbindir <path> # location of globally installed programs
docdir <path> # location of installed documentation
localdocdir <path> # location of locally installed documentation
projectdocdir <path> # location of project-wide
# installed documentation
globaldocdir <path> # location of globally installed documentation
repository <path> # path of the cvs repository
cvsroot <path> # same as above
cvspath <path> # path of the cvs command to be used
vc-options <o1>,<o2>, # version control options propagated
# to the version control backend
# CVS currently knows about prune,
# noprune, create, nocreate
project-collection <path> # path of the server's initial project collection
package-collection <path> # path of the server's initial package collection
editor <program> # program name of the editor to be used
browser <program> # program name of the browser
httpd-resources <path> # path of the server's (html-) resources
httpd-port <number> # port of the server
httpd-help-resources <path> # path of the server's help
html files
the succession of entries does not matter, each entry may be omitted, and the patterns {HOME}, {USER}, and {PKG} may be part of the path-values. They will be substituted by the current values of the corresponding environment variables. Therefore, we postpone any further explanation; for the moment, a one-line .pkgmrc in your home directory suffices. We suggest you create such a file, if only to verify that everything works out as predicted. -- Please do not forget to back up any pre-installed one. -- In the presence of the new file, there should not be any error message indicating that ComPact cannot find a valid TPC name.
In keeping with the coherence and user friendliness of the overall system, commands have always the format pkgm <command_options_and_arguments>. Pkgm stands for package management. The following command options are of basic nature:
Note: simple command format
Table 2-2.
| -help | -h | print the help text |
| -man | -? | display the entire manual |
| -copyright | -cr | print the copyright notice and a contact address |
| -v | run verbosely |
| -q | run quietly |
Note that -help and -copyright have entirely equivalent short forms. Many further options may be abbreviated.
Note: One can abbreviate many commands.
On a terminological remark, we speak often of a pkgm command whenever we mean a ComPact command option.