|
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:
^Top
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.
^Top
Script Language
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 @argv # compile one or more source files
library -n foo -v @argv # build a library file
Note: 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.
The combination of configuration language (qvrs), high-level script language (qsg), and macro facilities (qefpp) provides the developer with a "build" environment of considerable flexibity.
^Top
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.
^Top
Library Management
qef simplifies the use of object libraries. For example, individual source files may use "magic" comments to specify the libraries which they require:
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"
Libraries may be remapped. For example, the following qvrs command tells qef to add the library "bsd" whenever the X11 library is used:
set LibMap[-lX11] -lX11 -lbsd
Additionally, 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.
^Top
Back-End Software
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.
qmk is a newer version of mimk which is under development. qmk adds dependency evaluation, extended history mechanisms, and other features.
^Top
|
