The QEF environment consists
of the main QEF executable, support programs, and on-line
documentation. QEF can be used at the command-line level
or through a graphical user interface (GUI) named qefgui.
During a "build" operation, QEF performs three major steps:
QEF includes mechanisms which simplify management of:
|Project Configuration (qvrs)
QEF uses a separate program, qvrs, to manage
configuration parameters, variables, search paths, tool names, etc.
qvrs builds a configuration-variable database which is used
by other components of the QEF system.
qvrs eliminates most of the configuration problems which normally occur with large projects. qvrs supports a simple configuration language which can be used to specify standard parameters (platform, project version, etc.), as well as user-defined parameters.
The QEF toolset includes a script generator named
qsg. qsg translates simple high-level scripts into
low-level scripts suitable for use with other programs (such as
purify or QEF's own version of make).
For example, qsg translates the following high-level script into a low-level script which builds a library file:
commands # compile one or more source files library -n foo -v # build a library fileNote: This script processes source files based on the filename extension. For example, if the current directory contains C source files, qsg will produce an output script which runs the C compiler.
"commands" and "library" are qsg scripts themselves. The developer can modify these scripts or add new scripts to support new languages and/or operations.
QEF runs qsg output scripts through a macro processor qefpp before passing them to the back-end software. qefpp translates high-level macro calls appropriately. For example, if the qsg script for a given program includes the following macro call:
_FndSrc_(bar.c)qefpp will search the associated source directories for the file "bar.c" and replace the macro call with the full pathname obtained.
qefpp also resolves references to variables defined in the qvrs database; e.g., directory paths, command-line option switches, etc.
|Directory Server (qdsrv)
The QEF toolset includes a daemon (or server) named
qdsrv. qdsrv maintains a database which describes
project directory trees. In a LAN environment, the database includes
projects located on any/all hosts.
qdsrv may be used to locate and/or jump to project trees based on attributes, as well as project names. Developers working on large projects don't need to know the directory paths associated with particular configurations, release numbers, host systems, etc. This greatly simplifies project-tree management.
QEF simplifies the use of object libraries. For example,
individual source files may use "magic" comments to specify the
libraries which they require:
/* LIBS: -lXaw -lXmu -lXt -lXext -lX11 */qvrs commands may be used to specify libraries either globally or on a module-by-module basis:
set ExtraLibs -lplumber # always load this library set LIBS[foo.c] -lm -lsocket # libraries required by "foo.c" set LIBS[bar.c] -lX11 -lbsd # libraries required by "bar.c"qvrs Libraries may be remapped. For example, the following command tells QEF to add the library "bsd" whenever the X11 library is used:
set LibMap[-lX11] -lX11 -lbsdAdditionally, qvrs commands may be used to control the use of "static" libraries vs. "shared" libraries either globally or on a library-by-library basis.
At link time, QEF determines the total set of libraries required automatically, remaps the libraries, locates them, and passes them to the linker. This approach reduces effort spent on library management significantly.
The QEF toolset includes a number of programs written
specifically for use as back-end interpreters.
For example, qsh is a minimal "shell" (or command interpreter) that includes features added to simplify "build" operations.
mimk is a make-like program that provides parallel execution of "recipes", a "build" history, extended consistency checking, "gentle" halts, and other enhancements.
|qefarch.qh - 1.17 - 05/09/23|