[Python-checkins] distutils2: Synchronize docs with pre-revert distutils docs

tarek.ziade python-checkins at python.org
Thu Aug 19 08:34:11 CEST 2010


tarek.ziade pushed 2ceac3adf248 to distutils2:

http://hg.python.org/distutils2/rev/2ceac3adf248
changeset:   526:2ceac3adf248
user:        ?ric Araujo <merwok at netwok.org>
date:        Mon Aug 09 07:08:33 2010 +0200
summary:     Synchronize docs with pre-revert distutils docs
files:       docs/source/apiref.rst, docs/source/builtdist.rst, docs/source/extending.rst, docs/source/index.rst, docs/source/setupscript.rst, docs/source/sourcedist.rst

diff --git a/docs/source/apiref.rst b/docs/source/apiref.rst
--- a/docs/source/apiref.rst
+++ b/docs/source/apiref.rst
@@ -21,7 +21,7 @@
 .. function:: setup(arguments)
 
    The basic do-everything function that does most everything you could ever ask
-   for from a Distutils method. See XXXXX
+   for from a Distutils method.
 
    The setup function takes a large number of arguments. These are laid out in the
    following table.
@@ -147,11 +147,11 @@
 In addition, the :mod:`distutils.core` module exposed a number of  classes that
 live elsewhere.
 
-* :class:`Extension` from :mod:`distutils.extension`
-
-* :class:`Command` from :mod:`distutils.cmd`
-
-* :class:`Distribution` from :mod:`distutils.dist`
+* :class:`~distutils.extension.Extension` from :mod:`distutils.extension`
+
+* :class:`~distutils.cmd.Command` from :mod:`distutils.cmd`
+
+* :class:`~distutils.dist.Distribution` from :mod:`distutils.dist`
 
 A short description of each of these follows, but see the relevant module for
 the full reference.
@@ -995,7 +995,7 @@
    errors are ignored (apart from being reported to ``sys.stdout`` if *verbose* is
    true).
 
-**\*\*** Some of this could be replaced with the shutil module? **\*\***
+.. XXX Some of this could be replaced with the shutil module?
 
 
 :mod:`distutils.file_util` --- Single file operations
@@ -1311,8 +1311,7 @@
   the "negative alias" of :option:`--verbose`, then :option:`--quiet` on the
   command line sets *verbose* to false.
 
-**\*\*** Should be replaced with :mod:`optik` (which is also now known as
-:mod:`optparse` in Python 2.3 and later). **\*\***
+.. XXX Should be replaced with :mod:`argparse`.
 
 
 .. function:: fancy_getopt(options, negative_opt, object, args)
@@ -1680,8 +1679,8 @@
 ===================================================================
 
 .. module:: distutils.cmd
-   :synopsis: This module provides the abstract base class Command. This class is subclassed
-              by the modules in the distutils.command  subpackage.
+   :synopsis: This module provides the abstract base class Command. This class
+              is subclassed by the modules in the distutils.command subpackage.
 
 
 This module supplies the abstract base class :class:`Command`.
@@ -1691,239 +1690,21 @@
 
    Abstract base class for defining command classes, the "worker bees" of the
    Distutils.  A useful analogy for command classes is to think of them as
-   subroutines with local variables called *options*.  The options are declared in
-   :meth:`initialize_options` and defined (given their final values) in
-   :meth:`finalize_options`, both of which must be defined by every command class.
-   The distinction between the two is necessary because option values might come
-   from the outside world (command line, config file, ...), and any options
-   dependent on other options must be computed after these outside influences have
-   been processed --- hence :meth:`finalize_options`.  The body of the subroutine,
-   where it does all its work based on the values of its options, is the
-   :meth:`run` method, which must also be implemented by every command class.
-
-   The class constructor takes a single argument *dist*, a  :class:`Distribution`
+   subroutines with local variables called *options*.  The options are declared
+   in :meth:`initialize_options` and defined (given their final values) in
+   :meth:`finalize_options`, both of which must be defined by every command
+   class.  The distinction between the two is necessary because option values
+   might come from the outside world (command line, config file, ...), and any
+   options dependent on other options must be computed after these outside
+   influences have been processed --- hence :meth:`finalize_options`.  The body
+   of the subroutine, where it does all its work based on the values of its
+   options, is the :meth:`run` method, which must also be implemented by every
+   command class.
+
+   The class constructor takes a single argument *dist*, a :class:`Distribution`
    instance.
 
 
-:mod:`distutils.command` --- Individual Distutils commands
-==========================================================
-
-.. module:: distutils.command
-   :synopsis: This subpackage contains one module for each standard Distutils command.
-
-
-.. % \subsubsection{Individual Distutils commands}
-.. % todo
-
-
-:mod:`distutils.command.bdist` --- Build a binary installer
-===========================================================
-
-.. module:: distutils.command.bdist
-   :synopsis: Build a binary installer for a package
-
-
-.. % todo
-
-
-:mod:`distutils.command.bdist_packager` --- Abstract base class for packagers
-=============================================================================
-
-.. module:: distutils.command.bdist_packager
-   :synopsis: Abstract base class for packagers
-
-
-.. % todo
-
-
-:mod:`distutils.command.bdist_dumb` --- Build a "dumb" installer
-================================================================
-
-.. module:: distutils.command.bdist_dumb
-   :synopsis: Build a "dumb" installer - a simple archive of files
-
-
-.. % todo
-
-
-:mod:`distutils.command.bdist_msi` --- Build a Microsoft Installer binary package
-=================================================================================
-
-.. module:: distutils.command.bdist_msi
-   :synopsis: Build a binary distribution as a Windows MSI file
-
-.. class:: bdist_msi(Command)
-
-   Builds a `Windows Installer`_ (.msi) binary package.
-
-   .. _Windows Installer: http://msdn.microsoft.com/en-us/library/cc185688(VS.85).aspx
-
-   In most cases, the ``bdist_msi`` installer is a better choice than the
-   ``bdist_wininst`` installer, because it provides better support for
-   Win64 platforms, allows administrators to perform non-interactive
-   installations, and allows installation through group policies.
-
-
-:mod:`distutils.command.bdist_rpm` --- Build a binary distribution as a Redhat RPM and SRPM
-===========================================================================================
-
-.. module:: distutils.command.bdist_rpm
-   :synopsis: Build a binary distribution as a Redhat RPM and SRPM
-
-
-.. % todo
-
-
-:mod:`distutils.command.bdist_wininst` --- Build a Windows installer
-====================================================================
-
-.. module:: distutils.command.bdist_wininst
-   :synopsis: Build a Windows installer
-
-
-.. % todo
-
-
-:mod:`distutils.command.sdist` --- Build a source distribution
-==============================================================
-
-.. module:: distutils.command.sdist
-   :synopsis: Build a source distribution
-
-
-.. % todo
-
-
-:mod:`distutils.command.build` --- Build all files of a package
-===============================================================
-
-.. module:: distutils.command.build
-   :synopsis: Build all files of a package
-
-
-.. % todo
-
-
-:mod:`distutils.command.build_clib` --- Build any C libraries in a package
-==========================================================================
-
-.. module:: distutils.command.build_clib
-   :synopsis: Build any C libraries in a package
-
-
-.. % todo
-
-
-:mod:`distutils.command.build_ext` --- Build any extensions in a package
-========================================================================
-
-.. module:: distutils.command.build_ext
-   :synopsis: Build any extensions in a package
-
-
-.. % todo
-
-
-:mod:`distutils.command.build_py` --- Build the .py/.pyc files of a package
-===========================================================================
-
-.. module:: distutils.command.build_py
-   :synopsis: Build the .py/.pyc files of a package
-
-
-.. % todo
-
-
-:mod:`distutils.command.build_scripts` --- Build the scripts of a package
-=========================================================================
-
-.. module:: distutils.command.build_scripts
-   :synopsis: Build the scripts of a package
-
-
-.. % todo
-
-
-:mod:`distutils.command.clean` --- Clean a package build area
-=============================================================
-
-.. module:: distutils.command.clean
-   :synopsis: Clean a package build area
-
-
-.. % todo
-
-
-:mod:`distutils.command.config` --- Perform package configuration
-=================================================================
-
-.. module:: distutils.command.config
-   :synopsis: Perform package configuration
-
-
-.. % todo
-
-
-:mod:`distutils.command.install` --- Install a package
-======================================================
-
-.. module:: distutils.command.install
-   :synopsis: Install a package
-
-
-.. % todo
-
-
-:mod:`distutils.command.install_data` --- Install data files from a package
-===========================================================================
-
-.. module:: distutils.command.install_data
-   :synopsis: Install data files from a package
-
-
-.. % todo
-
-
-:mod:`distutils.command.install_headers` --- Install C/C++ header files from a package
-======================================================================================
-
-.. module:: distutils.command.install_headers
-   :synopsis: Install C/C++ header files from a package
-
-
-.. % todo
-
-
-:mod:`distutils.command.install_lib` --- Install library files from a package
-=============================================================================
-
-.. module:: distutils.command.install_lib
-   :synopsis: Install library files from a package
-
-
-.. % todo
-
-
-:mod:`distutils.command.install_scripts` --- Install script files from a package
-================================================================================
-
-.. module:: distutils.command.install_scripts
-   :synopsis: Install script files from a package
-
-
-.. % todo
-
-
-:mod:`distutils.command.register` --- Register a module with the Python Package Index
-=====================================================================================
-
-.. module:: distutils.command.register
-   :synopsis: Register a module with the Python Package Index
-
-
-The ``register`` command registers the package with the Python Package  Index.
-This is described in more detail in :pep:`301`.
-
 .. % todo
 
 :mod:`distutils.command.check` --- Check the meta-data of a package
@@ -1939,25 +1720,23 @@
 
 .. % todo
 
-
 Creating a new Distutils command
 ================================
 
 This section outlines the steps to create a new Distutils command.
 
 A new command lives in a module in the :mod:`distutils.command` package. There
-is a sample template in that directory called  :file:`command_template`. Copy
+is a sample template in that directory called :file:`command_template`.  Copy
 this file to a new module with the same name as the new command you're
-implementing. This module should implement a class with the same name as the
-module (and the command). So, for instance, to create the command
+implementing.  This module should implement a class with the same name as the
+module (and the command).  So, for instance, to create the command
 ``peel_banana`` (so that users can run ``setup.py peel_banana``), you'd copy
-:file:`command_template`  to :file:`distutils/command/peel_banana.py`, then edit
+:file:`command_template` to :file:`distutils/command/peel_banana.py`, then edit
 it so that it's implementing the class :class:`peel_banana`, a subclass of
 :class:`distutils.cmd.Command`.
 
 Subclasses of :class:`Command` must define the following methods.
 
-
 .. method:: Command.initialize_options()
 
    Set default values for all the options that this command supports.  Note that
@@ -1979,22 +1758,259 @@
 
 .. method:: Command.run()
 
-   A command's raison d'etre: carry out the action it exists to perform, controlled
-   by the options initialized in :meth:`initialize_options`, customized by other
-   commands, the setup script, the command-line, and config files, and finalized in
-   :meth:`finalize_options`.  All terminal output and filesystem interaction should
-   be done by :meth:`run`.
-
-*sub_commands* formalizes the notion of a "family" of commands, eg. ``install``
-as the parent with sub-commands ``install_lib``, ``install_headers``, etc.  The
-parent of a family of commands defines *sub_commands* as a class attribute; it's
-a list of 2-tuples ``(command_name, predicate)``, with *command_name* a string
-and *predicate* an unbound method, a string or None. *predicate* is a method of
-the parent command that determines whether the corresponding command is
-applicable in the current situation.  (Eg. we ``install_headers`` is only
-applicable if we have any C header files to install.)  If *predicate* is None,
-that command is always applicable.
-
-*sub_commands* is usually defined at the \*end\* of a class, because predicates
-can be unbound methods, so they must already have been defined.  The canonical
-example is the :command:`install` command.
+   A command's raison d'etre: carry out the action it exists to perform,
+   controlled by the options initialized in :meth:`initialize_options`,
+   customized by other commands, the setup script, the command-line, and config
+   files, and finalized in :meth:`finalize_options`.  All terminal output and
+   filesystem interaction should be done by :meth:`run`.
+
+
+.. attribute:: Command.sub_commands
+
+   *sub_commands* formalizes the notion of a "family" of commands,
+   e.g. ``install`` as the parent with sub-commands ``install_lib``,
+   ``install_headers``, etc.  The parent of a family of commands defines
+   *sub_commands* as a class attribute; it's a list of 2-tuples ``(command_name,
+   predicate)``, with *command_name* a string and *predicate* a function, a
+   string or ``None``.  *predicate* is a method of the parent command that
+   determines whether the corresponding command is applicable in the current
+   situation.  (E.g. we ``install_headers`` is only applicable if we have any C
+   header files to install.)  If *predicate* is ``None``, that command is always
+   applicable.
+
+   *sub_commands* is usually defined at the *end* of a class, because
+   predicates can be methods of the class, so they must already have been
+   defined.  The canonical example is the :command:`install` command.
+
+
+:mod:`distutils.command` --- Individual Distutils commands
+==========================================================
+
+.. module:: distutils.command
+   :synopsis: This subpackage contains one module for each standard Distutils command.
+
+
+.. % \subsubsection{Individual Distutils commands}
+.. % todo
+
+
+:mod:`distutils.command.bdist` --- Build a binary installer
+===========================================================
+
+.. module:: distutils.command.bdist
+   :synopsis: Build a binary installer for a package
+
+
+.. % todo
+
+
+:mod:`distutils.command.bdist_packager` --- Abstract base class for packagers
+=============================================================================
+
+.. module:: distutils.command.bdist_packager
+   :synopsis: Abstract base class for packagers
+
+
+.. % todo
+
+
+:mod:`distutils.command.bdist_dumb` --- Build a "dumb" installer
+================================================================
+
+.. module:: distutils.command.bdist_dumb
+   :synopsis: Build a "dumb" installer - a simple archive of files
+
+
+.. % todo
+
+
+:mod:`distutils.command.bdist_msi` --- Build a Microsoft Installer binary package
+=================================================================================
+
+.. module:: distutils.command.bdist_msi
+   :synopsis: Build a binary distribution as a Windows MSI file
+
+.. class:: bdist_msi(Command)
+
+   Builds a `Windows Installer`_ (.msi) binary package.
+
+   .. _Windows Installer: http://msdn.microsoft.com/en-us/library/cc185688(VS.85).aspx
+
+   In most cases, the ``bdist_msi`` installer is a better choice than the
+   ``bdist_wininst`` installer, because it provides better support for
+   Win64 platforms, allows administrators to perform non-interactive
+   installations, and allows installation through group policies.
+
+
+:mod:`distutils.command.bdist_rpm` --- Build a binary distribution as a Redhat RPM and SRPM
+===========================================================================================
+
+.. module:: distutils.command.bdist_rpm
+   :synopsis: Build a binary distribution as a Redhat RPM and SRPM
+
+
+.. % todo
+
+
+:mod:`distutils.command.bdist_wininst` --- Build a Windows installer
+====================================================================
+
+.. module:: distutils.command.bdist_wininst
+   :synopsis: Build a Windows installer
+
+
+.. % todo
+
+
+:mod:`distutils.command.sdist` --- Build a source distribution
+==============================================================
+
+.. module:: distutils.command.sdist
+   :synopsis: Build a source distribution
+
+
+.. % todo
+
+
+:mod:`distutils.command.build` --- Build all files of a package
+===============================================================
+
+.. module:: distutils.command.build
+   :synopsis: Build all files of a package
+
+
+.. % todo
+
+
+:mod:`distutils.command.build_clib` --- Build any C libraries in a package
+==========================================================================
+
+.. module:: distutils.command.build_clib
+   :synopsis: Build any C libraries in a package
+
+
+.. % todo
+
+
+:mod:`distutils.command.build_ext` --- Build any extensions in a package
+========================================================================
+
+.. module:: distutils.command.build_ext
+   :synopsis: Build any extensions in a package
+
+
+.. % todo
+
+
+:mod:`distutils.command.build_py` --- Build the .py/.pyc files of a package
+===========================================================================
+
+.. module:: distutils.command.build_py
+   :synopsis: Build the .py/.pyc files of a package
+
+
+.. class:: build_py(Command)
+
+
+:mod:`distutils.command.build_scripts` --- Build the scripts of a package
+=========================================================================
+
+.. module:: distutils.command.build_scripts
+   :synopsis: Build the scripts of a package
+
+
+.. % todo
+
+
+:mod:`distutils.command.clean` --- Clean a package build area
+=============================================================
+
+.. module:: distutils.command.clean
+   :synopsis: Clean a package build area
+
+
+.. % todo
+
+
+:mod:`distutils.command.config` --- Perform package configuration
+=================================================================
+
+.. module:: distutils.command.config
+   :synopsis: Perform package configuration
+
+
+.. % todo
+
+
+:mod:`distutils.command.install` --- Install a package
+======================================================
+
+.. module:: distutils.command.install
+   :synopsis: Install a package
+
+
+.. % todo
+
+
+:mod:`distutils.command.install_data` --- Install data files from a package
+===========================================================================
+
+.. module:: distutils.command.install_data
+   :synopsis: Install data files from a package
+
+
+.. % todo
+
+
+:mod:`distutils.command.install_headers` --- Install C/C++ header files from a package
+======================================================================================
+
+.. module:: distutils.command.install_headers
+   :synopsis: Install C/C++ header files from a package
+
+
+.. % todo
+
+
+:mod:`distutils.command.install_lib` --- Install library files from a package
+=============================================================================
+
+.. module:: distutils.command.install_lib
+   :synopsis: Install library files from a package
+
+
+.. % todo
+
+
+:mod:`distutils.command.install_scripts` --- Install script files from a package
+================================================================================
+
+.. module:: distutils.command.install_scripts
+   :synopsis: Install script files from a package
+
+
+.. % todo
+
+
+:mod:`distutils.command.register` --- Register a module with the Python Package Index
+=====================================================================================
+
+.. module:: distutils.command.register
+   :synopsis: Register a module with the Python Package Index
+
+
+The ``register`` command registers the package with the Python Package  Index.
+This is described in more detail in :pep:`301`.
+
+.. % todo
+
+:mod:`distutils.command.check` --- Check the meta-data of a package
+===================================================================
+
+.. module:: distutils.command.check
+   :synopsis: Check the metadata of a package
+
+
+The ``check`` command performs some tests on the meta-data of a package.
+For example, it verifies that all required meta-data are provided as
+the arguments passed to the :func:`setup` function.
diff --git a/docs/source/builtdist.rst b/docs/source/builtdist.rst
--- a/docs/source/builtdist.rst
+++ b/docs/source/builtdist.rst
@@ -146,8 +146,8 @@
 Creating dumb built distributions
 =================================
 
-**\*\*** Need to document absolute vs. prefix-relative packages here, but first
-I have to implement it! **\*\***
+.. XXX Need to document absolute vs. prefix-relative packages here, but first
+       I have to implement it!
 
 
 .. _creating-rpms:
@@ -176,7 +176,7 @@
 explicitly specify multiple :command:`bdist_\*` commands and their options::
 
    python setup.py bdist_rpm --packager="John Doe <jdoe at example.org>" \
-                   bdist_wininst --target_version="2.0"
+                   bdist_wininst --target-version="2.0"
 
 Creating RPM packages is driven by a :file:`.spec` file, much as using the
 Distutils is driven by the setup script.  To make your life easier, the
@@ -322,7 +322,7 @@
 option.
 
 By default the installer will display the cool "Python Powered" logo when it is
-run, but you can also supply your own bitmap which must be a Windows
+run, but you can also supply your own 152x261 bitmap which must be a Windows
 :file:`.bmp` file with the :option:`--bitmap` option.
 
 The installer will also display a large title on the desktop background window
@@ -375,7 +375,7 @@
 The Postinstallation script
 ---------------------------
 
-Starting with Python 2.3, a postinstallation script can be specified which the
+Starting with Python 2.3, a postinstallation script can be specified with the
 :option:`--install-script` option.  The basename of the script must be
 specified, and the script filename must also be listed in the scripts argument
 to the setup function.
diff --git a/docs/source/extending.rst b/docs/source/extending.rst
--- a/docs/source/extending.rst
+++ b/docs/source/extending.rst
@@ -15,8 +15,8 @@
 should be copied into packages in addition to :file:`.py` files as a
 convenience.
 
-Most distutils command implementations are subclasses of the :class:`Command`
-class from :mod:`distutils.cmd`.  New commands may directly inherit from
+Most distutils command implementations are subclasses of the
+:class:`distutils.cmd.Command` class.  New commands may directly inherit from
 :class:`Command`, while replacements often derive from :class:`Command`
 indirectly, directly subclassing the command they are replacing.  Commands are
 required to derive from :class:`Command`.
@@ -94,61 +94,3 @@
 should still be added to represent what would have been created.
 
 
-Creating a new Distutils command
-================================
-
-This section outlines the steps to create a new Distutils command.
-
-A new command lives in a module in the :mod:`distutils.command` package. There
-is a sample template in that directory called  :file:`command_template`. Copy
-this file to a new module with the same name as the new command you're
-implementing. This module should implement a class with the same name as the
-module (and the command). So, for instance, to create the command
-``peel_banana`` (so that users can run ``setup.py peel_banana``), you'd copy
-:file:`command_template`  to :file:`distutils/command/peel_banana.py`, then edit
-it so that it's implementing the class :class:`peel_banana`, a subclass of
-:class:`distutils.cmd.Command`.
-
-Subclasses of :class:`Command` must define the following methods.
-
-
-.. method:: Command.initialize_options()
-
-   Set default values for all the options that this command supports.  Note that
-   these defaults may be overridden by other commands, by the setup script, by
-   config files, or by the command-line.  Thus, this is not the place to code
-   dependencies between options; generally, :meth:`initialize_options`
-   implementations are just a bunch of ``self.foo = None`` assignments.
-
-
-.. method:: Command.finalize_options()
-
-   Set final values for all the options that this command supports. This is
-   always called as late as possible, ie.  after any option assignments from the
-   command-line or from other commands have been done.  Thus, this is the place
-   to to code option dependencies: if *foo* depends on *bar*, then it is safe to
-   set *foo* from *bar* as long as *foo* still has the same value it was
-   assigned in :meth:`initialize_options`.
-
-
-.. method:: Command.run()
-
-   A command's raison d'etre: carry out the action it exists to perform, controlled
-   by the options initialized in :meth:`initialize_options`, customized by other
-   commands, the setup script, the command-line, and config files, and finalized in
-   :meth:`finalize_options`.  All terminal output and filesystem interaction should
-   be done by :meth:`run`.
-
-*sub_commands* formalizes the notion of a "family" of commands, eg. ``install``
-as the parent with sub-commands ``install_lib``, ``install_headers``, etc.  The
-parent of a family of commands defines *sub_commands* as a class attribute; it's
-a list of 2-tuples ``(command_name, predicate)``, with *command_name* a string
-and *predicate* an unbound method, a string or None. *predicate* is a method of
-the parent command that determines whether the corresponding command is
-applicable in the current situation.  (Eg. we ``install_headers`` is only
-applicable if we have any C header files to install.)  If *predicate* is None,
-that command is always applicable.
-
-*sub_commands* is usually defined at the \*end\* of a class, because predicates
-can be unbound methods, so they must already have been defined.  The canonical
-example is the :command:`install` command.
diff --git a/docs/source/index.rst b/docs/source/index.rst
--- a/docs/source/index.rst
+++ b/docs/source/index.rst
@@ -1,12 +1,18 @@
-.. Distutils2 documentation master file, created by
-   sphinx-quickstart on Sun Feb 28 15:23:06 2010.
-   You can adapt this file completely to your liking, but it should at least
-   contain the root `toctree` directive.
+.. _distutils-index:
 
-Welcome to Distutils2's documentation!
-======================================
+###############################
+  Distributing Python Modules
+###############################
 
-Contents:
+:Authors: Greg Ward, Anthony Baxter
+:Email: distutils-sig at python.org
+:Release: |version|
+:Date: |today|
+
+This document describes the Python Distribution Utilities ("Distutils") from
+the module developer's point of view, describing how to use the Distutils to
+make Python modules and extensions easily available to a wider audience with
+very little overhead for build/release/install mechanics.
 
 .. toctree::
    :maxdepth: 2
@@ -22,14 +28,4 @@
    examples.rst
    extending.rst
    commandref.rst
-   metadata.rst
-   devresources.rst
    apiref.rst
-
-Indices and tables
-==================
-
-* :ref:`genindex`
-* :ref:`modindex`
-* :ref:`search`
-
diff --git a/docs/source/setupscript.rst b/docs/source/setupscript.rst
--- a/docs/source/setupscript.rst
+++ b/docs/source/setupscript.rst
@@ -207,7 +207,7 @@
 SWIG on the interface file and compile the resulting C/C++ file into your
 extension.
 
-**\*\*** SWIG support is rough around the edges and largely untested! **\*\***
+.. XXX SWIG support is rough around the edges and largely untested!
 
 This warning notwithstanding, options to SWIG can be currently passed like
 this::
@@ -326,7 +326,7 @@
 (Again, this sort of non-portable construct should be avoided if you intend to
 distribute your code.)
 
-**\*\*** Should mention clib libraries here or somewhere else! **\*\***
+.. XXX Should mention clib libraries here or somewhere else!
 
 
 Other options
diff --git a/docs/source/sourcedist.rst b/docs/source/sourcedist.rst
--- a/docs/source/sourcedist.rst
+++ b/docs/source/sourcedist.rst
@@ -76,10 +76,7 @@
   :option:`packages` options
 
 * all C source files mentioned in the :option:`ext_modules` or
-  :option:`libraries` options (
-
-  **\*\*** getting C library sources currently broken---no
-  :meth:`get_source_files` method in :file:`build_clib.py`! **\*\***)
+  :option:`libraries` options
 
 * scripts identified by the :option:`scripts` option
   See :ref:`distutils-installing-scripts`.
@@ -137,20 +134,12 @@
 :option:`--no-defaults` and :option:`--no-prune` to disable the standard
 "include" and "exclude" sets.
 
-Second, you might want to force the manifest to be regenerated---for example, if
-you have added or removed files or directories that match an existing pattern in
-the manifest template, you should regenerate the manifest::
-
-   python setup.py sdist --force-manifest
-
-Or, you might just want to (re)generate the manifest, but not create a source
-distribution::
+Second, you might just want to (re)generate the manifest, but not create a
+source distribution::
 
    python setup.py sdist --manifest-only
 
-:option:`--manifest-only` implies :option:`--force-manifest`. :option:`-o` is a
-shortcut for :option:`--manifest-only`, and :option:`-f` for
-:option:`--force-manifest`.
+:option:`-o` is a sortcut for :option:`--manifest-only`.
 
 .. _manifest_template:
 

--
Repository URL: http://hg.python.org/distutils2


More information about the Python-checkins mailing list