![]() |
What QEF is, why it was created, and the principles underlying its design. |
![]() |
|
![]() |
is a software toolkit and framework used by development teams to control
their software constructions.
It consists of approximately 140 programs that
together provide a construction system,
which combined with a version system,
enables any developer to build any release of any software
product on any machine at any time.
Developers control all their builds with a single set of commands,
regardless of platform, development language or compilers.
Many popular construction targets
(program, library, debug, profile, install, release, etc.)
are supported right out of the box;
and you can customize QEF to support new constructions.
QEF takes into account the complexities of
the modern software development environment.
It scales to small, medium, and large projects.
The QEF toolkit can manage even the most complex software constructions,
thousands of source files stored in hundreds of directories
and spanning numerous platforms.
With large software projects,
QEF can save developer hours,
which translates into many thousands of dollars.
QEF provides a consistency that simplifies post-release maintenance.
With the QEF toolkit, you can build all your software in a consistent way. Many developers, many projects, many releases, many platforms. No matter what the project, development language, platform, release or developer, a single set of commands builds the product. |
![]() |
At first, you might find it useful to think of QEF as "super-make", though it is more than an extended or enhanced make. QEF is a toolkit. The QEF tools combine in various ways to control your software constructions. Most of the QEF tools are command-line utilities that can be invoked directly from the shell. Although you can run any of the QEF tools directly, you as a developer normally deal with one of the two interface or driver programs: qef, the command-line interface, and qefgui, the GUI interface. These two driver programs allow you to trigger an arbitrarily complex construction process with a single mouse click or command. This is perhaps the greatest strength of QEF. As one developer has said, "All you ever say is `qef'." |
![]() |
The most common tool for software construction is make or one of its derivatives. When the original make was developed in the mid-seventies, it was a major step forward. In the decades since, software has grown much more complex. The standard make and its descendants fall short of what you need as a software developer. At the least, you need a system that:
|
![]() |
QEF was designed to give you confidence in your software constructions. In practice, this involves several sub-goals: |
Abstraction | Software constructions are described in abstract terms. Platforms, directories, file names, development tools and their parameters are all abstracted, allowing you to describe a construction at a higher level. You no longer have to worry about such problems as different compiler flags on various platforms. |
Isolation | The source and object directories should be isolated from one another. The source tree should contain sources and nothing else. The object tree should contain nothing you cannot remove anytime you need some disk space or want to start again. |
Locality | You can build any part of a software product, so you build only what needs to be built. |
Simplicity | You can build all your software products using the same simple method, regardless of programming language, platform, release number, production mode (e.g. debug, Purify) or developer location. You should never have to modify make scripts simply to add or remove or relocate sources. |
Flexibility |
The QEF software construction environment offers flexibility in these
four areas:
|
Verifiability | Every software construction produces a build log (i.e., an audit trail) listing precisely what went into the resulting product. The log is unambiguous and exhaustive (e.g., all hidden dependencies are revealed). |
![]() |
qef is a driver program that controls your builds, calling QEF tools and other programs as needed to perform the builds. A qef run passes through three phases:
|
![]() |
|
Initialization and Parameterization | This includes reading the qvrs configuration files as well as the qeffile to assemble all of the information needed to do the construction. |
Script Preparation | transforming all of the abstract construction descriptions into explicit instructions appropriate to the selected back-end process. For example, the abstract command might be to build a library. The language to use, the location of the input files, the compiler arguments to use, the developer and the platform are all stored in the database and referenced symbolically. During script preparation, references to each of named files are resolved to absolute pathnames for the construction host. |
Back-End Interpretation | typically, executing the complete set of instructions generated in the previous phase to build a given software product. The construction might invoke virtually any tool (e.g., rdist), but most often calls mimk, qsh, or make. |
![]() |
To better understand how QEF works, you should be familiar with some terms used throughout the QEF documentation. Other terms may be retrieved from the on-line glossary by typing % x-qmisc glossary |
Source file | Any file created by the developers that is crucial to a software construction. |
Object file | Any file produced as an intermediate product during a software construction. |
Product | The file(s) resulting from a successful construction. |
Baseline Source Tree | A read-only copy of the complete set of source files for a particular release of a product. |
VCS | A version-control system such as RCS, SCCS, or CVS. |
Release | A version of the product, typically created after a milestone has been reached (beta release, final release, and in many shops, the product as delivered to a particular client). At each release point, a complete record of how the product was built should be created so that post-release maintenance can be done. |
Viewpath | A list of directory trees that will be searched when looking for a particular file; the system stops at the first match. This is a generalization of the viewpath mechanism on other systems, which only specifies directories. For example, suppose the viewpath includes the directory trees rooted at /work, /unpub, and /baseline, and the QEF system is searching for the file io.c in the current directory, /work/cli/modules. The QEF system looks for the file in each tree: first /work/cli/modules/io.c, then for the file /unpub/cli/modules/io.c, and lastly for the file /baseline/cli/modules/io.c. As soon as the file is found, the search stops. |
Trees | A tree is a hierarchical arrangement of files in the filesystem. The hierarchical structure is used to manage the complexity of a project. At the root of each tree in the QEF system there is a file that links it to one or more parent trees as shown in Figure 1-2. Each tree also has a type associated with it that describes its purpose (e.g. baseline, working or object). |
Working Tree | The tree where constructions are performed. An object tree has a parent source tree, which may itself have parent trees, and so on. Objects are built using the files from the combination of these source trees. Only generated and temporary files are kept in object trees. |
Tree Set | The set of trees being developed by the developer. |
Object Tree | The tree where all of the constructions are performed. Each object tree has one source or baseline source tree as its parent tree. Only generated and temporary files are kept in object trees. Each object tree has a unique set of construction information associated with it that describes how things are built in the tree. |
Destination Directory | The directory (or directory tree) into which the final products of the construction processes are installed. Usually the destination directory does not mirror the source tree. |
![]() |
Because QEF is flexible, it can be adapted to a number of development models. Here is one that is strongly supported by QEF. It is suitable for large projects. Preferably there is a code librarian, who is responsible for all code in the project and building all of the versions of the product. The code librarian may be the project manager or part of the quality assurance staff, or simply a senior developer. The source code that is used to build the product is kept in the baseline tree, which should be under control of the code librarian, and under version control. Each developer has a working tree for this project, and one or more object trees. Typically there is an object tree for each configuration supported. When developers need to make changes to a file or set of files, they use the version control interface (vci) to retrieve the file(s) from the baseline source into their working tree. After making modifications to the working tree source, they build in their object trees. This is shown here. The two production trees are both object trees representing different configurations. Both are built from the baseline source. The developer has a working tree that is a subset of the baseline tree. Each object tree is built from the source in the working tree, with any files not there taken from the baseline source. If any additional files (e.g., headers, tools, or libraries) that are not built in the developer's tree are required, they are usually accessed directly from the production version.
|
![]() |
When the developer is satisfied with the changes, he or she uses the version control interface to submit them to the version system. The changed will then be incorporated into the baseline and then used to build the production versions. This scheme has a number of interesting advantages.
|
![]() |
Some of the more important tools in the QEF toolset are: |
qef | the command-line driver program that controls software constructions. See Chapter 4 for the QEF tutorials. |
qefgui | a graphical user interface which calls all the other tools, simplifying the task of software construction. Using qefgui, you can perform most tasks with a few mouse clicks. See Chapter 5. |
qef Info tool | part of the qefgui, the Info tool is a comprehensive hypertext information tool which provides access to all of the documentation about QEF and the UNIX Programmer's Manual (UPM) pages. See Chapter 5.6. |
qvrs | a utility which processes the database of construction information (such as paths, tool names and flags, project names and locations). All the other tools in the toolset have access to this database, and look to it for any information they require. Since qvrs is a separate QEF program, it can be used by any other tool to query the construction database. See Chapter 8. |
qsg | the QEF script generator; this program translates high-level construction expressions into the detailed scripts used by lower-level construction tools (typically the output is a mimk script). See Chapter 9. |
lib/qsg/std.qsl | a library of qsg scripts that perform a variety of standard operations involved in software construction, from creating a new project to preparing a distribution. Many of the commands and arguments given in the construction files are actually qsg scripts from the library. See Chapter 9.4. |
qefdirs | the directory script generator; this program creates scripts to run qef sub-processes in named directories, and makes it possible for QEF to handle trees of constructions. |
qds | an interface to the QEF project server (qdsrv) that simplifies finding out what projects and trees are available and where they are. See Chapter 6. |
qhy | a tool that queries the construction history files to find out why something was built. |
mimk | a replacement for make. Because configuration and script generation is done elsewhere, mimk can be a faster, more robust consistency engine than make. |
incls | an extremely fast source dependency evaluator for a variety of languages that is used to dynamically create the dependency lists. See incls. |
instal | used to install files in remote directories, paranoidly checking everything, recording actions in audit trail, getting flags and controls from the qvrs system, recording chown, chgrp, and chmod failures. See instal. |
arupdate |
an interface to ar that provides comprehensive control.
See arupdate.
There are many other tools besides these, but for the most part they are called automatically by these principal tools. Some of the other important or really useful tools are described in Chapter 11. A complete list of the QEF tool set is given in Appendix E. |
![]() |
QEF is a state-of-the-art software construction toolset.
In particular, QEF provides:
This means:
The result is confidence in your work. |
c007.qh - 1.23 - 00/05/30 |
![]() ![]() ![]() ![]() ![]() |