-->
Page 266
Some complex imake macros require generated make variables local to each invocation of the macro, often because their value depends on parameters passed to the macro. Such variables can be created by using an imake variable of the form XVARdefn, where n is a single digit. A unique make variable will be substituted. Later occurrences of the variable XVARusen will be replaced by the variable created by the corresponding XVARdefn.
On systems whose cpp reduces multiple tabs and spaces to a single space, imake attempts to put back any necessary tabs (make is very picky about the difference between tabs and spaces). For this reason, colons (:) in command lines must be preceded by a backslash (\).
USE WITH THE X WINDOW SYSTEM
The X Window System uses imake extensively, for both full builds within the source tree and external software. As mentioned earlier, two special variables, TOPDIR and CURDIR, are set to make referencing FILES using relative pathnames easier. For example, the following command is generated automatically to build the Makefile in the directory lib/X/ (relative to the top of the sources):
% ../.././config/imake _I../.././config \ _DTOPDIR=../../. _DCURDIR=./lib/X
When building X programs outside the source tree, a special symbol UseInstalled is defined and TOPDIR and CURDIR are omitted. If the configuration FILES have been properly installed, the script xmkmf(1) may be used.
INPUT FILES
Here is a summary of the FILES read by imake as used by X. The indentation shows which FILES include which other FILES.
Imake.tmpl generic variables site.def site-specific, BeforeVendorCF defined .cf machine-specific Lib.rules shared library rules site.def site-specific, AfterVendorCF defined Imake.rules rules Project.tmpl X-specific variables Lib.tmpl shared library variables Imakefile Library.tmpl library rules Server.tmpl server rules Threads.tmpl multi-threaded rules
Note that site.def is included twice, once before the *.cf file and once after. Although most site customizations should be specified after the *.cf file, some, such as the choice of compiler, need to be specified before, because other variable settings may depend on them.
The first time site.def is included, the variable BeforeVendorCF is defined, and the second time, the variable AfterVendorCF is defined. All code in site.def should be inside a #ifdef for one of these symbols.
FILES
Imakefile.c | Temporary input file for cpp |
/tmp/Imf.XXXXXX | Temporary Makefile for -s |
/tmp/IIf.XXXXXX | Temporary Imakefile if specified Imakefile uses # comments |
/lib/cpp | Default C preprocessor |
SEE ALSO
make(1), xmkmf(1)
S. I. Feldman, MakeA Program for Maintaining Computer Programs.
Page 267
ENVIRONMENT VARIABLES
The following ENVIRONMENT variables may be set; however, their use is not recommended as they introduce dependencies that are not readily apparent when imake is run.
IMAKEINCLUDE | If defined, this should be a valid include argument for the C preprocessor. Example: |
_I/usr/include/local
Actually, any valid cpp argument will work here. | |
IMAKECPP | If defined, this should be a valid path to a preprocessor program. Example: |
/usr/local/cpp
By default, imake will use /lib/cpp. | |
IMAKEMAKE | If defined, this should be a valid path to a make program, such as |
/usr/local/make
By default, imake will use whatever make program is found using execvp(3). This variable is only used if the _e option is specified. |
AUTHORs
Todd Brunhoff, Tektronix and MIT Project Athena
Jim Fulton, MIT X Consortium
X Version 11 Release 6
imgtoppmConvert an Img-whatnot file into a portable pixmap
SYNOPSIS
imgtoppm [imgfile]
DESCRIPTION
imgtoppm reads an Img-whatnot file as input and produces a portable pixmap as output. The Img-whatnot toolkit is available for FTP on venera.isi.edu, along with numerous images in this format.
SEE ALSO
ppm(5)
AUTHOR
Based on a simple conversion program posted to comp.graphics by Ed Falk.
Copyright" 1989 by Jef Poskanzer.
5 September 1989
inewsSend a Usenet article to the local news server for distribution
SYNOPSIS
inews [ _h ][_D ][_O ][_R ][_S ][header_flags ][input ]
Page 268
DESCRIPTION
Inews reads a Usenet news article (perhaps with headers) from the named file or standard input if no file is given. It adds some headers and performs some consistency checks. If the article does not meet these checks (for example, too much quoting of old articles, or posting to nonexistent newsgroups), then the article is rejected. If it passes the checks, inews sends the article to the local news server as specified in the inn.conf(5) file for distribution.
In the standard mode of operation, the input consists of the article headers, a blank line, and the message body. For com-patibility with older software, the _h flag must be used. If there are no headers in the message, then this flag may be omitted.
Several headers may be specified on the command line, shown in the SYNOPSIS above as header flags. Each of these flags takes a single parameter; if the value is more than one word (for example, almost all Subject lines) then quotes must be used to prevent the shell from splitting it into multiple words. The OPTIONS, and their equivalent headers, are as follows:
a | Approved |
c | Control |
d | Distribution |
e | Expires |
f | From |
w | Followup-To |
n | Newsgroups |
r | Reply-To |
t | Subject |
F | References |
o | Organization |
x | Path prefix |
The Path header is built according to the following rules. If the
_x flag is used, then its value will be the start of the
header. Any other host will see the site in the header, and therefore not offer the article to that site. If the
pathhost configuration parameter is specified in the
inn.conf(5) file, then it will be added to the Path. Otherwise, if the
server configuration parameter is specified, then the full domain name of the local host will be added to the Path. The Path will always end
not-for-mail.
The default Organization header will be provided if none is present in the article or if the _o flag is not used. To prevent adding the default, use the _O flag.
As a debugging aide, if the _D flag is used, the consistency checks will be performed, and the article will be sent to the standard output, rather then sent to the server.
For compatibility with C News, inews accepts, but ignores, the _A, _V, and _W flags. The C News _N flag is treated as the _D flag.
If a file named .signature exists in the user's home directory, inews will try to append it to the end of the article. If the file cannot be read, or if it is too long (for example, more than four lines or one standard I/O buffer), or if some other problem occurs, then the article will not be posted. To suppress this action, use the _S flag.
If the _R flag is used then inews will reject any attempts to post control messages.
If an unapproved posting is made to a moderated newsgroup, inews will try to mail the article to the moderator for posting. It uses the moderators(5) file to determine the mailing address. If no address is found, it will use the inn.conf file to determine a "last-chance" host to try.
If the NNTP server needs to authenticate the client, inews will use the NNTPsendpass-word(3) routine to authenticate itself. In order to do this, the program will need read access to the passwd.nntp(5) file. This is typically done by having the file group-readable and making inews run setgid to that group.
Inews exits with a zero status if the article was successfully posted or mailed, or with a nonzero status if the article could not be delivered.