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.)
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.
Issue1584 has implemented ways to specify non-standard Tcl and Tk include file and library locations, both via ./configure and as "make" arguments. Since there are many other issues open regarding specific aspects of setup.py and since, in nine years, there has has been no progress in addressing the more general concerns and since the intent is to phase out setup.py in general in future releases, I am going to close this issue as a duplicate of Issue1584.
History
Date
User
Action
Args
2022-04-11 14:56:09
admin
set
github: 41487
2013-11-12 08:05:23
ned.deily
set
status: open -> closedsuperseder: Mac OS X: building with X11 Tkinterversions: + Python 2.7, Python 3.3, Python 3.4, - Python 3.2nosy: + ned.deilymessages: + resolution: duplicatestage: resolved