Doc: remove invalid uses of ":option:" which will emit warnings in Sphinx 1.3.

1 files changed, 19 insertions, 19 deletions

diff --git a/Doc/distutils/setupscript.rst b/Doc/distutils/setupscript.rst
index fbe4290..8d89f3b 100644
--- a/Doc/distutils/setupscript.rst
+++ b/Doc/distutils/setupscript.rst
@@ -62,9 +62,9 @@ code instead of hardcoding path separators::
 Listing whole packages
 ======================
 
-The :option:`packages` option tells the Distutils to process (build, distribute,
+The ``packages`` option tells the Distutils to process (build, distribute,
 install, etc.) all pure Python modules found in each package mentioned in the
-:option:`packages` list.  In order to do this, of course, there has to be a
+``packages`` list.  In order to do this, of course, there has to be a
 correspondence between package names and directories in the filesystem.  The
 default correspondence is the most obvious one, i.e. package :mod:`distutils` is
 found in the directory :file:`distutils` relative to the distribution root.
@@ -75,7 +75,7 @@ the directory where your setup script lives.  If you break this promise, the
 Distutils will issue a warning but still process the broken package anyway.
 
 If you use a different convention to lay out your source directory, that's no
-problem: you just have to supply the :option:`package_dir` option to tell the
+problem: you just have to supply the ``package_dir`` option to tell the
 Distutils about your convention.  For example, say you keep all Python source
 under :file:`lib`, so that modules in the "root package" (i.e., not in any
 package at all) are in :file:`lib`, modules in the :mod:`foo` package are in
@@ -94,13 +94,13 @@ written in the setup script as ::
 
     package_dir = {'foo': 'lib'}
 
-A ``package: dir`` entry in the :option:`package_dir` dictionary implicitly
+A ``package: dir`` entry in the ``package_dir`` dictionary implicitly
 applies to all packages below *package*, so the :mod:`foo.bar` case is
 automatically handled here.  In this example, having ``packages = ['foo',
 'foo.bar']`` tells the Distutils to look for :file:`lib/__init__.py` and
-:file:`lib/bar/__init__.py`.  (Keep in mind that although :option:`package_dir`
+:file:`lib/bar/__init__.py`.  (Keep in mind that although ``package_dir``
 applies recursively, you must explicitly list all packages in
-:option:`packages`: the Distutils will *not* recursively scan your source tree
+``packages``: the Distutils will *not* recursively scan your source tree
 looking for any directory with an :file:`__init__.py` file.)
 
 
@@ -120,7 +120,7 @@ This describes two modules, one of them in the "root" package, the other in the
 :mod:`pkg` package.  Again, the default package/directory layout implies that
 these two modules can be found in :file:`mod1.py` and :file:`pkg/mod2.py`, and
 that :file:`pkg/__init__.py` exists as well. And again, you can override the
-package/directory correspondence using the :option:`package_dir` option.
+package/directory correspondence using the ``package_dir`` option.
 
 
 .. _describing-extensions:
@@ -138,7 +138,7 @@ directories, libraries to link with, etc.).
 .. XXX read over this section
 
 All of this is done through another keyword argument to :func:`setup`, the
-:option:`ext_modules` option.  :option:`ext_modules` is just a list of
+``ext_modules`` option.  ``ext_modules`` is just a list of
 :class:`~distutils.core.Extension` instances, each of which describes a
 single extension module.
 Suppose your distribution includes a single extension, called :mod:`foo` and
@@ -181,7 +181,7 @@ in the filesystem (and therefore where in Python's namespace hierarchy) the
 resulting extension lives.
 
 If you have a number of extensions all in the same package (or all under the
-same base package), use the :option:`ext_package` keyword argument to
+same base package), use the ``ext_package`` keyword argument to
 :func:`setup`.  For example, ::
 
     setup(...,
@@ -336,24 +336,24 @@ Other options
 
 There are still some other options which can be used to handle special cases.
 
-The :option:`optional` option is a boolean; if it is true,
+The ``optional`` option is a boolean; if it is true,
 a build failure in the extension will not abort the build process, but
 instead simply not install the failing extension.
 
-The :option:`extra_objects` option is a list of object files to be passed to the
+The ``extra_objects`` option is a list of object files to be passed to the
 linker. These files must not have extensions, as the default extension for the
 compiler is used.
 
-:option:`extra_compile_args` and :option:`extra_link_args` can be used to
+``extra_compile_args`` and ``extra_link_args`` can be used to
 specify additional command line options for the respective compiler and linker
 command lines.
 
-:option:`export_symbols` is only useful on Windows.  It can contain a list of
+``export_symbols`` is only useful on Windows.  It can contain a list of
 symbols (functions or variables) to be exported. This option is not needed when
 building compiled extensions: Distutils  will automatically add ``initmodule``
 to the list of exported symbols.
 
-The :option:`depends` option is a list of files that the extension depends on
+The ``depends`` option is a list of files that the extension depends on
 (for example header files). The build command will call the compiler on the
 sources to rebuild extension if any on this files has been modified since the
 previous build.
@@ -449,7 +449,7 @@ to refer to the current interpreter location. By default, it is replaced with
 the current interpreter location.  The :option:`--executable` (or :option:`-e`)
 option will allow the interpreter path to be explicitly overridden.
 
-The :option:`scripts` option simply is a list of files to be handled in this
+The ``scripts`` option simply is a list of files to be handled in this
 way.  From the PyXML setup script::
 
     setup(...,
@@ -514,11 +514,11 @@ The corresponding call to :func:`setup` might be::
 Installing Additional Files
 ===========================
 
-The :option:`data_files` option can be used to specify additional files needed
+The ``data_files`` option can be used to specify additional files needed
 by the module distribution: configuration files, message catalogs, data files,
 anything which doesn't fit in the previous categories.
 
-:option:`data_files` specifies a sequence of (*directory*, *files*) pairs in the
+``data_files`` specifies a sequence of (*directory*, *files*) pairs in the
 following way::
 
     setup(...,
@@ -539,7 +539,7 @@ modules).  Each file name in *files* is interpreted relative to the
 directory information from *files* is used to determine the final location of
 the installed file; only the name of the file is used.
 
-You can specify the :option:`data_files` options as a simple sequence of files
+You can specify the ``data_files`` options as a simple sequence of files
 without specifying a target directory, but this is not recommended, and the
 :command:`install` command will print a warning in this case. To install data
 files directly in the target directory, an empty string should be given as the
@@ -650,7 +650,7 @@ information is sometimes used to indicate sub-releases.  These are
 1.0.1a2
     the second alpha release of the first patch version of 1.0
 
-:option:`classifiers` are specified in a Python list::
+``classifiers`` are specified in a Python list::
 
     setup(...,
           classifiers=[