[Python-checkins] CVS: distutils TODO,1.1,1.2

[Greg Ward]

Update of /cvsroot/python/distutils
In directory slayer.i.sourceforge.net:/tmp/cvs-serv9978

Modified Files:
	TODO 
Log Message:
Recently revived the to-do list after months of hibernation --
lots of additions and a few deletions.

Index: TODO
===================================================================
RCS file: /cvsroot/python/distutils/TODO,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -r1.1 -r1.2
*** TODO	1999/12/16 01:13:05	1.1
--- TODO	2000/06/02 02:09:53	1.2
***************
*** 2,14 ****
  -------
  
- * how to commands communicate non-option data amongst themselves?
-   eg. 'install_py' might want to ask 'build_py' which .py files
-   to install and compile -- how should that be handled (NB.
-   implies that 'build' must be run before 'install' is run,
-   can't just go by what's in the filesystem)
-   -> currently done by commands just knowing about each others'
-      options and methods; this seems to work, and I don't see
-      a need for further bureaucracy here
- 
  * I think fancy_getopt needs to get fancier to properly support the
    -I, -D, -l, -L, etc. options of "build_ext": need to be able
--- 2,5 ----
***************
*** 17,33 ****
    repetitions of the same option will accumulate or replace, etc.
  
  
  BUILD/INSTALL
  -------------
  
- * "site" vs "std" install directories need to be more symmetrical.
-   Perhaps:
-     'install_std_lib' and 'install_std_platlib'
-   vs
-     'install_site_lib' and 'install_site_platlib'
-   and when we know the installation scheme ('std' or 'site'), we pick
-   one of these pairs as 'install_lib' and 'install_platlib'.  Then
-   the install_* commands need only refer to 'install_lib' and
-   'install_platlib', and not worry about the installation scheme.
  
  
--- 8,93 ----
    repetitions of the same option will accumulate or replace, etc.
  
+ * do the above options even work at all?  seem to recall hearing
+   reports of dismal failure, but I never looked into it
+   [knowing how FancyGetopt works, there's no way these options
+   can work: damn]
+ 
+ * think about how to support distribution-specific "configure" commands --
+   eg. how can they push option values (include/library directories, that
+   sort of thing) onto the "build_ext" command?
+ 
+ * should/can the 'finalize_options()' methods be made more robust, so
+   you can sensibly call them multiple times?  this might be all that's
+   necessary to enable option-pushing...
+   [no: added reinitialize_command(), which *is* what's needed to enable
+    option-pushing]
+ 
+ * inconsistent use of -f (sdist vs bdist) -- force or format?
+ 
+ * fix UnixCCompiler so it doesn't depend on sysconfig (ie. cc must
+   be passed in)
+ 
+ * allow user to supply cc (compiler executable) in addition to
+   compiler type
+ 
+ * ?? add pre-processor interface to CCompiler ?? (needed to support
+   Autoconf-style 'try_cpp', 'search_cpp', 'search_headers' in config
+   commands)
+ 
+ * radically simplify CCompiler method signatures: drop most of the
+   per-invocation customization, and just use the instance
+   attributes for eg. include_dirs, libraries, ...
+ 
+ * need a good, general-purpose, portable-if-you-want-it, unportable-if-
+   you-need-control, way for the builder/installer to specify compiler
+   and linker flags (lots of people expect CFLAGS and LDFLAGS to work,
+   so they probably should; but options to either command and/or
+   build are the right way, so those should be preferred)
+ 
+ 
+ HELP
+ ----
+ 
+ * interface for "help about some option" -- eg. --help-compiler to
+   build_ext would list available compilers; --help-formats to "sdist"
+   or "bdist" would list available distribution formats; ...
+   [delegated to Rene Liebscher]
+ 
  
+ DOCS
+ ----
+ 
+ * write write write
+ 
+ * standard blurb for README files
+ 
+ 
+ 
  BUILD/INSTALL
  -------------
+ 
+ * if Distutils installs the first third-party modules in an installation
+   (and creates site-packages), then "install" needlessly warns about
+   having installed to a location not on sys.path -- presumably because
+   site-packages isn't in sys.path at startup, since it doesn't exist
+   until we create it!  (I think this is only a problem with 1.5.2,
+   since site-packages is now created when Python is installed -- check!)
+ 
+ * write a class Extension (name?) to hold all the information needed
+   to describe a single extension -- ie. replace the (ext_name, build_info)
+   tuple (particularly build_info!)
+   [done 2000/05/30 GPW]
+ 
+ * need a mechanism for specifying pre-install and post-install hooks,
+   which will be run when installing from a smart built distribution
+   (RPM, wininst, etc.); also, "install" needs to run these hooks
+   *except* for "fake" installs done solely to create a built distribution
+ 
+ * extension building on AIX
+ 
+ * bdist_dumb should grow a little intelligence: let packager choose whether
+   to make archive relative to prefix or the root (prefix is essential
+   for proper Windows support )
  
  
  
***************
*** 35,42 ****
--- 95,121 ----
  ------------------
  
+ * review and integrate cygwin patch from Rene Liebscher
+ 
  
+ DISTRIBUTIONS
+ -------------
+ 
+ * review/tweak bdist_rpm code from Harry Gebel (minor style issues, fix
+   hardcoded directories)
+   [done 2000/06/01 GPW, but in need of serious testing!]
+ 
+ * figure out why bdist_rpm doesn't work with RPM 2.x, and make it work if
+   possible
+ 
+ * make "bdist" take multiple formats (both for convenience
+   and consistency with "sdist"); should be doable now that we can
+   reinitialize, refinalize, and (presumably) rerun commands
+ 
+ 
  EXTERNAL DEPENDENCIES
  ---------------------
+ 
  * ??? do we need to implement autoconf in Python (shudder) ???
+ 
  * if not, how to handle the case of "if Tk present, build with it" in
    PIL, or "define HAVE_STRFTIME if we have strftime()" in mxDateTime"?