traverseda
/
cpython
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Changed '\option' to '\longprogramopt' wherever it referred to a command-line 

option.
This commit is contained in:
Greg Ward 2000-04-19 22:34:11 +00:00
parent ff9ea480eb
commit a021acacfb
2 changed files with 27 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
Doc/dist/dist.tex vendored
View File

@ -356,7 +356,7 @@ default format for the current platform. The default formats are:
\lineii{Unix}{gzipped tar file (\file{.tar.gz})}
\lineii{Windows}{zip file}
\end{tableii}
You can specify as many formats as you like using the \option{--formats}
You can specify as many formats as you like using the \longprogramopt{formats}
option, for example:
\begin{verbatim}
python setup.py sdist --formats=gztar,zip
@ -486,10 +486,10 @@ source distribution:
\begin{verbatim}
python setup.py sdist --manifest-only
\end{verbatim}
(\option{--manifest-only} implies \option{--force-manifest}.)
(\longprogramopt{manifest-only} implies \longprogramopt{force-manifest}.)
If you don't want to use the default file set, you can supply the
\option{--no-defaults} option. If you use \option{--no-defaults} and
\longprogramopt{no-defaults} option. If you use \longprogramopt{no-defaults} and
don't supply a manifest template (or it's empty, or nothing matches the
patterns in it), then your source distribution will be empty.
@ -547,7 +547,7 @@ between someone being able to use your extensions or not.
\XXX{filenames are inaccurate here!}
The \command{bdist} command has a \option{--format} option, similar to
The \command{bdist} command has a \longprogramopt{format} option, similar to
the \command{sdist} command, that you can use to select which formats to
generate: for example,
\begin{verbatim}
@ -580,7 +580,7 @@ The available formats for built distributions are:
\end{description}
You don't have to use the \command{bdist} command with the
\option{--formats} option; you can also use the command that directly
\longprogramopt{formats} option; you can also use the command that directly
implements the format you're interested in. Many of these
\command{bdist} ``sub-commands'' actually generate several similar
formats; for instance, the \command{bdist\_dumb} command generates all

44
Doc/inst/inst.tex
View File

@ -219,7 +219,7 @@ As implied above, the \command{build} command is responsible for putting
the files to install into a \emph{build directory}. By default, this is
\file{build} under the distribution root; if you're excessively
concerned with speed, or want to keep the source tree pristine, you can
change the build directory with the \option{--build-base} option. For
change the build directory with the \longprogramopt{build-base} option. For
example:
\begin{verbatim}
python setup.py build --build-base=/tmp/pybuild/foo-1.0
@ -342,16 +342,16 @@ installations in the next section.
{Override option}
\lineiii{pure module distribution}
{\filevar{#1}\filenq{#2}}
{\option{--install-purelib}}
{\longprogramopt{install-purelib}}
\lineiii{non-pure module distribution}
{\filevar{#3}\filenq{#4}}
{\option{--install-platlib}}
{\longprogramopt{install-platlib}}
\lineiii{scripts}
{\filevar{#5}\filenq{#6}}
{\option{--install-scripts}}
{\longprogramopt{install-scripts}}
\lineiii{data}
{\filevar{#7}\filenq{#8}}
{\option{--install-data}}
{\longprogramopt{install-data}}
\end{tableiii}}
\section{Alternate Installation}
@ -390,14 +390,14 @@ Installing a new module distribution is as simple as
\begin{verbatim}
python setup.py install --home=<dir>
\end{verbatim}
where you can supply any directory you like for the \option{home}
where you can supply any directory you like for the \longprogramopt{home}
option. Lazy typists can just type a tilde (\code{\tilde}); the
\command{install} command will expand this to your home directory:
\begin{verbatim}
python setup.py install --home=~
\end{verbatim}
The \option{home} option defines the installation base directory. Files
The \longprogramopt{home} option defines the installation base directory. Files
are installed to the following directories under the installation base
as follows:
\installscheme{home}{/lib/python}
@ -438,12 +438,12 @@ could be done with
/usr/local/bin/python setup.py install --prefix=/mnt/@server/export
\end{verbatim}
In either case, the \option{prefix} option defines the installation
base, and the \option{exec-prefix} option defines the platform-specific
In either case, the \longprogramopt{prefix} option defines the installation
base, and the \longprogramopt{exec-prefix} option defines the platform-specific
installation base, which is used for platform-specific files.
(Currently, this just means non-pure module distributions, but could be
expanded to C libraries, binary executables, etc.) If
\option{exec-prefix} is not supplied, it defaults to \option{prefix}.
\longprogramopt{exec-prefix} is not supplied, it defaults to \longprogramopt{prefix}.
Files are installed as follows:
\installscheme{prefix}{/lib/python1.\filevar{X}/site-packages}
@ -451,14 +451,14 @@ Files are installed as follows:
{prefix}{/bin}
{prefix}{/share}
There is no requirement that \option{prefix} or \option{exec-prefix}
There is no requirement that \longprogramopt{prefix} or \longprogramopt{exec-prefix}
actually point to an alternate Python installation; if the directories
listed above do not already exist, they are created at installation
time.
Incidentally, the real reason the prefix scheme is important is simply
that a standard Unix installation uses the prefix scheme, but with
\option{prefix} and \option{exec-prefix} supplied by Python itself (as
\longprogramopt{prefix} and \longprogramopt{exec-prefix} supplied by Python itself (as
\code{sys.prefix} and \code{sys.exec\_prefix}). Thus, you might think
you'll never use the prefix scheme, but every time you run \code{python
setup.py install} without any other options, you're using it.
@ -472,7 +472,7 @@ used to run extensions installed in this way is compatibile with the
interpreter used to build them. The best way to do this is to ensure
that the two interpreters are the same version of Python (possibly
different builds, or possibly copies of the same build). (Of course, if
your \option{prefix} and \option{exec-prefix} don't even point to an
your \longprogramopt{prefix} and \longprogramopt{exec-prefix} don't even point to an
alternate Python installation, this is immaterial.)
@ -481,8 +481,8 @@ alternate Python installation, this is immaterial.)
Since Windows has no conception of a user's home directory, and since
the standard Python installation under Windows is simpler than that
under Unix, there's no point in having separate \option{prefix} and
\option{home} options. Just use the \option{prefix} option to specify
under Unix, there's no point in having separate \longprogramopt{prefix} and
\longprogramopt{home} options. Just use the \longprogramopt{prefix} option to specify
a base directory, e.g.
\begin{verbatim}
python setup.py install --prefix="\Temp\Python"
@ -490,8 +490,8 @@ python setup.py install --prefix="\Temp\Python"
to install modules to the \file{\bslash{}Temp} directory on the current
drive.
The installation base is defined by the \option{prefix} option; the
\option{exec-prefix} option is not supported under Windows. Files are
The installation base is defined by the \longprogramopt{prefix} option; the
\longprogramopt{exec-prefix} option is not supported under Windows. Files are
installed as follows:
\installscheme{prefix}{}
{prefix}{}
@ -504,7 +504,7 @@ installed as follows:
Like Windows, Mac~OS has no notion of home directories (or even of
users), and a fairly simple standard Python installation. Thus, only a
\option{prefix} option is needed. It defines the installation base, and
\longprogramopt{prefix} option is needed. It defines the installation base, and
files are installed under it as follows:
\XXX{how do MacPython users run the interpreter with command-line args?}
@ -541,14 +541,14 @@ how you define a custom installation scheme. These override options can
be relative, absolute, or explicitly defined in terms of one of the
installation base directories. (There are two installation base
directories, and they are normally the same---they only differ when you
use the Unix ``prefix scheme'' and supply different \option{prefix} and
\option{exec-prefix} options.)
use the Unix ``prefix scheme'' and supply different \longprogramopt{prefix} and
\longprogramopt{exec-prefix} options.)
For example, say you're installing a module distribution to your home
directory under Unix---but you want scripts to go in
\file{\tilde/scripts} rather than \file{\tilde/bin}. As you might
expect, you can override this directory with the
\option{install-scripts} option; in this case, it makes most sense to
\longprogramopt{install-scripts} option; in this case, it makes most sense to
supply a relative path, which will be interpreted relative to the
installation base directory (your home directory, in this case):
\begin{verbatim}
@ -559,7 +559,7 @@ Another Unix example: suppose your Python installation was built and
installed with a prefix of \file{/usr/local/python}, so under a standard
installation scripts will wind up in \file{/usr/local/python/bin}. If
you want them in \file{/usr/local/bin} instead, you would supply this
absolute directory for the \option{install-scripts} option:
absolute directory for the \longprogramopt{install-scripts} option:
\begin{verbatim}
python setup.py install --install-scripts=/usr/local/bin
\end{verbatim}