Mailman 3 March 2000 - Distutils-SIG

build_ext.py rev 1.27 :distutils broken
by Joe Van Andel 30 Mar '00

30 Mar '00

I updated my distutils from cvs and installed them. Now, when I try to build my application, I get: =========================================================== running build_ext Traceback (innermost last): File "setup.py", line 69, in ? ext_modules = [ File "/usr/lib/python1.5/site-packages/distutils/core.py", line 98, in setup dist.run_commands () File "/usr/lib/python1.5/site-packages/distutils/core.py", line 533, in run_co mmands self.run_command (cmd) File "/usr/lib/python1.5/site-packages/distutils/core.py", line 582, in run_co mmand cmd_obj.run () File "/usr/lib/python1.5/site-packages/distutils/command/install.py", line 364 , in run self.run_peer ('build') File "/usr/lib/python1.5/site-packages/distutils/core.py", line 899, in run_pe er self.distribution.run_command (command) File "/usr/lib/python1.5/site-packages/distutils/core.py", line 582, in run_co mmand cmd_obj.run () File "/usr/lib/python1.5/site-packages/distutils/command/build.py", line 95, i n run self.run_peer ('build_ext') File "/usr/lib/python1.5/site-packages/distutils/core.py", line 899, in run_pe er self.distribution.run_command (command) File "/usr/lib/python1.5/site-packages/distutils/core.py", line 582, in run_co mmand cmd_obj.run () File "/usr/lib/python1.5/site-packages/distutils/command/build_ext.py", line 1 92, in run self.build_extensions () TypeError: not enough arguments; expected 2, got 1 ========================================================================= cvs diff -r1.25 build_ext.py shows (among other differences): # Now actually compile and link everything. - self.build_extensions (self.extensions) + self.build_extensions () Restoring the old version of this line seems to fix the problem. Not to be picky, but I'd certainly appreciate better regression testing on distutils, so these trival errors don't occur. Would you consider tagging CVS revisions for additional sub-releases, like Distutils_0_1_3a, so we'd know what it likely to be stable? As it is, I think I'll have to save a working copy of distutils, before I update from CVS. -- Joe VanAndel National Center for Atmospheric Research http://www.atd.ucar.edu/~vanandel/ Internet: vanandel(a)ucar.edu

2 1

Distutils now in Python CVS tree
by Greg Ward 29 Mar '00

29 Mar '00

Hi all -- Distutils is now available through the Python CVS tree *in addition to its own CVS tree*. That is, if you keep on top of developments in the Python CVS tree, then you will be tracking the latest Distutils code in Lib/distutils. Or, you can keep following the Distutils through its own CVS tree. (This is all done through one itty-bitty little symlink in the CNRI CVS repository, and It Just Works. Cool.) Note that only the 'distutils' subdirectory of the distutils distribution is tracked by Python: that is, changes to the documentation, test suites, and example setup scripts are *not* reflected in the Python CVS tree. If you follow neither Python nor Distutils CVS updates, this doesn't affect you. If you've been following Distutils CVS updates, you can continue to do so as you've always done (and as is documented on the Distutils "Anonymous CVS" web page). If you've been following Python CVS updates, then you are now following most Distutils CVS updates too -- as long as you do "cvs update -d", of course. If you're interested in following updates in the Distutils documentation, tests, examples, etc. then you should follow the Distutils CVS tree directly. If you've been following *both* Python and Distutils CVS updates, and hacking on the Distutils, then you should pick one or the other as your working directory. If you submit patches, it doesn't really matter if they're relative to the top of the Python tree, the top of the Distutils tree, or what -- I'll probably figure it out. However, it's probably best to continue sending Distutils patches to distutils-sig(a)python.org, *or* direct to me (gward(a)python.net) for trivial patches. Unless Guido says otherwise, I don't see a compelling reason to send Distutils patches to patches(a)python.org. In related news, the distutils-checkins list is probably going to go away, and all Distutils checkin messages will go python-checkins instead. Let me know if you avidly follow distutils-checkins, but do *not* want to follow python-checkins -- if lots of people respond (doubtful, as distutils-checkins only had 3 subscribers last I checked!), we'll reconsider. Greg

2 1

Problems on NT
by Thomas Heller 29 Mar '00

29 Mar '00

1. msvccompiler.py defines a method _find_exe(), but uses find_exe(). 2. The python/libs directory is no longer included in library_dirs when linking extensions. Thomas Heller

3 3

patch to change order of -I's in build_ext.py
by Les Schaffer 28 Mar '00

28 Mar '00

the following one line patch fixes a problem when using distutils to build CVS releases of Numerical Python. what was happening is this: changes were being made to the Numeric API -- changes reflected in the .h files in subdir Include -- but the distutils script build_ext.py was placing -I/usr/include/python1.5 __before__ the local -IInclude, hence killing the compile process when API changes occured. the change below adds -I/usr/include/python1.5 to the end of the list self.include_dir rather than the beginning. perhaps you pros in distutils SIG have a better fix than this hack??? les schaffer *** build_ext.py~ Sun Jan 30 13:34:12 2000 --- build_ext.py Tue Mar 28 13:30:03 2000 *************** *** 99,105 **** self.include_dirs = string.split (self.include_dirs, os.pathsep) ! self.include_dirs.insert (0, py_include) if exec_py_include != py_include: self.include_dirs.insert (0, exec_py_include) --- 99,105 ---- self.include_dirs = string.split (self.include_dirs, os.pathsep) ! self.include_dirs.append(py_include) if exec_py_include != py_include: self.include_dirs.insert (0, exec_py_include)

2 1

More problems?
by Thomas Heller 28 Mar '00

28 Mar '00

How is the --library_dirs resp. -L option supposed to be used? When I type python setup.py install build_ext -L=./Libs I get the following linker command line: ... /LIBPATH:= /LIBPATH:. /LIBPATH:/ /LIBPATH:L /LIBPATH:i (and so on) Thomas Heller

2 1

mkpath patch
by Bastian Kleineidam 28 Mar '00

28 Mar '00

Hello, this patch lets the mkpath() function return all created directories. You will need that if you want to generate a list of installed files and directories. Bastian

2 1

Optimize patch
by Bastian Kleineidam 28 Mar '00

28 Mar '00

Hello, I found this in compileall.py. We can tell if we run under python -O by looking at __builtin__.__debug__. Bastian Kleineidam

2 1

Installation: new code, new docs
by Greg Ward 28 Mar '00

28 Mar '00

Hi all -- I've just checked in a bunch of changes to the 'install' command, the net effect of which is that it now WORKS. (In case you hadn't been paying attention, I checked in a version several weeks ago that was only half-finished and has since been abandoned.) If you're interested in playing around: first, read the docs, which are also a complete rewrite. This is the nucleus of the "Installing Python Modules" manual; so far, it only covers "alternate" and "custom" installation. ("Standard" installation is pretty obvious, and anyone reading this sig should know what that means... does need to be documented, though!) Documentation is at http://www.python.org/sigs/distutils-sig/documentation.html Code is in the CVS tree of course, and I've just put out a new snapshot to celebrate the occasion: http://www.python.org/sigs/distutils-sig/implementation.html Enjoy! Greg -- Greg Ward - Linux geek gward(a)python.net http://starship.python.net/~gward/ I am NOT a nut....

3 7

Opinion on uninstall
by Bastian Kleineidam 24 Mar '00

24 Mar '00

Hello, here are some thoughts about an uninstall enhancement. If you supply it as an option to install.py (e.g. --create-uninstall), you can not be sure that the user always turns this option on. Suppose he ran the install command without --create-uninstall and some files got installed. Now he runs it again, but with --create-uninstall. The result is that no new files will be copied and the file list of (newly) installed files is empty. So your package list of installed files is empty and therefore incorrect. Solution: either you turn on self.force or you dont supply an option and write the package list every time you run the install command. I like the second solution more. A second problem with installation of Debian packages: I can install everything in `pwd`/debian/tmp with --home or supply my own install directories. But then the uninstall information is incorrect. When the Debian package gets installed the package files are still pointing to `pwd`/debian/tmp. This is the point where my --destdir=<destpath> option kicks in. The destpath prefix gets stripped off the package file list. If I run "./setup.py install --destdir=`pwd`/debian/tmp" a file installed as "`pwd`/debian/tmp/usr/lib/python1.5/foo.py" is listed in the package file list as "/usr/lib/python1.5/foo.py". Greetings, Bastian

1 0

_nt_quote_args patch
by Bastian Kleineidam 24 Mar '00

24 Mar '00

Hello, You should return the args variable in _nt_quote_args, not None. Bastian Kleineidam diff -rc distutils.orig/distutils/spawn.py distutils.quote/distutils/spawn.py *** distutils.orig/distutils/spawn.py Thu Mar 23 11:36:18 2000 --- distutils.quote/distutils/spawn.py Thu Mar 23 13:02:47 2000 *************** *** 55,61 **** for i in range (len (args)): if string.find (args[i], ' ') != -1: args[i] = '"%s"' % args[i] ! return def _spawn_nt (cmd, search_path=1, --- 55,61 ---- for i in range (len (args)): if string.find (args[i], ' ') != -1: args[i] = '"%s"' % args[i] ! return args def _spawn_nt (cmd, search_path=1,

1 0