\end{verbatim}
If all these things are true, then you already know how to build and
-install the modules you've just downloaded: run the command above.
+install the modules you've just downloaded: Run the command above.
Unless you need to install things in a non-standard way or customize the
build process, you don't really need this manual. Or rather, the above
command is everything you need to get out of this manual.
want to customize the build process, or if things are going wrong---you
can use the setup script to do one thing at a time. This is
particularly helpful when the build and install will be done by
-different users---e.g., you might want to build a module distribution
+different users---for example, you might want to build a module distribution
and hand it off to a system administrator for installation (or do it
yourself, with super-user privileges).
The specified installation directories are relative to \filevar{prefix}.
Of course, you also have to ensure that these directories are in
-Python's module search path, e.g. by putting a \file{.pth} file in
+Python's module search path, such as by putting a \file{.pth} file in
\filevar{prefix}.
% \XXX should have a section describing \file{.pth} files and
\begin{tableiii}{l|l|c}{textrm}
{Type of file}{Location and filename}{Notes}
\lineiii{system}{\filenq{\filevar{prefix}\textbackslash{}Lib\textbackslash{}distutils\textbackslash{}distutils.cfg}}{(4)}
- \lineiii{personal}{\filenq{\%HOME\textbackslash{}pydistutils.cfg}}{(5)}
+ \lineiii{personal}{\filenq{\%HOME\%\textbackslash{}pydistutils.cfg}}{(5)}
\lineiii{local}{\filenq{setup.cfg}}{(3)}
\end{tableiii}
1.5.2.
\item[(2)] On \UNIX, if the \envvar{HOME} environment variable is not
defined, the user's home directory will be determined with the
- \function{getpwuid()} function from the standard \module{pwd} module.
+ \function{getpwuid()} function from the standard
+ \ulink{\module{pwd}}{../lib/module-pwd.html} module.
\item[(3)] I.e., in the current directory (usually the location of the
setup script).
\item[(4)] (See also note (1).) Under Python 1.6 and later, Python's
extensions to build. Each line in a \file{Setup} describes a single
module. Lines have the following structure:
-\begin{verbatim}
- <module> ... [<sourcefile> ...] [<cpparg> ...] [<library> ...]
-\end{verbatim}
+\begin{alltt}
+\var{module} ... [\var{sourcefile} ...] [\var{cpparg} ...] [\var{library} ...]
+\end{alltt}
Let's examine each of the fields in turn.
\begin{itemize}
\item \var{module} is the name of the extension module to be built,
-and should be a valid Python identifier. You can't just change this
-in order to rename a module (edits to the source code would also be
-needed), so this should be left alone.
+ and should be a valid Python identifier. You can't just change
+ this in order to rename a module (edits to the source code would
+ also be needed), so this should be left alone.
\item \var{sourcefile} is anything that's likely to be a source code
-file, at least judging by the filename. Filenames ending in .c are
-assumed to be written in C, filenames ending in .C, .cc, .c++ are
-assumed to be \Cpp, and filenames ending in .m or .mm are assumed to
-be in Objective C.
+ file, at least judging by the filename. Filenames ending in
+ \file{.c} are assumed to be written in C, filenames ending in
+ \file{.C}, \file{.cc}, and \file{.c++} are assumed to be
+ \Cpp, and filenames ending in \file{.m} or \file{.mm} are
+ assumed to be in Objective C.
\item \var{cpparg} is an argument for the C preprocessor,
-and is anything starting with -I, -D, -U or -C .
+ and is anything starting with \programopt{-I}, \programopt{-D},
+ \programopt{-U} or \programopt{-C}.
-\item <library> is anything ending in .a or beginning with -l or -L.
+\item \var{library} is anything ending in \file{.a} or beginning with
+ \programopt{-l} or \programopt{-L}.
\end{itemize}
If a particular platform requires a special library on your platform,
\end{verbatim}
must be linked with the math library \file{libm.a} on your platform,
-simply add \samp{-lm} to the line:
+simply add \programopt{-lm} to the line:
\begin{verbatim}
foo foomodule.c -lm
\end{verbatim}
Arbitrary switches intended for the compiler or the linker can be
-supplied with the \code{-Xcompiler \var{arg}} and \code{-Xlinker
-\var{arg}} options:
+supplied with the \programopt{-Xcompiler} \var{arg} and
+\programopt{-Xlinker} \var{arg} options:
\begin{verbatim}
foo foomodule.c -Xcompiler -o32 -Xlinker -shared -lm
\end{verbatim}
-The next option after \code{-Xcompiler} and \code{-Xlinker} will be
-appended to the proper command line, so in the above example the
-compiler will be passed the \samp{-o32} option, and the linker will be
-passed \samp{-shared}. If a compiler option requires an argument,
-you'll have to supply multiple \code{-Xcompiler} options; for example,
-to pass \code{-x c++} the \file{Setup} file would have to contain
-\code{-Xcompiler -x -Xcompiler c++}.
+The next option after \programopt{-Xcompiler} and
+\programopt{-Xlinker} will be appended to the proper command line, so
+in the above example the compiler will be passed the \programopt{-o32}
+option, and the linker will be passed \programopt{-shared}. If a
+compiler option requires an argument, you'll have to supply multiple
+\programopt{-Xcompiler} options; for example, to pass \code{-x c++} the
+\file{Setup} file would have to contain
+\code{-Xcompiler -x -Xcompiler c++}.
Compiler flags can also be supplied through setting the
\envvar{CFLAGS} environment variable. If set, the contents of
projects / python / commitdiff