Mailman 3 June 2000 - Distutils-SIG

One last code snapshot...
by Greg Ward 29 Jun '00

29 Jun '00

...before I throw together Distutils 0.9. I expect the code will be identical, unless I find bugs in the process of putting 0.9 together. So this is really a formality. Still, give it a pounding -- I don't imagine 0.9 will be really out for several hours. Greg PS. http://starship.python.net/~gward/python/distutils.html -- Greg Ward - Unix bigot gward(a)python.net http://starship.python.net/~gward/ I'd like some JUNK FOOD ... and then I want to be ALONE --

1 0

winreg module changes
by Fred L. Drake, Jr. 29 Jun '00

29 Jun '00

Greg, Windows users, etc.: I just checked in the changes for winreg so that an object-oriented interface is presented to the user. This affects the distutils on Windows; if someone who knows about this stuff can update the winreg use, it would be really good to get that in tonight or first thing tomorrow morning! -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member

2 5

New code snapshot
by Greg Ward 29 Jun '00

29 Jun '00

Title says it all. Fixes the bugs Harry spotted. The URL is http://starship.python.net/~gward/python/distutils.html OK, 0.9 release tomorrow night fer shure... (famous last words...) Greg -- Greg Ward - geek-on-the-loose gward(a)python.net http://starship.python.net/~gward/ Could I have a drug overdose?

1 0

Some patches
by Harry Henry Gebel 29 Jun '00

29 Jun '00

I have put a few patches up on the SourceForge patch manager. The first patch prunes CVS files and directories from source distributions. (Making a source distribution of the Distutils was failing because it kept putting 'misc/CVS' into MANIFEST. Of course, this wouldn't effect somebody who wasn't using the CVS Distutils.) The second patch fixes a problem that you could not build source distributions for packages that use the old-style way of specifying extensions. The third patch is for the examples directory. It updates the pil and xml setup scripts to use new-style extensions and fixes a bug in the mxDateTime setup script (which uses new-style extensions but did not import the Extension class.) -- Harry Henry Gebel, Senior Developer, Landon House SBS ICQ# 76308382 West Dover Hundred, Delaware

2 1

Comments on bdist_wininst
by Greg Ward 29 Jun '00

29 Jun '00

Howdy -- OK, I'm looking through bdist_wininst.py right now. About all I've fixed so far are typos in comments, and changed it to use 'reinitialize_command()' -- thanks to Bastian for spotting that one (and prodding me into reviewing the code). Some thoughts... these are mostly idle speculation, because I really can't see anything wrong with the code! * should we change ImportError on zlib to DistutilsPlatformError (or something) that generates a friendlier error message... or is this being silly because zlib is absolutely positively always available for Python on Windows? * is "foo-1.0.win32.exe" the right filename for the installer? this is consistent with "dumb" build distributions (simple tarballs and ZIP files) as well as RPMs, so that's a good enough argument for me. * "win32" is hard-coded in a few spots: should that be 'get_platform()' (which now just returns sys.platform)? (I don't remember what the decision on sys.platform for 64-bit Windows was: is it going to return "win32"?) Other than it looks good. I'll see if I can't produce an installer for the Distutils tonight -- that would be, as they say, THE BOMB. ;-) Greg -- Greg Ward - maladjusted nerd gward(a)python.net http://starship.python.net/~gward/ If it can't be expressed in figures, it is not science--it is opinion.

2 2

Another code snapshot
by Greg Ward 28 Jun '00

28 Jun '00

OK, tonight's changes were worth another code snapshot. You'll find it on my Starship page, at: http://starship.python.net/~gward/python/distutils.html Distutils code snapshots will be distributed from there until further notice (ie., until I get back write access to python.org!). Changes: * minor tweakage to bdist_wininst.py: please try it out and make sure I didn't make any stupid typos * added C source for Thomas' installer in "misc" -- note that this is *not* yet in CVS, as I was (and am) unsure of the right way to handle DOS text files -- have to check the CVS book tomorrow * added Lyle Johnson's bcppcompiler.py to support Borland C++ Note that bcppcompiler.py doesn't actually work: Lyle reports a very odd problem when spawning the linker. I'm sure he'd gladly welcome debugging help, and I'd really like to see support for Borland's compiler working too. See the comment I added to the source for details. Please, everyone bash this code mercilessly. I'm planning to release Distutils 0.9 tomorrow or Thursday night, so that there's a real release out there a few days before Guido release Python 1.6b1 -- that way, if any real bone-headed mistakes have slipped in, we have a chance to fix 'em. Greg -- Greg Ward - maladjusted nerd gward(a)python.net http://starship.python.net/~gward/ The NSA. We care: we listen to our customers.

1 0

Better support for compiler temp dirs
by Greg Ward 28 Jun '00

28 Jun '00

I just got the Lyle Johnson's current patch for supporting Borland C++. One thing he added is a 'build_temp' parameter to the 'link_*()' methods of the CCompiler interface. This seems reasonable to me, so I'm going to check it in as-is. However, BCPPCompiler is the only compiler class to do anything with 'build_temp'. Strikes me as irrelevant for UnixCCompiler, but could very well be useful for MSVCCompiler: the issue of linker turds has been hacked around in the 'msvc_prelink_hack()' method, but is there a nicer way to do it? Possibly. This change might reduce the amount of code in that hack method, which would be a good thing. Anyone want to take a look at this and see if we can lighten the load of 'msvc_prelink_hack()' by using the 'build_temp' parameter to 'link_*()'? Thanks in advance! Greg -- Greg Ward - Unix geek gward(a)python.net http://starship.python.net/~gward/ Never put off till tomorrow what you can put off till the day after tomorrow.

1 0

Duelling SWIG patches
by Greg Ward 27 Jun '00

27 Jun '00

Well, I was inspired by Thomas' patch for SWIG support to come up with my own patch. Here it is: completely untested, so I haven't checked it in yet. (I don't have SWIG installed at home, so I figured I'd let someone Out There who actually uses it test this for me. Remember: laziness is a virtue!) Note that Thomas' patch was Windows/C++-centric; mine tries to be OS-agnostic, but is C-centric. Is it possible to tell from a SWIG .i file whether it is destined to be C or C++? I can't think of a good way to do it, but then my knowledge if SWIG is roughly epsilon. (Out of curiosity, I took the manual home and read it about three years ago. It struck me as being *way* to easy, and I wanted to write Perl extensions like a *real* man. Ahh, the folly of youth...) Here's da patch: =================================================================== RCS file: /cvsroot/python/distutils/distutils/command/build_ext.py,v retrieving revision 1.43 diff -u -r1.43 build_ext.py --- build_ext.py 2000/06/17 23:04:31 1.43 +++ build_ext.py 2000/06/22 01:30:49 @@ -367,12 +367,13 @@ else: self.announce ("building '%s' extension" % ext.name) - # First step: compile the source code to object files. This - # drops the object files in the current directory, regardless - # of where the source is (may be a bad thing, but that's how a - # Makefile.pre.in-based system does it, so at least there's a - # precedent!) + # First, scan the sources for SWIG definition files (.i), run + # SWIG on 'em to create .c files, and modify the sources list + # accordingly. + sources = self.swig_sources(sources) + # Next, compile the source code to object files. + # XXX not honouring 'define_macros' or 'undef_macros' -- the # CCompiler API needs to change to accomodate this, and I # want to do one thing at a time! @@ -428,6 +429,74 @@ # build_extensions () + + def swig_sources (self, sources): + + """Walk the list of source files in 'sources', looking for SWIG + interface (.i) files. Run SWIG on all that are found, and + return a modified 'sources' list with SWIG source files replaced + by the generated C (or C++) files. + """ + + new_sources = [] + swig_sources = [] + swig_targets = {} + + # XXX this drops generated C files into the source tree, which + # is fine for developers who want to distribute the generated + # source -- but there should be an option to put SWIG output in + # the temp dir. + + for source in sources: + (base, ext) = os.path.splitext(source) + if ext in self.swig_ext(): + new_sources.append(base + ".c") # umm, what if it's C++? + swig_files.append(source) + swig_targets[source] = new_sources[-1] + else: + new_sources.append(source) + + if not swig_files: + return new_sources + + swig = self.find_swig() + swig_cmd = [swig, "-python", "-dnone", "-ISWIG"] # again, C++?!? + + for source in swig_sources: + self.announce ("swigging %s to %s" % (src, obj)) + self.spawn(swig_cmd + ["-o", swig_targets[source], source]) + + return new_sources + + # swig_sources () + + def find_swig (self): + """Return the name of the SWIG executable. On Unix, this is + just "swig" -- it should be in the PATH. Tries a bit harder on + Windows. + """ + + if os.name == "posix": + return "swig" + elif os.name == "nt": + + # Look for SWIG in its standard installation directory on + # Windows (or so I presume!). If we find it there, great; + # if not, act like Unix and assume it's in the PATH. + for vers in ("1.3", "1.2", "1.1"): + fn = os.path.join("c:\\swig%s" % vers, "swig.exe") + if os.path.isfile (fn): + return fn + else: + return "swig.exe" + + else: + raise DistutilsPlatformError, \ + ("I don't know how to find (much less run) SWIG " + "on platform '%s'") % os.name + + # find_swig () + # -- Hooks --------------------------------------------------------- ======================================================================== Greg -- Greg Ward - Unix geek gward(a)python.net http://starship.python.net/~gward/ All right, you degenerates! I want this place evacuated in 20 seconds!

3 6

Example of "config" command
by Greg Ward 27 Jun '00

27 Jun '00

Oh, here's an example of how easy it is to autoconfigure Python extensions now. This is taken from examples/mxdatetime_setup.py; here're the essentials 'run()' method of the "config_mxDateTime" command class: def run (self): have = {} have['strftime'] = self.check_func('strftime', ['time.h']) have['strptime'] = self.check_func('strptime', ['time.h']) have['timegm'] = self.check_func('timegm', ['time.h']) define = [] undef = [] for name in have.keys(): # ('strftime', 'strptime', 'timegm'): macro_name = 'HAVE_' + string.upper(name) if have[name]: define.append((macro_name, None)) else: undef.append(macro_name) Note that the bulk of the code is the bureaucracy of figuring out which macros to define, ie. generateing HAVE_STRFTIME and friends. Obviously this could (and should) be taken care of by the standard "config" command; we'll get there! Here's the output of "setup.py config" (very noisy because --noisy and --dump-source are both enabled by default for now): running config compiling '_configtest.c': #include <time.h> int main () { strftime; } gcc -c -g -O2 -fPIC _configtest.c -o _configtest.o gcc _configtest.o -o _configtest success! removing: _configtest.c _configtest.o _configtest compiling '_configtest.c': #include <time.h> int main () { strptime; } gcc -c -g -O2 -fPIC _configtest.c -o _configtest.o _configtest.c: In function `main': _configtest.c:4: `strptime' undeclared (first use in this function) _configtest.c:4: (Each undeclared identifier is reported only once _configtest.c:4: for each function it appears in.) failure. removing: _configtest.c _configtest.o compiling '_configtest.c': #include <time.h> int main () { timegm; } gcc -c -g -O2 -fPIC _configtest.c -o _configtest.o gcc _configtest.o -o _configtest success! removing: _configtest.c _configtest.o _configtest macros to define: [('HAVE_STRFTIME', None), ('HAVE_TIMEGM', None)] macros to undefine: ['HAVE_STRPTIME'] Note that ('HAVE_STRFTIME', None) means "-DHAVE_STRFTIME" -- i.e. define the macro without any particular value. No, I don't know why 'strptime()' isn't showing up, but at least it demonstrates a failure case. Greg -- Greg Ward - geek-on-the-loose gward(a)python.net http://starship.python.net/~gward/ Save energy: be apathetic.

3 6

New code snapshots on starship
by Greg Ward 27 Jun '00

27 Jun '00

Hi all -- I've just uploaded two code snapshots (one from Saturday, one from today) to Starship. Unfortunately, Starship seems to have gone down in the time since I uploaded them, so I can't test these URLs. However, try 'em yourself: http://starship.python.net/~gward/python/distutils-20000624.tar.gz http://starship.python.net/~gward/python/distutils-20000624.zip http://starship.python.net/~gward/python/distutils-20000626.tar.gz http://starship.python.net/~gward/python/distutils-20000626.zip I can't think of any reason why you'd want to use Saturday's snapshot, as tonight's is *ever* so much nicer: it includes Thomas' "bdist_wininst" command, and my adaptation of Rene's fix for building extensions on AIX. Please give these (and all the other recent features) a whirl! I want to put together Distutils 0.9 in the next couple of days, so there's time to fix any bugs that people discover before Guido throws up Python 1.6b1. Greg -- Greg Ward - programmer-at-big gward(a)python.net http://starship.python.net/~gward/ I have a very good DENTAL PLAN. Thank you.

1 0