I think setup.py needs major rework
I just submitted a bug report for setup.py: http://python.org/sf/1109602 It begins: 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. ... and ends: This might be an excellent sprint topic for PyCon. Skip
On Tuesday 25 January 2005 23:30, Skip Montanaro wrote:
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.
...
This might be an excellent sprint topic for PyCon.
Indeed it would be! -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>
Fred L. Drake, Jr. wrote:
On Tuesday 25 January 2005 23:30, Skip Montanaro wrote:
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.
...
This might be an excellent sprint topic for PyCon.
Indeed it would be!
... and now it is listed as one. Started a section on the sprint wiki page for orphaned sprint topics with a subsection on core stuff. Listed a rewrite of setup.py along with a rewrite of site.py and the usual bug/patch squashing. URL is http://www.python.org/moin/PyConDC2005/Sprints for those not wanting to go hunting for it. -Brett
Skip Montanaro <skip@pobox.com> writes:
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.
This may be more due to the complexity of distutils than to setup.py itself. Special cases are special cases, after all, e.g. look at Autotools. setup.py is billed as "Autodetecting setup.py script for building the Python extensions" but exactly how to override it without hacking it isn't very well documented, when possible at all. "Distributing Python Modules" helped me, but the reference section is missing, so it's utsl from there. So one improvement would be to better document overriding setup.py in README. Your solution may be as simple as adding to Makefile:342 (approx) --include-dirs=xxxx --library-dirs=yyyy where setup.py is called. (distutils/command/build_ext.py) *But* I suspect build() may not pass the options through to build_ext()! So, a config file approach: .../src/setup.cfg: [build_ext] include-dirs=xxxx library-dirs=yyyy In setup.py, PyBuildExt.build_extension() does most of the special casing. The last thing done is to call PyBuildExt.detect_tkinter() which handles a bunch of platform incompatibilities. e.g. # OpenBSD and FreeBSD use Tcl/Tk library names like libtcl83.a, but # the include subdirs are named like .../include/tcl8.3. If the previous ideas flub, you could hack your detect_tkinter() and append your include and lib dirs to inc_dirs and lib_dirs at the beginning of the method. All else fails, use Modules/Setup.dist to install Tcl/Tk? Or maybe symlink your non-standard location? -- KBK
participants (4)
-
Brett C. -
Fred L. Drake, Jr. -
kbk＠shore.net -
Skip Montanaro