Python's setup.py has grown way out of control.  I'm
trying to build and install Python 2.4.0 on a Solaris
system with Tcl/Tk installed in a non-standard place and
I can't figure out the incantation to tell setup.py to look
where they are installed.  I have tried:

  * setting LDFLAGS and CPPFLAGS on the make and
  configure command lines

  * running "setup.py --help" and "setup.py build --help"

  * reading the setup.py source

It's not at all obvious to me from any of this if there is
any way to point setup.py at a non-standard place.

Over time setup.py has grown into the Python
equivalent of a configure script, but there's been
precious little refactoring, so there is stuff all over the
place to add this directory on that platform or try
different ad hoc solutions for various external packages
based upon common installation practices.  I think it's
time to rethink the function and organization of setup.py.

This might be an excellent sprint topic for PyCon.

Something like this works with Python 2.5
./configure LDFLAGS="-L/myplace/tcl8.4.14_gcc/lib/"\
                  CPPFLAGS="-I/myplace/tcl8.4.14_gcc/include/"

(Both tcl and tk librarys and headers are installed in these directories.)

Skip, did the suggestion work? or is this otherwise out of date for 3.2?

The bug reported by Skip looks like something to be done with ./configure.  When this is solved, I think this bug with its original title should be kept open.  Let’s refactor setup.py into something manageable and testable.