Mailman 3 June 2000 - Distutils-SIG

Sample setup.py for Numeric Python
by Greg Ward April 29, 2018

April 29, 2018

Hi again -- [cc'd to Paul Dubois: you said you weren't following the distutils sig anymore, but this directly concerns NumPy and I'd like to get your input!] here's that sample setup.py for NumPy. See below for discussion (and questions!). ------------------------------------------------------------------------ #!/usr/bin/env python # Setup script example for building the Numeric extension to Python. # This does sucessfully compile all the .dlls. Nothing happens # with the .py files currently. # Move this file to the Numerical directory of the LLNL numpy # distribution and run as: # python numpysetup.py --verbose build_ext # # created 1999/08 Perry Stoll __rcsid__ = "$Id: numpysetup.py,v 1.1 1999/09/12 20:42:48 gward Exp $" from distutils.core import setup setup (name = "numerical", version = "0.01", description = "Numerical Extension to Python", url = "http://www.python.org/sigs/matrix-sig/", ext_modules = [ ( '_numpy', { 'sources' : [ 'Src/_numpymodule.c', 'Src/arrayobject.c', 'Src/ufuncobject.c' ], 'include_dirs' : ['./Include'], 'def_file' : 'Src/numpy.def' } ), ( 'multiarray', { 'sources' : ['Src/multiarraymodule.c'], 'include_dirs' : ['./Include'], 'def_file': 'Src/multiarray.def' } ), ( 'umath', { 'sources': ['Src/umathmodule.c'], 'include_dirs' : ['./Include'], 'def_file' : 'Src/umath.def' } ), ( 'fftpack', { 'sources': ['Src/fftpackmodule.c', 'Src/fftpack.c'], 'include_dirs' : ['./Include'], 'def_file' : 'Src/fftpack.def' } ), ( 'lapack_lite', { 'sources' : [ 'Src/lapack_litemodule.c', 'Src/dlapack_lite.c', 'Src/zlapack_lite.c', 'Src/blas_lite.c', 'Src/f2c_lite.c' ], 'include_dirs' : ['./Include'], 'def_file' : 'Src/lapack_lite.def' } ), ( 'ranlib', { 'sources': ['Src/ranlibmodule.c', 'Src/ranlib.c', 'Src/com.c', 'Src/linpack.c', ], 'include_dirs' : ['./Include'], 'def_file' : 'Src/ranlib.def' } ), ] ) ------------------------------------------------------------------------ First, what d'you think? Too clunky and verbose? Too much information for each extension? I kind of think so, but I'm not sure how to reduce it elegantly. Right now, the internal data structures needed to compile a module are pretty obviously exposed: is this a good thing? Or should there be some more compact form for setup.py that will be expanded later into the full glory we see above? I've already made one small step towards reducing the amount of cruft by factoring 'include_dirs' out and supplying it directly as a parameter to 'setup()'. (But that needs code not in the CVS archive yet, so I've left the sample setup.py the same for now.) The next thing I'd like to do is get that damn "def_file" out of there. To support it in MSVCCompiler, there's already an ugly hack that unnecessarily affects both the UnixCCompiler and CCompiler classes, and I want to get rid of that. (I refer to passing the 'build_info' dictionary into the compiler classes, if you're familiar with the code -- that dictionary is part of the Distutils extension-building system, and should not propagate into the more general compiler classes.) But I don't want to give these weird "def file" things standing on the order of source files, object files, libraries, etc., because they seem to me to be a bizarre artifact of one particular compiler, rather than something present in a wide range of C/C++ compilers. Based on the NumPy model, it seems like there's a not-too-kludgy way to handle this problem. Namely: if building extension "foo": if file "foo.def" found in same directory as "foo.c" add "/def:foo.def" to MSVC command line this will of course require some platform-specific code in the build_ext command class, but I figured that was coming eventually, so why put it off? ;-) To make this hack work with NumPy, one change would be necessary: rename Src/numpy.def to Src/_numpy.def to match Src/_numpy.c, which implements the _numpy module. Would this be too much to ask of NumPy? (Paul?) What about other module distributions that support MSVC++ and thus ship with "def" files? Could they be made to accomodate this scheme? Thanks for your feedback -- Greg -- Greg Ward - software developer gward(a)cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913

4 5

Can now compile simple extensions
by Greg Ward April 29, 2018

April 29, 2018

Hi all -- at long last, I found the time to hack in the ability to compile extension modules to the Distutils. Mainly, this meant adding a 'build_ext' command which uses a CCompiler instance for all its dirty work. I also had to add a few methods to CCompiler (and, of course, UnixCCompiler) to make this work. And I added a new module, 'spawn', which takes care of running sub-programs more efficiently and robustly (no shell involved) than os.system. That's needed, obviously, so we can run the compiler! If you're in the mood for grubbing over raw source code, then get the latest from CVS or download a current snapshot. See http://www.python.org/sigs/distutils-sig/implementation.html for a link to the code snapshot. I'm still waiting for more subclasses of CCompiler to appear. At the very least, we're going to need MSVCCompiler to build extensions on Windows. Any takers? Also, someone who knows the Mac, and how to run compilers programmatically there, will have to figure out how to write a Mac-specific concrete CCompiler subclass. The spawn module also needs a bit of work to be portable. I suspect that _win32_spawn() (the intended analog to my _posix_spawn()) will be easy to implement, if it even needs to go in a separate function at all. It looks from the Python Library documentation for 1.5.2 that the os.spawnv() function is all we need, but it's a bit hard to figure out just what's needed. Windows wizards, please take a look at the 'spawn()' function and see if you can make it work on Windows. As for actually compiling extensions: well, if you can figure out the build_ext command, go ahead and give it a whirl. It's a bit cryptic right now, since there's no documentation and no example setup.py. (I have a working example at home, but it's not available online.) If you feel up to it, though, see if you can read the code and figure out what's going on. I'm just hoping *I'll* be able to figure out what's going on when I get back from the O'Reilly conference next week... ;-) Enjoy -- Greg -- Greg Ward - software developer gward(a)cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913

2 1

Two fixes (at last)
by Greg Ward April 29, 2018

April 29, 2018

Hi all -- at long last, I have fixed two problems that a couple people noticed a while ago: * I folded in Amos Latteier's NT patches almost verbatim -- just changed an `os.path.sep == "/"' to `os.name == "posix"' and added some comments bitching about the inadequacy of the current library installation model (I think this is Python's fault, but for now Distutils is slavishly aping the situation in Python 1.5.x) * I fixed the problem whereby running "setup.py install" without doing anything else caused a crash (because 'build' hadn't yet been run). Now, the 'install' command automatically runs 'build' before doing anything; to make this bearable, I added a 'have_run' dictionary to the Distribution class to keep track of which commands have been run. So now not only are command classes singletons, but their 'run' method can only be invoked once -- both restrictions enforced by Distribution. The code is checked into CVS, or you can download a snapshot at http://www.python.org/sigs/distutils-sig/distutils-19990607.tar.gz Hope someone (Amos?) can try the new version under NT. Any takers for Mac OS? BTW, all parties involved in the Great "Where Do We Install Stuff?" Debate should take a good, hard look at the 'set_final_options()' method of the Install class in distutils/install.py; this is where all the policy decisions about where to install files are made. Currently it apes the Python 1.5 situation as closely as I could figure it out. Obviously, this is subject to change -- I just don't know to *what* it will change! Greg -- Greg Ward - software developer gward(a)cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913

2 1

Package versioning
by Timothy Docker April 29, 2018

April 29, 2018

Hi all, I've been aware that the distutils sig has been simmerring away, but until recently it has not been directly relevant to what I do. I like the look of the proposed api, but have one question. Will this support an installed system that has multiple versions of the same package installed simultaneously? If not, then this would seem to be a significant limitation, especially when dependencies between packages are considered. Assuming it does, then how will this be achieved? I am presently managing this with a messy arrangement of symlinks. A package is installed with its version number in it's name, and a separate directory is created for an application with links from the unversioned package name to the versioned one. Then I just set the pythonpath to this directory. A sample of what the directory looks like is shown below. I'm sure there is a better solution that this, and I'm not sure that this would work under windows anyway (does windows have symlinks?). So, has this SIG considered such versioning issues yet? Cheers, Tim -------------------------------------------------------------- Tim Docker timd(a)macquarie.com.au Quantative Applications Division Macquarie Bank -------------------------------------------------------------- qad16:qad $ ls -l lib/python/ total 110 drwxr-xr-x 2 mts mts 512 Nov 11 11:23 1.1 -r--r----- 1 root mts 45172 Sep 1 1998 cdrmodule_0_7_1.so drwxr-xr-x 2 mts mts 512 Sep 1 1998 chart_1_1 drwxr-xr-x 3 mts mts 512 Sep 1 1998 Fnorb_0_7_1 dr-xr-x--- 3 mts mts 512 Nov 11 11:21 Fnorb_0_8 drwxr-xr-x 3 mts mts 1536 Mar 3 12:45 mts_1_1 dr-xr-x--- 7 mts mts 512 Nov 11 11:22 OpenGL_1_5_1 dr-xr-x--- 2 mts mts 1024 Nov 11 11:23 PIL_0_3 drwxr-xr-x 3 mts mts 512 Sep 1 1998 Pmw_0_7 dr-xr-x--- 2 mts mts 512 Nov 11 11:21 v3d_1_1 qad16:qad $ ls -l lib/python/1.1 total 30 lrwxrwxrwx 1 root other 29 Apr 10 10:43 _glumodule.so -> ../OpenGL_1_5_1/_glumodule.so lrwxrwxrwx 1 root other 30 Apr 10 10:43 _glutmodule.so -> ../OpenGL_1_5_1/_glutmodule.so lrwxrwxrwx 1 root other 22 Apr 10 10:43 _imaging.so -> ../PIL_0_3/_imaging.so lrwxrwxrwx 1 root other 36 Apr 10 10:43 _opengl_nummodule.so -> ../OpenGL_1_5_1/_opengl_nummodule.so lrwxrwxrwx 1 root other 27 Apr 10 10:43 _tkinter.so -> ../OpenGL_1_5_1/_tkinter.so lrwxrwxrwx 1 mts mts 21 Apr 10 10:43 cdrmodule.so -> ../cdrmodule_0_7_1.so lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 chart -> ../chart_1_1 lrwxrwxrwx 1 root other 12 Apr 10 10:43 Fnorb -> ../Fnorb_0_8 lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 mts -> ../mts_1_1 lrwxrwxrwx 1 root other 15 Apr 10 10:43 OpenGL -> ../OpenGL_1_5_1 lrwxrwxrwx 1 root other 33 Apr 10 10:43 opengltrmodule.so -> ../OpenGL_1_5_1/opengltrmodule.so lrwxrwxrwx 1 root other 33 Apr 10 10:43 openglutil_num.so -> ../OpenGL_1_5_1/openglutil_num.so lrwxrwxrwx 1 root other 10 Apr 10 10:43 PIL -> ../PIL_0_3 lrwxrwxrwx 1 mts mts 10 Apr 10 10:43 Pmw -> ../Pmw_0_7 lrwxrwxrwx 1 root other 10 Apr 10 10:43 v3d -> ../v3d_1_1

3 2

[Distutils-sig] distutils charter and interscript
by John Skaller April 29, 2018

April 29, 2018

3 2

Re: CygwinCCompiler, msvc hack, BCPPCompiler
by Rene Liebscher Aug. 13, 2000

Aug. 13, 2000

---- CygwinCCompiler ------------ OK, it should now be better to read. I also included your other changes (set_executables, build_temp.) ----- msvc hack ----------- I also had a look at this msvc hack in build_ext. I think it is now possible to get rid of it. It does several things which could be done in an other way or shouldn't be done at all. First, it tries to find a def-file in the source directory if none is given. I think one should specify this explicitely, who knows if it is really the right file and moreover it overwrites any export_symbols given to Extension(). Then it uses the module_name to create an export directive for the procedure 'init{modulename}'. It is possible to extract this name from the output filename (see (bcpp|cygwin)compiler.py ) I think this export parameter should be only used if neither a def file nor a list of symbols is given. (Then you could use your compiler classes also for non python dll's by specifying [] as export_symbols list.) And finally it uses the build_temp path for it implib directive. We have now this new extra parameter to link_shared_library, so this is also not a problem. When I looked at the code of build_ext I found you are not using export_symbols as parameter to link_shared_object. Also you are not using any of this export_* values from the Extension class. This should be changed. But there is one point which is not clear. There is no parameter at link_shared_object for export_symbols_file. Either we add this or we change the semantics of the existing export_symbols a bit. * export_symbols == None : no export symbols given => add init{module} * type(export_symbols) == ListType : export all symbols from this list * type(export_symbols) == StringType : take this as a filename of a def file ------ bcppcompiler ------------- Which version of Borland C you need to use it? I tried BC5. It doesn't have a linker named ilink32 (?) and it doesn't accept some of your parameters /q for bcc32 and /Gn /q for the linker (tlink32). Also it is using mypylib, which probably the stub library for python15.dll . Is this library somewhere to download or how can I create it? My BC version doesn't include files if they are in the source directory ( src/foo.c includes "foo.h" which is really src/foo.h ) so I had to specify this as an include_dir (-Isrc). If all versions of BC do the same, the directories of the source files should append to include_dir in the bcppcompiler class. Kind regards Rene Liebscher """distutils.cygwinccompiler Contains the CygwinCCompiler class, a subclass of UnixCCompiler that handles the Gnu Win32 C compiler. It also contains the Mingw32CCompiler class which handles the mingw32 compiler (same as cygwin in no-cygwin mode.) """ # created 2000/05/05, Rene Liebscher __revision__ = "$Id: cygwinccompiler.py,v 1.1 2000/06/21 03:33:03 gward Exp $" import os,sys,string from distutils import sysconfig from distutils.unixccompiler import UnixCCompiler # Because these compilers aren't configured in Python's config.h file by default # we should at least warn the user if he is using a unmodified version. def check_config_h(): """ checks, if the gcc-compiler is mentioned in config.h if it is not, compiling probably doesn't work """ from distutils import sysconfig import string,sys try: # It would probably better to read single lines to search. # But we do this only once, and it is fast enough f=open(sysconfig.get_config_h_filename()) s=f.read() f.close() try: # is somewhere a #ifdef __GNUC__ or something similar string.index(s,"__GNUC__") except ValueError: sys.stderr.write ("warning: "+ "Python's config.h doesn't seem to support your compiler.\n") except IOError: # if we can't read this file, we cannot say it is wrong # the compiler will complain later about this file as missing pass # This is called when the module is imported, so we make this check only once check_config_h() # XXX Things not currently handled: # * see UnixCCompiler class CygwinCCompiler (UnixCCompiler): compiler_type = 'cygwin' def __init__ (self, verbose=0, dry_run=0, force=0): UnixCCompiler.__init__ (self, verbose, dry_run, force) # our compiler uses other names # dllwrap: specification of entry point is not necessary self.set_executables(compiler='gcc -O -Wall', compiler_so='gcc -O -Wall', linker_exe='gcc', linker_so='dllwrap --target=i386-cygwin32') # cygwin and mingw32 need different sets of libraries self.dll_libraries=[ # cygwin shouldn't need msvcrt, # but without the dll's will crash # ( gcc version 2.91.57 ) # perhaps something about initialization # mingw32 needs it in all cases "msvcrt" ] # __init__ () def link_shared_object (self, objects, output_filename, output_dir=None, libraries=None, library_dirs=None, runtime_library_dirs=None, export_symbols=None, debug=0, extra_preargs=None, extra_postargs=None, build_temp=None): if libraries == None: libraries = [] # additional libraries # the python library is always needed on Windows # we need the python version without the dot, eg. '15' libraries = libraries + [ "python%d%d" % ( sys.hexversion >> 24, (sys.hexversion >> 16) & 0xff) ] + self.dll_libraries # name of extension if not debug: ext_name = os.path.basename(output_filename)[:-len(".pyd")] else: ext_name = os.path.basename(output_filename)[:-len("_d.pyd")] def_file = os.path.join(build_temp, ext_name + ".def") #exp_file = os.path.join(build_temp, ext_name + ".exp") #lib_file = os.path.join(build_temp, 'lib' + ext_name + ".a") # Make .def file # (It would probably better to check if we really need this, # but for this we had to insert some unchanged parts of # UnixCCompiler, and this is not what we want.) f = open(def_file,"w") f.write("EXPORTS\n") # intro if export_symbols == None: # export a function "init" + ext_name f.write("init" + ext_name + "\n") else: # if there are more symbols to export write them into f for sym in export_symbols: f.write(sym+"\n") f.close() if extra_preargs == None: extra_preargs = [] extra_preargs = extra_preargs + [ #"--verbose", #"--output-exp",exp_file, #"--output-lib",lib_file, "--def",def_file ] # who wants symbols and a many times larger output file # should explicitely switch the debug mode on # otherwise we let dllwrap strip the output file # (On my machine unstripped_file = stripped_file + 254KB # 10KB < stripped_file < ??100KB ) if not debug: extra_preargs = extra_preargs + ["-s"] UnixCCompiler.link_shared_object(self, objects, output_filename, output_dir, libraries, library_dirs, runtime_library_dirs, None, # export_symbols, we do this with our def-file debug, extra_preargs, extra_postargs, build_temp) # link_shared_object () # class CygwinCCompiler # the same as cygwin plus some additional parameters class Mingw32CCompiler (CygwinCCompiler): compiler_type = 'mingw32' def __init__ (self, verbose=0, dry_run=0, force=0): CygwinCCompiler.__init__ (self, verbose, dry_run, force) self.set_executables(compiler='gcc -mno-cygwin -O -Wall', compiler_so='gcc -mno-cygwin -O -Wall', linker_exe='gcc -mno-cygwin', linker_so='dllwrap' + ' --target=i386-mingw32' + ' --entry _DllMain@12') # mingw32 doesn't really need 'target' and cygwin too (it seems, # it is enough to specify a different entry point) # no additional libraries need # (only msvcrt, which is already added by CygwinCCompiler) # __init__ () # class Mingw32CCompiler

3 19

DOS text files and CVS
by Greg Ward July 7, 2000

July 7, 2000

Hi all -- can anyone enlighten me on the right way to check in DOS text files to a CVS repository? I have Thomas Heller's C source for his simple graphical installer for Python modules, and it should definitely be in the Distutils CVS tree. But I don't want to check it in if it'll screw up line-endings for anyone. Is there a Right Way to do this? Thanks -- Greg -- Greg Ward - Linux nerd gward(a)python.net http://starship.python.net/~gward/ Just because you're paranoid doesn't mean they *aren't* out to get you.

7 8

ANNOUNCE: Distutils 0.9
by Greg Ward June 30, 2000

June 30, 2000

Python Distribution Utilities release 0.9 June 29, 2000 The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python modules. (It is intended that ultimately the Distutils will grow up into a system for distributing and installing whole Python applications, but for now their scope is limited to module distributions.) The Distutils are a standard part of Python 2.0; if you are running 2.0 (or one of the 1.6 alpha releases that preceded it), you don't need to install the Distutils separately. This release is primarily so that you can add the Distutils to a Python 1.5.2 installation -- you will then be able to install modules that require the Distutils, or use the Distutils to distribute your own modules. More information is available at the Distutils web page: http://www.python.org/sigs/distutils-sig/ and in the README.txt included in the Distutils source distribution. You can download the Distutils from http://www.python.org/sigs/distutils-sig/download.html Trivial patches can be sent to me (Greg Ward) at gward(a)python.net. Larger patches should be discussed on the Distutils mailing list: distutils-sig(a)python.org.

3 2

Heads up!
by Fred L. Drake, Jr. June 30, 2000

June 30, 2000

I said: > I'll try to get this deal with tonight, but it may well be tomorrow > morning before I can get to it all. :( Greg Ward replied: > Well, I took a chance and sent the announcement out... in just an hour > or two, people will be waking up in Europe, eagerly banging on > python.org, wondering where Distutils 0.9 is... ;-) Ok, everyone, heads up: I didn't get this done, so it's not there yet! Greg has sent specific information I need to get this updated on python.org, but I'm too tired to follow it. I'll do this first thing in the morning. Sorry! This is my fault, not Greg's! -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member

1 0

Distutils 0.9
by Greg Ward June 30, 2000

June 30, 2000

...just a note of self-congratulatory gloating that I didn't put in the official announcement: the Distutils 0.9 release is available as: * source tarball * source ZIP file * source RPM * RPM * Windows installer ... all of them generated by the Distutils in three easy commands. Probably could have done it with one command, but I didn't want to push my luck. Wow-ee! That is, to be blunt, TOTALLY ****ING COOL!! Couldn't have done it without ya, folks. This thing is working like a *charm*. Special thanks to Harry Gebel and Thomas Heller, who actually brought it all together with the RPM and Windows installer support. Now, I will sleep soundly, put in one perfunctory day of work, and then completely forget about computers for two whole days... ahhhh... Greg -- Greg Ward - Linux geek gward(a)python.net http://starship.python.net/~gward/ I had pancake makeup for brunch!

1 0

One last code snapshot...
by Greg Ward June 29, 2000

June 29, 2000

...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. June 29, 2000

June 29, 2000

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 June 29, 2000

June 29, 2000

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 June 29, 2000

June 29, 2000

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 June 29, 2000

June 29, 2000

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 June 28, 2000

June 28, 2000

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 June 28, 2000

June 28, 2000

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 June 27, 2000

June 27, 2000

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 June 27, 2000

June 27, 2000

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 June 27, 2000

June 27, 2000

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

Behaviour of "install_data" changed
by Greg Ward June 27, 2000

June 27, 2000

I've just fixed the behaviour of the "install_data" command: the default directory for installating data files is now just the installation base, which is usually sys.prefix. Thus, if you put data_files = ["my_data"] in your setup script, you will wind up installing (eg.) /usr/local/my_data -- definitely the wrong thing on Unix, and probably wrong on Windows too. (Except for applications that have their own prefix, but that's not really dealt with yet.) This is the Right Thing now because of the change to "install_data" that lets you specify where to put data files; the above should be spelled data_files = [("share", ["my_data"])] which will install /usr/local/share/my_data. Of course, this still doesn't solve the problem of, "How does my application/module know where Distutils installed this data file if the user did some wild funky custom installation?". Oh well, better than nothing. Greg -- Greg Ward - Unix nerd gward(a)python.net http://starship.python.net/~gward/ Vote anarchist.

3 3

building extensions with AIX
by Rene Liebscher June 27, 2000

June 27, 2000

Hi, I have seen in the TODO file that there was an entry about AIX. I tried it and found some little problems. It seems some paths in the Makefile are wrong. After playing a little bit around with it, I wrote a new compiler class. (I think, these changes could be included in unixccompiler, but to test it, it is nice to have a own file for it.) Maybe we should also change the default compiler table. I think we should have entries for sys.platform in it, too. So we could try a more specific name first ('aix4') and if there is no entry the usual os.name ('posix'.) The AIXCCompiler class is attached, maybe someone wants to try it, and find out if this is really all we have to change against the standard unixccompiler. (Don't forget to make an entry for it in ccompiler.py.) kind regards Rene Liebscher PS: I used AIX 4.3 and its 'cc' compiler. """distutils.aixccompiler Contains the AIXCCompiler class, a subclass of UnixCCompiler that handles some path problems with AIX. The makefile isn't correct for distutils' standard compiler. """ # created 2000/06/23, Rene Liebscher __revision__ = "$Id: aixccompiler.py $" from distutils import sysconfig from distutils.unixccompiler import UnixCCompiler # XXX Things not currently handled: # * see UnixCCompiler class AIXCCompiler (UnixCCompiler): compiler_type = 'aix' def __init__ (self, verbose=0, dry_run=0, force=0): UnixCCompiler.__init__ (self, verbose, dry_run, force) # we have to correct some paths self.ld_shared=sysconfig.get_python_lib(standard_lib=1)+'/config/ld_so_aix' self.ldflags_shared.append('-bI:'+sysconfig.get_python_lib(standard_lib=1)+'/config/python.exp') # __init__ () # class AIXCCompiler

2 3

Updated TODO list
by Greg Ward June 25, 2000

June 25, 2000

Hey, this to-do list is looking pretty good: lots of "done" items as of today. Highest priority: * bdist_wininst * auto-configuration; currently has enough to support mxDateTime, probably needs some more to support PIL, and then I need to find some other distributions with auto-configuration needs to play with Medium priority: * Cygwin GCC support, Borland C++ support * AIX, OSF/1 support Here's the list... GENERAL ------- * think about how to support distribution-specific "configure" commands -- eg. how can they push option values (include/library directories, that sort of thing) onto the "build_ext" command? [see also "AUTO-CONFIGURATION" section below, and the "config" command] * need a good, general-purpose, portable-if-you-want-it, unportable-if- you-need-control, way for the builder/installer to specify compiler and linker flags (lots of people expect CFLAGS and LDFLAGS to work, so they probably should; but options to either command and/or build are the right way, so those should be preferred) * install_data should install to $prefix by default, not $prefix/share (and should warn if developer doesn't supply any dir component: installing right to $prefix is almost always the wrong thing to do) [done 2000/06/24 GPW] DOCS ---- * write write write * include a standard blurb for README files somewhere PATCH REVIEW/INTEGRATION ------------------------ * review Rene Liebscher's patch for help options: he changed archive_util.py ccompiler.py command/bdist.py command/build.py command/build_clib.py command/build_ext.py command/sdist.py dist.py ...and I checked 'em all in without review because I want other people to try it out and I don't have time to review it right now (and he fixed a stupid bug in bdist.py for me) [done 2000/06/23 GPW] * review Rene Liebscher's cygwinccompiler.py contribution [started and aborted, 2000/06/24 GPW; asked Rene to resubmit patch with stylistic changes] COMMAND-LINE PARSING -------------------- * I think fancy_getopt needs to get fancier to properly support the -I, -D, -l, -L, etc. options of "build_ext": need to be able to accumulate multiple options in a list, should be able to split a string on a given delimiter, probably want to specify if repetitions of the same option will accumulate or replace, etc. * do the above options even work at all? seem to recall hearing reports of dismal failure, but I never looked into it [knowing how FancyGetopt works, there's no way these options can work: damn] COMPILER MODEL & CLASSES ------------------------ * add pre-processor interface to CCompiler (needed to support Autoconf-style 'try_cpp', 'search_cpp', 'search_headers' in config commands) [done, but only UnixCCompiler implements that interface] * fix UnixCCompiler so it doesn't depend on sysconfig (ie. cc must be passed in) [done 2000/06/24 GPW] * allow user to supply cc (compiler executable) in addition to compiler type [done 2000/06/24 GPW] * radically simplify CCompiler method signatures: drop most of the per-invocation customization, and just use the instance attributes for eg. include_dirs, libraries, ... [NB. should probably hold off integrating Cygwin and Borland support until this is done, *if* that is it is the right thing to do...] [update 2000/06/24: I'm cooling to this idea; it turns out the extra complex interface that's been there all along is useful for the "config" command, which has to do lots of little temporary compile and link steps] * Cygwin/Mingw32 support [Rene Liebscher is working on this] * Borland C++ support [Lyle Johnson is working on this] AUTO-CONFIGURATION ------------------ * add more goodies to the standard "config" command, and finish hacking up the example mxDateTime setup script to take advantage of them [partly done: at least enough is there to auto-configure mxDateTime; need to work on PIL's auto-configuration next] EXTENSION BUILDING ------------------ * extension building on AIX [update 2000/06/24: Rene Liebscher has a patch for this, which I have asked him to refine] * support for SWIG -- should just have to specify the .i file and have Distutils take care of running SWIG and knowing what the output is (to be really clever: make sure SWIG's output is included in source distributions, so builders-from-source don't need to have SWIG installed) [update 2000/06/24: Thomas Heller and I have gone back and forth on this a couple times: sounds like Thomas has the right idea, I'll let him work on it] * support for PyFort (lower priority than SWIG!) * OSF/1 problem: ld command has "*" in it, which is appropriate when a shell is involved, but there isn't one here, so we need to strip the quotes (and, ideally, put them back on again when spawn() prints out the command run!) INSTALLATION ------------ * if Distutils installs the first third-party modules in an installation (and creates site-packages), then "install" needlessly warns about having installed to a location not on sys.path -- presumably because site-packages isn't in sys.path at startup, since it doesn't exist until we create it! (I think this is only a problem with 1.5.2, since site-packages is now created when Python is installed -- check!) * need a mechanism for specifying pre-install and post-install hooks, which will be run when installing from a smart built distribution (RPM, wininst, etc.); also, "install" needs to run these hooks *except* for "fake" installs done solely to create a built distribution * bdist_dumb should grow a little intelligence: let packager choose whether to make archive relative to prefix or the root (prefix is essential for proper Windows support ) DISTRIBUTION FORMATS -------------------- * figure out why bdist_rpm doesn't work with RPM 2.x, and make it work if possible [punt: I don't care anymore, if anyone else does, let them fix it] * make "bdist" take multiple formats (both for convenience and consistency with "sdist"); should be doable now that we can reinitialize, refinalize, and (presumably) rerun commands [done 2000/06/06 GPW] * Solaris pkgtool, HP depot [Mark Alexander is working on these] * minimal Windows installer ("bdist_wininst") [Thomas Heller is working on this] * Wise installer for Windows ("bdist_wise") [Thomas Heller said he will work on this when "bdist_wininst" is done] $Id: TODO,v 1.5 2000/06/25 02:37:09 gward Exp $ -- Greg Ward - Linux geek gward(a)python.net http://starship.python.net/~gward/ No problem is so formidable that you can't just walk away from it.

1 0

bdist_rpm and RPM 2.x
by Greg Ward June 24, 2000

June 24, 2000

The "bdist_rpm" doesn't work with RPM 2.x. This means that building RPMs will only work on Red Hat 6.x -- and presumably any version of Mandrake (since Mandrake started as a fork of Red Hat 6.0), and recent SuSE versions as well, but I don't know how recent. Does anyone care? I don't anymore, since I finally got around to upgrading to Red Hat 6. If compatibility with RPM 2.x matters to you, then please dig in to the bdist_rpm command, figure out why it doesn't work, and submit a patch. Otherwise Distutils will only be able to build RPMs with RPM 3. Greg -- Greg Ward - Linux nerd gward(a)python.net http://starship.python.net/~gward/ In space, no one can hear you fart.

1 0

RC and MC patch for msvccompiler
by Thomas Heller June 24, 2000

June 24, 2000

This is the patch for msvccompiler factored out of my previous swig patch, which allows compiling resource scripts (.rc) to .res files, and messages (.mc) to .res files. The resulting .res files are passed to the linker. Additionally .cxx is now recognized as C++ source extension. Thomas

2 1

distutil install
by Michel Sanner June 24, 2000

June 24, 2000

Hello, I got the OpenDX Python wrapper from Randall Hopper and asked him why the .so wrapping the DX library ends up not int he package directory but in $exec_prefix/lib/python/site-packages. His answer was that this is where distutil puts it. I feel that it would nicer to have the .so along with all other files of the package in $exec_prefix/lib/python/site-packages/DX. Is there a way to specify this in setup.py ? -Michel -- ----------------------------------------------------------------------- >>>>>>>>>> AREA CODE CHANGE <<<<<<<<< we are now 858 !!!!!!! Michel F. Sanner Ph.D. The Scripps Research Institute Assistant Professor Department of Molecular Biology 10550 North Torrey Pines Road Tel. (858) 784-2341 La Jolla, CA 92037 Fax. (858) 784-2860 sanner(a)scripps.edu http://www.scripps.edu/sanner -----------------------------------------------------------------------

2 1

ccompiler problem
by Thomas Heller June 24, 2000

June 24, 2000

Consider the object_filenames method: def object_filenames (self, source_filenames, strip_dir=0, output_dir=''): if output_dir is None: output_dir = '' obj_names = [] for src_name in source_filenames: (base, ext) = os.path.splitext (src_name) if ext not in self.src_extensions: continue ^^^^^^^^^ Problem is here if strip_dir: base = os.path.basename (base) obj_names.append (os.path.join (output_dir, base + self.obj_extension)) return obj_names # object_filenames () If you specify a source-file with an unknown extension in the sources list, you later get a traceback later saying something like 'sources and targets must have the same length'. IMO we have two possibilities here: - assume that 'ext' is something which should be passed to the linker - raise an error like 'Don't know how to compile this file' Thomas Heller ION-TOF GmbH

2 1

Re: [Distutils] Duelling SWIG patches
by Michel Sanner June 24, 2000

June 24, 2000

I have been following the SWIG support discussion for a while. I am not sure I see the point in having distutil run SWIG. Why not simply provide the result or running swig as part of the source code that get's compiled. There are a number of versions of SWIG that have different types of arguments, in addition the interface might use user defined typemaps ! It seems to me that this would be very difficult to get to work properly and I cannot see any real benefit. -Michel On Jun 23, 10:42am, Thomas Heller wrote: > Subject: Re: [Distutils] Duelling SWIG patches > > 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...) > > > I don't like this patch. > > While I won't argue whether ccompiler is an appropriate superclass > for swig, swig shares some important properties: > > Swig has command line flags to specify include directories -I<dir>, > libraries -l<ifile>, define symbols -Dsymbol like C-compilers. > Other options which are maybe usefull for python extensions > are -t <typemap file>, -shadow (create shadow classes), > -module name (set module name) and maybe more. > > >From this I have the impression that swig should be a separate class > implemented in swig.py, and there should be distutils command line > flags for setting the above options (and also the -c++ option). > Although I did not implement them so far. > > (Sidenote: I also needed a swig-object in build_ext for my setup-script > for win32all. I had to extend distutils in the setup-script > because there are also exe-files to be built from C++ > and swig sources). > > As I pointed out in a separate post, there should also be an option > to specify C or C++ processing. > > If I find time, I will submit a new patch. > > Thomas > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG(a)python.org > http://www.python.org/mailman/listinfo/distutils-sig >-- End of excerpt from Thomas Heller -- ----------------------------------------------------------------------- >>>>>>>>>> AREA CODE CHANGE <<<<<<<<< we are now 858 !!!!!!! Michel F. Sanner Ph.D. The Scripps Research Institute Assistant Professor Department of Molecular Biology 10550 North Torrey Pines Road Tel. (858) 784-2341 La Jolla, CA 92037 Fax. (858) 784-2860 sanner(a)scripps.edu http://www.scripps.edu/sanner -----------------------------------------------------------------------

2 1

Fw: [Distutils] Duelling SWIG patches
by Thomas Heller June 23, 2000

June 23, 2000

Thomas Heller ION-TOF GmbH ----- Original Message ----- From: "Thomas Heller" <thomas.heller(a)ion-tof.com> To: <distutils-sig(a)python.org> Sent: Friday, June 23, 2000 9:08 AM Subject: Re: [Distutils] Duelling SWIG patches > > > > Greg Ward wrote: > > [snip] > > > 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 > > [snip] > > and Michael wrote: > > > > I'm pretty sure that the only way to do this short of parsing the file is > to > > run "swig" with no options and then (if it fails) run "swig -c++" > (enabling > > the C++ processing features). This seems more like something you'd want > to > > do during configuration then during the build. > Unfortunately swig does not fail in C-mode on an I-file > which is destined for C++: The C-compiler will fail with syntax > errors. > > Thomas > > >

1 0

Re: [Distutils] Duelling SWIG patches
by Michael Muller June 23, 2000

June 23, 2000

Greg Ward wrote: [snip] > 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 [snip] I'm pretty sure that the only way to do this short of parsing the file is to run "swig" with no options and then (if it fails) run "swig -c++" (enabling the C++ processing features). This seems more like something you'd want to do during configuration then during the build. Maybe it would be best to adopt a convention for SWIG files in distutils (uppercase ".I" in C++, maybe?) or find some other way to allow the user to explicitly indicate a C++ file. ============================================================================= michaelMuller = mmuller(a)enduden.com | http://www.cloud9.net/~proteus ----------------------------------------------------------------------------- We are explorers in the further reaches of experience: demons to some, angels to others. - "Pinhead" from "Hellraiser" =============================================================================

1 0

Autoconf in Python
by Greg Ward June 22, 2000

June 22, 2000

Those of you who follow python-checkins closely probably already know this, but for the rest of you I think this will be news: I now have a working demonstration of the long-mythical, frequently procrastinated, "Autoconf-in-Python"! Marc-Andre, you were right -- it wasn't too bad. I think I probably spent more time combing the Autoconf docs for inspiration, and figuring out how to sensibly translate Autoconf's byzantine shell/M4 interface into sensible OO Python, than I did actually coding it. Here's the bird's-eye view of how it works: * module developer defines a custom command, "config_xxx", which inherits from the standard "config" command (distutils.command.- config.config). (I suggest we adopt the convention "config_" + distribution_name -- which, come to think of it, is probably a good convention for *all* extended commands defined in setup scripts.) * this custom "config" command then calls the various methods provided by the standard "config" to probe the system. Currently available: 'try_cpp()', 'search_cpp()', 'try_compile()', 'try_link()', 'try_run()', 'check_header()', and 'check_func()'. (The 'try' methods are fairly low-level and expect you to provide a chunk of custom-crafted C/C++ code; the 'check' methods just take a header name or function name or what-have-you, and Do The Right Thing.) * the custom "config" command uses the result of the system probing to determine preprocessor macros to define/undefine, include directories to search, libraries to link against, library dirs to search, and whatever else might be needed. Currently the standard "config" command provides no support for this, although it probably should. (My thinking is something like this: users can provide manual overrides by editing the "[config]" section of the setup.cfg file; the custom config command -- if any! -- will then either respect the manual overrides or probe the system (or a combination, depending on which manual overrides are present). At the end of the day, there are a bunch of settings -- macros, include dirs, libraries, and library dirs -- sitting in the "config" command object, which are then used by the various "build" commands. (This is not terribly general -- what if you want to build one extension (or library or executable one way), but others differently? -- but it's good enough. If you need to get fancy, go right ahead: this is Python, the only barrier is your own creativity. No fighting with shell quoting rules or M4 bizarritude. Hooray!) A note on portability: yes, this is all heavily geared towards C and C++. No matter what Sun says (lying all the way to the bank, no doubt), I expect an Autoconf-ish facility will be necessary for grokking Java installations to build JPython extensions -- but that ability is a long ways off, definitely post-Distutils 1.0. Also, I had to add a 'preprocess()' method to the CCompiler interface, which is currently only implemented in UnixCCompiler. Thus, the preprocessor-depending "config" methods ('try_cpp()', 'search_cpp()', 'check_header()') will die horribly on Windows and Mac OS. Please take a look at the 'preprocess()' docstring and let me know if it can be implemented portably, or if the interface will have to change. Oh, Unix wizards: currently I just do "cc -E filename.c -o filename.i" to run the preprocessor. Works with GCC, and ISTR that SGI's compiler supports "-E" too. Anyone know how widely spread this convention is? Should I implement some heuristics to figure out whether to use "cc -E" or "/lib/cpp"? What other options are there? I'm gonna check this in now. No time to make a snapshot tonight -- please get the latest CVS code and give this a whirl. The only test case is mxDateTime (examples/mxdatetime_setup.py), and only 'check_func()' (and therefore 'try_link()') have been tested. Next up is to add autoconfiguration to PIL's setup script. Whee! this is fun... I guess I've written my code for the week, now back to wading through all those patches... Greg -- Greg Ward - nerd gward(a)python.net http://starship.python.net/~gward/ Support bacteria -- it's the only culture some people have!

3 3

Installation requirements
by A.M. Kuchling June 21, 2000

June 21, 2000

[Follow-up to the Distutils SIG, please.] There are a few steps needed to find and install a package: 1) Discovery : which module does what I need? 2) Download : where can I get a copy? 3) Security : is this actually from the package author, and not a Trojan? 4) Installation : how do I set it up? 5) Checking for new versions: I have 1.0 installed; is a newer version available? Distutils focuses on the hardest and most complicated step, #4. For #1, you would need to browse through a list of available packages, browse through a hierarchy like Parnassus, or do keyword searches. #2 is pretty simple, since you just get one or more download URLs corresponding to a given package name, using the same database as in #1. For #3, you'd have to check a signature on the downloaded package, using something external like GnuPG. This means this step has to be skipped if the external tool isn't available. We could implement our own signature scheme with Python code, but that's a bad idea; security is hard, and few people will bother to generate keys that are only useful for this one application of distributing Python modules. (Side note: the sdist and bdist_* commands should have a --sign switch to sign the generated .tgz, .rpm, or whatever file.) For #5, the existing stuff in Tools/versioncheck might be partially applicable, though it requires that every package have a text file somewhere which gives the latest version. You'd want to use the same database for everything, to ensure that people actually use it! To start off with, we'd need some sort of generic API to the above functions, so that different interfaces can be written. A command-line interface would then be easiest. I don't know how network communications should be handled: HTTP to CGI scripts that return sets of RFC-822 headers, maybe? Combined with a DNS alias like modules.python.org, or modules.{us,uk,...}.python.org? Some potential sources of inspiration: Debian: apt Perl: CPAM.pm FreeBSD: ports system RPMfind (rpmfind.net) XEmacs: packages system -- A.M. Kuchling http://starship.python.net/crew/amk/ "Jo, it's a pity escapology wasn't part of your curriculum." "Funny you should say that. Look." <shows untied hand> -- The Doctor and Jo, tied up, in "Terror of the Autons"

2 1

Prerelease: bdist_wininst
by Thomas Heller June 21, 2000

June 21, 2000

This is a preliminary version of command/bdist_wininst.py. I still have more plans to extend this, but you are invited to test it. Feedback is very much appreciated. How it works: - 'setup.py bdist_wininst' first builds a binary distribution in zip-format and writes metadata into an ini-file. - These two files are appended to an exe-program which is included compressed and base64 encoded in the bdist_wininst module, so you don't have to build it. - The source code and MSVC project file is temporarily available for download at http://www.ion-tof-com/~thomas. - This should work on unix as well as on win32 systems, as long as the binary distribution does not contain c-extension modules, because distutils cannot cross-compile for windows. The resulting executable, when started, displays an installer-like user interface, checks for python installation(s) via the registry, lets the user select a directory for installation, and extracts all files. If the installation directory is different from the python installation directory, a .pth file is written. Future plans: - Improve the appearance of the installer dialog, add an icon, ... - Provide a help button - Provide a rollback capability if the installation failed. - Provide an uninstaller. - More stuff ----- Options (command line flags) for bdist_wininst: --target-compile Set a flag to compile all .py files to .pyc on the target system --target-optimize Set a flag to compile all .py files to .pyo on the target system --target-version=[1.5|1.6] Require python 1.5 or 1.6 on the target system Thomas Appended are: 1. context-diffs to fully integrate bdist_wininst into distutils 2. source code for bdist_wininst.py --------> start patch <-------- Index: command/__init__.py =================================================================== RCS file: /cvsroot/python/distutils/distutils/command/__init__.py,v retrieving revision 1.13 diff -c -r1.13 __init__.py *** command/__init__.py 2000/05/28 23:49:03 1.13 --- command/__init__.py 2000/06/15 11:47:58 *************** *** 20,23 **** --- 20,24 ---- 'bdist', 'bdist_dumb', 'bdist_rpm', + 'bdist_wininst', ] Index: command/bdist.py =================================================================== RCS file: /cvsroot/python/distutils/distutils/command/bdist.py,v retrieving revision 1.11 diff -c -r1.11 bdist.py *** command/bdist.py 2000/06/07 03:00:06 1.11 --- command/bdist.py 2000/06/15 11:47:58 *************** *** 38,43 **** --- 38,44 ---- 'tar': ('bdist_dumb',"tar-file"), 'rpm': ('bdist_rpm',"rpm distribution"), 'zip': ('bdist_dumb',"zip-file"), + 'wininst': ('bdist_wininst',"windows installer"), } # prints all possible arguments to --format --------> end patch <-------- --------> start bdist_wininst.py <-------- Implements the Distutils 'bdist_wininst' command: create a windows installer exe-program.""" # created 2000/06/02, Thomas Heller __revision__ = "$Id$" import os, sys from distutils.core import Command from distutils.util import get_platform, create_tree, remove_tree from distutils.errors import * class bdist_wininst (Command): description = "create a \"wininst\" built distribution" user_options = [('bdist-dir=', 'd', "temporary directory for creating the distribution"), ('keep-tree', 'k', "keep the pseudo-installation tree around after " + "creating the distribution archive"), ('target-compile', 'c', "compile to .pyc on the target system"), ('target-optimize', 'o', "compile to .pyo on the target system"), ('target-version=', 'v', "require a specific python version" + " on the target system (1.5 or 1.6)"), ] def initialize_options (self): self.bdist_dir = None self.keep_tree = 0 self.target_compile = 0 self.target_optimize = 0 self.target_version = None # initialize_options() def finalize_options (self): if self.bdist_dir is None: bdist_base = self.get_finalized_command('bdist').bdist_base self.bdist_dir = os.path.join(bdist_base, 'wininst') if not self.target_version: self.target_version = "" else: if not self.target_version in ("1.5", "1.6"): raise DistutilsOptionError ( "target version must be 1.5 or 1.6") if self.distribution.has_ext_modules(): short_version = sys.version[:3] if self.target_version and self.target_version != short_version: raise DistutilsOptionError ("target version can only be" + short_version) self.target_version = short_version # finalize_options() def run (self): self.run_command ('build') # XXX don't use 'self.get_finalized_command()', because it always # runs 'ensure_finalized()' on the command object; we explictly # want a command object that has *not* been finalized, so we can set # options on it! (The option we set, 'root', is so that we can do # a proper "fake install" using this install command object.) install = self.distribution.get_command_obj('install') install.root = self.bdist_dir install_lib = self.distribution.get_command_obj('install_lib') install_lib.compile = 0 install_lib.optimize = 0 # The packager (correct term in distutils speak?) can choose # if pyc and pyo files should be created on the TARGET system # instead at the SOURCE system. ## # The compilation can only be done on the SOURCE system ## # for one python version (assuming 1.6 and 1.5 have incompatible ## # byte-codes). ## short_version = sys.version[:3] ## if self.target_version == short_version: ## if not self.target_compile: ## install_lib.compile = 1 ## if not self.target_optimize: ## install_lib.optimize = 1 install_lib.ensure_finalized() self.announce ("installing to %s" % self.bdist_dir) install.ensure_finalized() install.run() # And make an archive relative to the root of the # pseudo-installation tree. archive_basename = "%s.win32" % self.distribution.get_fullname() # XXX hack! Our archive MUST be relative to sys.prefix # XXX What about .install_data, .install_scripts, ...? root_dir = install.install_lib arcname = self.make_archive (archive_basename, "zip", root_dir=root_dir) self.create_exe (arcname) if not self.keep_tree: remove_tree (self.bdist_dir, self.verbose, self.dry_run) # run() def create_inifile (self): # create an inifile containing data describing the installation. # This could be done without creating a real file, but # a file is (at least) usefull for debugging bdist_wininst. import string metadata = self.distribution.metadata ini_name = "%s.ini" % self.distribution.get_fullname() self.announce ("creating %s" % ini_name) inifile = open (ini_name, "w") # write the [metadata] section. values are written with repr()[1:], # so they do not contain unprintable characters, and are not # surrounded by quote chars inifile.write ("[metadata]\n") # 'info' will be displayed in the installers dialog box, # describing the items to be installed info = metadata.long_description + '\n' for name in dir (metadata): if (name != 'long_description'): data = getattr (metadata, name) if data: info = info + ("\n %s: %s" % \ (string.capitalize (name), data)) inifile.write ("%s=%s\n" % (name, repr (data)[1:-1])) # The [setup] section contains entries controlling # the installer runtime. inifile.write ("\n[Setup]\n") inifile.write ("info=%s\n" % repr (info)[1:-1]) inifile.write ("pthname=%s.%s\n" % (metadata.name, metadata.version)) inifile.write ("pyc_compile=%d\n" % self.target_compile) inifile.write ("pyo_compile=%d\n" % self.target_optimize) if self.target_version: vers_minor = string.split (self.target_version, '.')[1] inifile.write ("vers_minor=%s\n" % vers_minor) title = self.distribution.get_fullname() inifile.write ("title=%s\n" % repr (title)[1:-1]) inifile.close() return ini_name # create_inifile() def create_exe (self, arcname): import struct, zlib cfgdata = open (self.create_inifile()).read() comp_method = zlib.DEFLATED co = zlib.compressobj (zlib.Z_DEFAULT_COMPRESSION, comp_method, -15) zcfgdata = co.compress (cfgdata) + co.flush() installer_name = "%s.win32.exe" % self.distribution.get_fullname() self.announce ("creating %s" % installer_name) file = open (installer_name, "wb") file.write (self.get_exe_bytes ()) file.write (zcfgdata) crc32 = zlib.crc32 (cfgdata) header = struct.pack ("iiiiiiii", 0x12345678, # tag comp_method, # compression method crc32, # checksum len (cfgdata), # uncompressed length len (zcfgdata), # compressed length 0, 0, 0) # reserved fields file.write (header) file.write (open (arcname, "rb").read()) # create_exe() def get_exe_bytes (self): import zlib, base64 return zlib.decompress (base64.decodestring (EXEDATA)) # class bdist_wininst if __name__ == '__main__': import zlib, base64 file = r"c:\wininst\wininst.exe" data = open (file, "rb").read() cdata = zlib.compress (data, 9) bdata = base64.encodestring (cdata) open ("EXEDATA", "w").write (bdata) print "%d %d %d" % (len (data), len (cdata), len (bdata)) EXEDATA = """ eNrtfQt4U9eV7pEl28IIJIJNlMRJlCBaN3JcE5uMiYDK2HJMsI1s2TIkDsbYMrLwK9IRj4akENkT DhvlMU06aW/bSZp2pnMnM5OZ5jY0bYONSQzkwcMp0JJpIO1NZQyEJATMU/df+2z5BalnvszMN/f7 fPi29jl7r7X2WmuvvdbaW0em9P6nJK0kSTqUWEyStknq5ZDGv46iTL31tanSK5PeuW2bpuSd2yp9 TUFLe6BtVaCuxVJf19raJltWei2BUKulqdVSuMRtaWlr8GZNmZJiFTT66x9r/ceEE/Pj5eAtR+e/ hDrrlg/n/zPqitujvN57c2z+TzjMyfmfCdgXeP9HvPbrjnO8iqZ6H/XFeXQ5JalEo5M8rxTPHebb qJmsSVKFdKltf1OCD1P82aHem1S9SNJwLT0v4HAl8E+TeDYNtZtG6Ci1UpK20s1TkuRLkP7zLvC5 VfPF3Vmyd51MkiwQDDnGMIbLIkkrsgINdXKdJL0/WchuGtaJNGwLjiwVTCrMwscKFZnXo+G6sgLB QL0kZH1K0Nt4NT1p4pq4Jq6Ja+KauCauiWvimrgmrolr4vpvvarYCebUe9jpzi65aou+Y7e8ZOP5 mlDhlmKNY+P57A3RjedzHp2x8XyrPHnj+UDot28mTSka6HszKaVo4EykVO/Xl7tiaaddDim80zAv JaSj/s1JIFk08I+bpxY5Bv5u41ek5Q/29HiYbNV7ooftkrSMTXllnUOKFGoS2JSXcde5+0VqCKV7 otvQ7wDJ50HS43qReqM/RNvAHa7yWNogWpfxxs6uZfKNPtMKh+SKrkO/JzaHwzbjPrzTtLwHgm06 YcIO2e2pVvtiab8COpvzY+LWO4hySdpOFKpdivNM7CAkYIc7j8jfjDkH3ZHO01diMV86DRBLc5SD Xd7iilUZQB/aSow5Lw1kQ9Jzh2/qCh81hLvqXXG01KvQohfxGd6Z6o6FBn0JOkmKzcl+gniaB5hq vxQ7uGzZwMZY6EwsTY8W5ry0rHb5A7tVMej0IafLM9epf51u5TkuqN5V7omF9C6fNA3E0p4ifUU6 pUuxGLXG0kzlfE7wEEvbis6BpM28V4UBwGY0RkpNttPlkY5EFc/gQftP+WSaVDi/yVfCZZmzM0Lc FoJqTtfyOF9Qb8RpcAE2xsf1UcsoGjFOo+ZqGrt7XtiGSfGEBxPkRWwONYYHtXJBeFAjL/TP9KXX OSRfB/AE2sHwYJI8I2d3eDDZ+Gz3ovCxhHzW/SKRGOjtTaSaThz8mqXLe8Bgj9/q8xGybDUNEYgm Lae5chDz5W5Pztlqj4+OJvxaj1/jo3MKri2ZrGQwHIvJtojzkqs6ltZMyvV4/AmeasUJiGfwXM3m byTAw7FD4YuxkC6na+AmgtG5Y2nPocPNTscOMaeBleoVPXuTT6abFoGpuvOsfB/bYDVtXCDJ+f4a TyxNoik/vazz7DI5G+sFQ7o4baKc6qfnXBfZfLVsjf4rpmXZ2R6TPOXNpJqi0GsQGcR7fK/SCV5a CbHmy64jRbe7aHW8dpkMzzDwu/AJAyu0prvZzSRhFXPMgDiFVlNO7NdA7Zq7wWoJTcvpCs/nyjQ+ 0+VAr6Waqwh6zKiurkI1L9bHToevxEJ+dQBMWugG6qYSvRHzvQxr09jxW2AN/EN40CVPcqlsDdwB EGs0EQuBQxDDKnV/whjaUwnSJ0OK/sfU0a3R1y6CdKTQmuqCFNmNrDilkTkM5H7mkSVTBz7M9JHu gk7zSBPATK3266o96qR52BwxaQdJtZP5MDUYZuCW6upqf8LQ3EVjB+0fh9J5f/EIZbZc4srEZCew N2qXP/gAHsicwifyMLkhQyMr0jfO10vGzu+TdP68iHOXH3if3S1JrOg6QDvYIybF+Tb8hl+jON9j RTMeUJyH/Xm+XRiGoD9xKY/silZOkTDf8jSX72W0RyM06ezwsoGvEYjOFa2cCj+HpXKDy/d9Amim BbzmOna4OlomcRcIQFf01wYiUytnuXwdBOaM07m5sbMrNCO2ZkYsZILVR0vuJiSDX/PAQELOEb4O HKSpHrJbjy9Kq3EfV4SV26oHqjH7NfhMj6WlogkatnCXky58rxmugJWa3OxBg6eabZh8IVI4+bji vGQrNtj2hvtnsP3aC5vyXIsTk5SqM8bObwM87DVJjeF1KZLxiQ14HNCyqjOs5NY7IrpbI7nTtJ8R uCbB2LkKnZsWuBZrdcbOBwivNwscR1JvNW5feotSddq43WUxbneka/u0vRg+Ms9k3F6UbtzuuVG7 S7tfW3UmUnjjLYrzRKQzyn3z/DnwY/zed7qOpvkrc1QVqv3CV3Yk0pPiHASxG11qXyx0Gt0nqFvQ 2itJQ/cDuUQmdeOvEv+E5xq5wRPHGnT5pehqbkwUSxbHQic8rujP1KXa2WXs6BhB5scgE4nQfbhf q+12+U7QVP4tJw7g0JQ44HODNLvOS2wORRXjq46U7qMmjOTTDAecgxgccz4yBh0ESswJHTlS5qLa +pcgpnqV3fClA+ew3nRkizw9QBrw9ZD2TanGEfpYnWgrTXSVHr7O7YmUJByvtuWbbPmGcPTuTXNp etnpiG6GsfNFSLQpb50n9zpj51/jvvOsceuTqLGSddt1oNGolEZZsUkp/ZQVG5TSs6xYz04rpads 7aZqNSGA4SI+r450vk/iorGYe0V5vtsvqY2+vJU88haqHdaI8yjkd/sTolcuIPaVHvWUu6IlXO/p FAtm9gzc4jOvHFrgA8m+M1AuJidMulyW0xWPwuET6fAeLorWOdBOdXXE+cdqV+wgRrkVt+TjKNrz u2LcDYEMHKmNx0sDpAQRSgsQbCleNmNo3/NMnRdDpPPMFTWOzuNiICWxIATlnHX5NWqfx0UH6xsR McjknIO9zkFSnSviPOOTvgkcD5KCS7E0HbrjoxIADO8SJ20Yps7TE+4o9GKES2NHgHHNQoBXQojx zkseTl2vUkdXytyQQU6EpcBlUE6w6USqRk1UEinfouCiN3a8hba5ifvQgIhJvmNOJbnYql+e0EqS seOv6PsGFzdH34B2OC/KBKgvox6QouWQqqe0DWQIUZ8ZXVWxgz4D1RjJivvBleq9BfdRcZ8OLVqk WKU13ff2yhHUKDJgmn/zOaYZYKnLAGKuiqWtc1F2Mjfxx1uxgjq+/V/PnV+zXMnm/L08lj9P9G6w p0FUWzaGPYTtBx+Qzf5s30/JgjaTBQvWKJPaTrbwehdEqPZEH8lGyk35cqHvKBKhagRIi2/DsAng OcO3Tn3mzn0QLdmu6KIzsAYssigPpMK7Z9Qu37STprkHXkEfPuG4k+fYVZ5qY8ejuCuW7XeehgHJ puLQQ36K3Cu49gYo1q4QrkhVpWxtUBUZ/QEWZP93gGV8tdBaU1xs7LgdpO78E6DknHA0UdYXF4dm +pMGEvwwt+jLFMSWcXv3faxSqomlbeRpZX8FyLBmayWbv5RWoeTrB0QVUrGbK8tJxD4/0g084853 FLPjO8H7OTrXmI+vF04YzXkU2qK3fx1LYhv11iyTp/Ag4Ylq0CjY8ETNXxdKnuTxRFPPEoOe6EAW 0J7fDjQpevFTLL85G8lI5vxxPaEcHIy7/+uj3RDJtzPOjjqVA5N9L41h0K+J895PMZDH36VIDtHV 7yE3LFsrfRsfBlIUSB5FmARfdlwfOUfcXCEeKOROVSG/cftOqS10/8vTWtoy8Qeu7F8g7fInIVcp tDZEX8IDUvCdprkl1kq01ISm2rtDKb514LP/e1grL3QwSgkTQzqlxFqDlJ3fVBK4/LVtNI7LTclZ NglD5P94gVSF9HuYh5zdAK+Rre44Yyo0eIj+XEC7R0BWhu4i+FBmbA4NTomgr7J+hIMzoMnk4mr0 qLoYuJPdTPWwCXlgDfPiysYDGOofYojHQkr1HDtMEg8FjvAjBqN8PZJznj6pu6x2moVXJFJfxNmF 2MA3E6T6w1DfgwY4B5Ij5bvLzp3P2e07g+HK1Quj/QpmizswnUkeZL6FopE7dgiyKs7UWFo6nl+3 PEx282wmTM3l8Rv9RuTyVnSAeRgXjylpZkpzow8JmBR/CrX2cU4NJE1aKo8cXSp768BR7fKcrgd2 q6JtyzDBVqszSQjsj2A0RK7XeZjeEeh1vj/7VoekhP6ohI7C40nfIhtzRpXQiVhaDdentFFSnKdj aRlAw6Y64jz8y7wGSKKEBpUHEZdWAIoyz+s9vky0+wwNQxs87rgojes8/DEWg9Qwcgo9ZLDzSX+I Qf5pEMRvwofHo0J7XLCItAaemWI3F0vzqRlpM7Woey/P60fXxRc3/FKaDxz6aDl6oic/gVW9SIsS C5hYe6phOON/+LS6fbpeXbyuqP4cQec+oUIji1/af4kmnd3cQNuqatd2mia/69e/ohhY9fpmknNj A/HTVx3degrYsTmE7ndxf1zlWxfvbBvu9NEX53wpV/na1X7+FF0MGHbzCjoIUSFzTlb5GlQIteFF irVVvqWj2iicVflKxEgv0kqJGq6QJKryDcS77570+HT4vbT3iaV1lMcdlroheIGo1drfQPRJxvTU 8HC0HMbztnpRrphzwL7DI+ew4nT7HjlTcaUqLr3iMrOHDOd+f9PZivBHyS5lNnOks+LU8uhAIk9j iYhO2kY5Ct08Fb/4sRE2zPewonR4yhxWZu3cLWcyRyqeUpAzvzWd8PXoZmUZrvKYx4qn3qJ0Oty6 BlHwh+1ITszea+w4B5At0pYptPO6p9vY+SfaOG2wmvOMne9L3Jka7OdCKRy/lmRkRRblUbO9N5TS W2Qx5cHEH82Y+6g1lNxbZM3GIzjwY1MEJiwQyd6rFKUD/dIQeonVpKxLZZ50+17lm4ZHDGD63G97 HZQWSuHz+g3LwueN36pE/zZq6Tuq3GdiZems3HDudzcdcJ07sOnDo3c7pAqkBVAaejCIkk/0PHO/ mRoyRveC0+Hhou14pAQW957oz6hvSJLabRe4UkzDmlYvRHI6o+g8i3iu09GmNZ22I+ex/sMLkBBR eGBIRXKOhC/otiMcxIzP9iz+dSJJ8IeLSo3VTDOhD5+fYnx8J4UyayQ7gzSj69xt7NiMlkU5B5Qy HSvT57OLSpmeTd0yTXHpCGsGdgLhY8aFG8/rlRlyWq80hWbBk95bZL4Ew1X8uoEfAYS5TN39unC3 3r5njXkkUFQF6v8muOqlkyhwryPup2HY4pzdShGG0TvYRbY8XSnSs6ScA7++lWxA71CSWIGu+6he 233u884D8m29Wk4WTEEiLh3o7yP6Pl0/HXKc7bYYOzdhjF5tMkHGwfovQ8cw7GpPedRB+hvEJIVj l0Nm4jFBUO118PeJ+vfRWUgslMAuhmMaY2dTgjrmReZKjRTryj0V0bfVJjqbLDbA8if3SgbC/M4V klE/LOOdACzGGEJIkhYSsotb9N3HzMp9uCchMbQ0aRhpkHIGD+ageKHi0XPU9JwDW6aBg2J994cm 7R6leARmyjDm638eUz8Gc/IwZscITI4GfI5ZDCSYxDAan2vMsrFjGSl6xExvEzP9FDbMoyaJHwLy gUKTWC9F7R36EXzC9Ip0GIp03P2hGX4JKipLx3C9Gu21MGcUj9JnUfqWFJod6NSk3a+iezg65bhX o08dQj8g0K+tICXji3i+SkOj9KNXyrJ7pSQMvY0EH8IdYWlF5p9CWcLghANQoYaGKkvv1ZBRca8j GrddHoZExRHpfpXVIf0e5b2vOKSpX3VIpSibUd5DqZrlkHagnEOZjf7VKAYsfjNK3L9w/0s+vZqO 0FnZPIV0uMFqCg/q5ETKHKcyj4Hdm1HhilWTKw8vSApNgfuoLo9uvF64+oxeEllSinKVomxWlCfc fWcX3DLdyFOR5ONfbJ9SNE+5N7t2ec+Qf6OzKKvJ7/BrMAjGsLDTdIpyNqSjU1S2JMP3PCzJry9H F/nXIivmZRqrzvBUqAzxI4EeMjkQcPs1rjhgBgBvRXwCbDnBohvgHtcotBLadWoPV3uU5ZlKWZ4q SPQj/uWAgacqPaP8cfhENlSW58Z4eVVMz+ApCyxsdTqyagNbnEvnt6wg22PfVa1UIrqUWAuDibbu 4oFEVpBp66YdJtOGBycZH7/BQM64swQBBOo3hy9rg/MYYW+wptKynAI3lrO7eIuxt9BK70JKbD97 p+/D8Bt6GmPyp/cCQwGiAvjAuwM6wmNvho8ms137o+FjmvCgVllsXvs0xpAxRviktlfLXfA74WPJ 3ae0fads/YTf3wxLQgQppm1oRaTEmuGKVFqzy/GYV+GKvoSZhJJqAJFLgod3ppbjObOCGlzlFVE2 hZ+pKQXcmXwMrkGcCPMRSZ39KRhhZCOt7P7PyS+jhWYfhFPDly3BTGQqF4wdzyeR6NBfyRb9kmGx N5DYDsDR8UDgPXaQvYsQfIzeku0+bsrZb+z8ESGeZN32N5TFOqXZajZ2fEUj1qKi7X/sCpfU1HnA 2PGrJC5XOqJg5w9ILcFMdBXaD4ZmYv7Ywxn2XvkGdsi+D2wUBpNtO4rZrgGd7VP2rsKxQqvAdAko FLvK3Yo7N/qzm0DEncuC2ZRqHASPJSoqe9e2ZxHmf3GmbQ+MgNDt+0IWGuIcH+KgGOLTMoZ5tO1g u9QhjB3Lk3hwh0Xp4lZg37Emge2wd+OzG+pLhfoK2S62v7s/4bOfsD2ATg8f09r2ffZjMm2uXNla qCWSqWyxzjaoPW3bRarEbBRi4HRoytjpI79dYFa/OUuGqqovq7MTvjw1mDfSLO8a3yyncpM8EDfJ WbFvAGoXDCR87Nbw+ZuNjyeRWPuQPMEQNl14no6dHv8Ui7w7mhg+eqtfF+nQJ9AhGsZ1seKM8piL L+gCfhAbIcBTU8Mnp/YWULhFwCdXOqAXxpTK3FiS+u7jKeEdOvuOoI9W1l0kAmHnJv07VhVnny3W 8+UEi2Wpkedo47LYQFase5q59QsVt57twFDxcQLPAWHbdJqhXcHbCHkIqVf3NB8JWGwP8Oy7Ah/Q gmOLrRWRAlPEnVpe0StR1uJiBQZXdNF16ooqtJrBcudtEFgp0PdqE0eLWaCjUfaR0j68FXqLdCSQ 1uy7jOGHKaQXmOzRYA7luGRKdspQ9+fs3mK8jxwTiQ2h+z6M6wGi26Nc8neYrnMpnQ4uTp35JsJc ZbcmousGkpk5dOFBE/jKDd7E9tiOM7eh7xSYUHRboHEHmOw/Rnnn4HW/IGlkbaT403D0OrJmsizt Husg7rPDXZPt/UF7nLOjumtzhv7skdz1c+52U7LL9mBcUGWGCHE6811tNz32ndLusfUTQ9S3WEer givn2K2RrSmkHFoe2n32/cbH/17Hn3IJL3zBFJoUPq8xPvZttPIniMYqt1waSMg5wB425BcrlU9e Cn1Oeleg9C9W/WOd5GPgFZjbCrBycqgO+NNCfpeJO2s5TKKC7QNa93HCL1+YqAFyhau3IJXbM7zs JLV2kPuMfjeN7MFK9kD2wf0OXxVW3GJl6MlKclV5islHY/x55J8tBJteDi/+UTI3KVoB1ToyJ53q mkeYUyFwaT8UtCir01k2O6Qg2yvW2w4qeVpyKyWU6CCcVbjcyuLc6HucoiE8iDSZ59Uy8At0HhfY ruQxdKWR9kQ68qYLmFvESDNiJDi2kwtKJZu6ZoQs4IZPX633anlevmsQWgWHgru9zMR8ehuxVajt B1cl5S6RUSk+vZLHHfLtMziH6klRdk9cwF4tKTf8xmWs5V6HeZ0XmatKFZgQWc8O+S/b9tMcao+7 BDkI3Jc2mlzJEDezWZNeKdexfdCVBsMUao9zfTXpKxAaCnKjz12NqnLB9vkv9+ablw7zQLRsB7XH OaHicmW9DmQ4EfdVRMxcI4st5OjVOfPp2X4wwedJZUJopYIE4WIY0sZqxcxFQRIDB0hk5pI4+TqK yey0orGd054CD9Ao0YNE0d2pVyu2cshyoDDkRCa2Nz49/kuu4UmJpP6ZSWGHMCG5V00InwzI4788 YjoKxxC65sIID14OJQna43BJ+iwfwegfp1/FqEA9BBPxDTHFlTLG+MDeT74Q/d9lu41Xo8MjVQxL 5yI3KCTbC62ZR2mNRIP4QzNweYRgk0eTpvOV0UoqGakkdUGMENZcMWIStl93zdn8IvRhSwBueAwu fJerwh1tHt2s7uYHDESAuymZu7gSUHB53NEFgIZHYW6edO2X/4I4xNgK/A3FkizFo2OHXLbfsFa9 9rhHadUrC/joiWOH0V9rGDO3mAIuTRbrJWIeve0Nv0a7z0O7bJXWL6Zdc2Vy3NGrkyZmxAJV54XT CE0bqw3zkDbdliF86JM2LFfYfk6jmFzFEI3ZY2jEznzNIZ28wyGtsCGaZzqke+50SLdlOaT2bId0 /RyH9CjKDpSlgFmDchhl2WzHqCMo2hsaaItm8Eue6ug7n8AR35vByrCVMvDTPYaNVRFtrLBBxBN1 6KvFsR/tsUZvn0bQY3tF7v6xCbu9FLHZ3WGQaG9l7jxi/MuP6X24TRdfhstiPYHEbXRjO4wUxLj1 BbLWaPdJXc6BcNS0ZUb4TZN2D5IVzyfa8+rNp/Gbz+I3Z+I3n8dvzsZvzsVvBuM35+M3F+I3F+M3 l+I3l+M3V+I3MbrRni81djbE6K0a2YDWGdo9RdrzxaEzrDvnwC8+gcjnPmG92+mGAevcuc4j7ILx 8enAeJD1PtB91FQ7uZsUEd+fY6b1rvLoB9x160crlL71c0XN3Bvqevhzqj8dm+mhvBlc3L6l0qrb AiqbXSaYlmFz8TTudfkbh3QeXGzuGdrfppL+LfzY0cq0SKMQkjOYx8KwtW/VIWZbmSe3mj2KXQyC twnBewcF76JM2w7amLFSKXwe+9srSfywUe9wSPMpOTI+9gP1ONeUYnzsr1Rnk8Htu4hCT6byaDqz YzPCdtn2sof12vOKVnlYr3hyWZWZOVPdngqkiKXToM8qE+07g5ReINXfBR4fTcfIhXQaXEms0i7c AXbDO82cx+yRPHbuJi7l6YvO/fam3eFjCeHuZKVU6nfSLtiZSmOYFKdeKTX0OtUjS6fBPhgsjG8g anTq0WUh37VmItvJlviRJbZje/uOQqCMcK9+8i6gYWQSMDPfTmlvZuBXzKAm1hB8JgD0Ed0uTsm8 pZjCfUZflBJXrm7KZ822wZyuLRp6L4gt4vFYKdWDK76nfhZ55k9Ncnr4qBHssnyd4uQg6Kfdbn+I +h3GDidk+KnF2PEHLdc49ZNH7a+iPNWph2gL46LdqONb4sxi/hIaRh4hUFxOEkw/VrDX4zsGtM/s ZqU67S4SRynVsVJ9XxRDUhanymUbZE4zpHbqMZnQ8hj1fkf7363eEUqMK5mmngJyf/ZlrsRO+gJd cRqg5YihW0xE//TLV2nwcMJ/kgYNcQ0a4hpMHKnBogxsv0gH2GumwarhdbU7bISnJtBI69HPd0FO XWcXcQzVauhETn3Xh5Vl2vdTOh66jZZ1WYa9W57O9tv3qSuF3ks023YMcH3A/lbRMqy0Zle4PdG3 UujQl5bYPL7EDFhiyLZGLjFQpzUmRrgd5Ckf+7NDGDuOaNQDmYVDcz5p8320lUrPL7aXZYqpSw0l gxyXrFS3CBZm7Mygbxec6o+Xv3WRvO6XlvFPk/5rZORfcJUOmcLmlIVkKalx7rsv8F1OBlyhcIrM BlfIdvUW8PzQ9o6ihV9UvaJgdd6kEUE/tQek+N6xwOxodFzLxRJB7mWxyXnHLbwskpnc6Kf6L6CU AUoDr/xHGXtxNLk/x4qitb0zFr1hNHo4lrwmjfAJOfyxHjtyIkacQJnAcwEnW8+njZXxKdsj0xED 57nMwlFtNBqWm4udd9sus9V67cfKZGW1Kv5nyWPF1187SA1rUDNGgy8n/7tF9l8ZgyuPxn3qvTyH 9PRch9R8j0M6jfJPdodkneeQFs5H7vYNh/QkSukCPsU6F08S1L3B2ASh3E3JlsWv80+H2fEfnMfP 2Q9TcnAkNEn9hvKBZZR1ppPJeqpYszU9AtbddNZrqahy8fP76f7p5dEHiMLp8M6M8JXLoRtZdYa7 ovde89a1Dkk9V2dvPriciIWvXJSTwo9IUsiAfh/6X6evMDjCaMhR+cymE6dpgK3WMxJ/jYm9YqVX BHJOVivN1kKUYpQSFBdKJcpSlBqUFSgNKD6UZpR2FBllHcoG5SUrvdfMDjJNuFvHajoKI4UdhQX3 KebQybmytTB0K0bkL8g+Y03n78wpX1PuoMnYtJP46WHf5+2/oIwgQom5nc5Q52aEJuWHu3Th88Y1 n7Fu+3lazcEkMk12/jUjwb7CB56bFdLfFz6ls/8mdMZ+AVlK5pokfth1gb63kxR730f2PcHrIjVb C20562blh3t0+9ES+DRieJbnaJiFSI2hkJUYCm2fKLLVsd409I2QYFH7LqTcTMCTc3bfJ0/POaIt SS8GpfuUrenUHvoY0nFlHmH80PIdOv+Vb2fPbKW3W9lL1gz6/cBW/qTUPCstVKaRSeSchHL06Cqw /zbwBp0rsQ/OHWFbUznWMxxLUSFoddm7oXEreOFkgA+7M9PPEdC0k5qarfOMT25K4GdGuZGSjkIe DSlzS2H7F3UeIGGNHQsAEDHY7d3GJ5I1XAN5CGviywJAZ8JG6egiT/uBrc+p3Ws/RAf+BLYmAXv0 ZnC5y/aW+OI+8ojG3rvmq+G9Maz7ZmuGthfqNufjYzp7RBd+Q7f/KPqTbb1oCpxkHVZ6h3Y7x/0T kzDV87SDm2L0RZTx8Y9VM7GQrjJ30HqJPNNBggk0hc7LzZ1dyh1yHuXQm5GAKq/wF4j5Qfpbmwut sxG93+yLsvsukb9jn9s+6b6itZ1WUrsVuVs3MAmkyBoV8h9ELhVqeDJGKdtWru4t+6CJ9Dv6Nlda Z4MXUn3E8LT9fCD5TbjDroFi9heApPcY7J8EUzddoUz2pgPhD58P71gBnOwBi+0TANB7g90fJWxJ nY0Hem9w4w4Xy51NEOFeHcROZ5SHWG1vvcZ18SF7qy9qR1QM3hIpeUMCD9naHcrcyLzfcCN9SIdp QG/gI0iVylUfuY++cbH2He3cIetz9u2Pdu4IDXLFsrdy9pGioOCt6tvVHR3CYqxLZl6wn5etoG8O R3VLwAj/msj2gcAEjp7DhN6nqMutYheFUguPtLuNnTsu8696eJLlIFunvIgOHDOMTzytfrfhyDlp /1y+HjuSTI1s2nZx9GqirevQA33hSk4y/jzKv1bxbzDz/DofmQQZ+zWc7GTxGsiDqpulr9KsZMBD TjaXDmwzXeW+5yocks9MH3QqXFURPU5ZATnczrPGzj7ViqzhPMnY8aYkzrARaIYI5RGhDP6bjHLf U24i5qafIhl+WlEe/eEwrZCV4ML3SCH9pss01Nrp9P3piG9HH+RenJz8kgx3OZx43rphJx/vvgjX KbrT1wkfPxbmkkwhYHAoBBD8WJgRseS9tVcPo5J45ZpRRIUZ3g/r2JQVlPxUWvWK/oWGRp5WG5QE OpDJ6erV+NDSm+Bb46CJLKfdroHvds1sNfa1D2ezIoP9MmXwZHdrtGx1Jisy2T62R+FYop0nZSNM xnIxRGkc/3abeVJtb2h/oxSZFE8qK8jDhnsqWzyvqro8tk8pmEdfib/DznEjFV/T0cnSnvAxrfaN z37M2xdnai/DRHEbepQV5LIgklX6ujSkVYK5tNTBmu0Uu9f0xUxUq0zca1KqRzLhEUzcm82dzzts PxvkTGjfYHvENsssWFHUw+B0UlTtcqXcoBQQlnmEeul8gOd/cNnuKtaUy8otHvZQdjXLYw6d/RSn mJ9OmgtOsn1eBiFS4c4WZSJFpG8gydOrX9rwHB6rc/jREh5MDd5OGdMiiqD0jRD7hO3q+yjcpZ98 8F70Bj7kroAwZWv2zD05R7akvxvJfbfziLHjCQpsu7eUafqOYxOEcc72mEJzz/Zg+zaTYo3hB3yD tVw3c4/2rZGIVddAlHvDfzDaegQSMMrotdlMeJ7j4UHjn2XSOMSkheLbMJNXMTebM5eo+SLmrmJq L5iy9wRt/JtV82gezoOHP9Gulvg4lG/voX1J4BCbp1Iu0828YOvRnmdvwdwz2ed9x+kg0faWmJQ8 tijD9on9XOB6xKJzzi1TizaXxkQVHkgYsNouA5fgHsq0nbN/sGa67YMtUzeXSs6iJaGzakeGaFiM BrA3cMMQ/1vKdOihAZ3EcOqmDdZUOhIK3MOPgwI5/Qnqt2bzwJyJPaTrzeebDttnMJ9MdppY7j6l tX9mfIzeA+zvU18GVKHLdLa32OHuAa39t8EELl6e7bzitkRS3+Fbkx1KQTo3/RnYUxfp6VW3vcoC 2x5tt4Kn1bmqp6Oc+2yPRfb8p9EdenmHbwVGyea4lmwBHaMGGuYKH+ZzdRh2SAykPc3y9YixbLbt oDJXu6NWyadxEJrII6q7hqeeis06Qy8gz7rEP3X0tugsPf808890/mnAp/p+aPl8erEV0UMfSN3U T/d30kenhrcHTyBR2dmpYceYHuvbRT9g8cd8+kqElewyh9TwAv/TVw3KLKrDJ3xuT7XijeYcUR68 5E+Ipb1Cr8WGp+TRW+/hKfOoiqVtoxeqp7xNi14fS+viT7v40ws76UF60QHA6P09sdjcm5+n3yEb fLeX0Quvu4hctJ/+nJVhBVjQ4yP6Hr3mvpPwnc9EnM+4YnO66MfMzu+7Is6nUJ53xdL20cvFOkKR COUF/os86wvv0XDZSmjrxgW3h+4pws2WpHt6ZN2820OfUpNuRJNlzafKg/sizh+DXAfwzjr3aeRp xled7w1M3bjAsuYwwQ587k9Z6vK43bG0pfxt5Rl99Au154BzmMZynoAeJymlm13l0RkS/Vyhh3mj sdDmWNpR9L8dm/VHPm/v88+3XfwVbi19aKTo9SpCTlfP28NXbNbLHPYllzqjE7+g///7Sr0fH/er 99PEX2rbukySvo+yDWUnyksoH6K8t0yFe88jSVdQDNWSZEW5G+U+lJ1oi6Ksw/0WlB+ivETtKEdR nkPfKyh/i3I/nn0oMu67sMe/B3URSgXKYygNHnWs+8HbGpSNKP8KuB+ibEV5FOUASivKcpT7UBag ZKFYUdJRpqIkoZwG7kco76PchTIPpQjFhfIcSgNKK8oBlCdQulB+hPISys9R9gj9NC5FP8qPUP4J RYeSimJByUJZiOJB6ULZh7IC+ipDmYeShXILigHlCvp+j3IcZQNK67KRM0LfUal/Ng/zIV0nWulw iA7S6YyMDuTpVVw6o6UXa+lMjN7fpFNveu2TDuSnShL/OsEo8C1NrY3NdbLXMjtrdlaOpaCtfX2g aZVPtsyeO3fOnfjIs5TWBVZb8huavQGLNPQ3IRPFeMmCh0li7MliLKPgk95EIodxEwq9Uz2Tggm9 gk9vKKEU0PEKCv1twCC5QxT6RWgPyh+IZ81/zG41Y0rCmKIdU3RjSuKYQle7KNIImiP1ENf/FCHz DSi3ocxGyUehv4+4CaWb8OknyigaEKFXi+lnb/QnJzVQIr1sq8EEa7Bz00DXmmwUB8qKL5ZzrFxj 5UgaMU/xuYrPV3zO4vM2WdiLQcgyhVtdLPZvpQ7pE5SXKofHz6R17sKaH9F2Fus2F21vVw23bYQN Z5ZjfY+EQ1sq4J4f0WaltYQ2xwjcC2h73jXhn/6n+6eCJaUFlSU5d2U1NDfDurTNQTnQ7G2F6b+t KWmrr2suCni90j9LRW2Bljq51BsM1q3yovegprSu3dPkXbuksaip2QsfUdDcFvQW17XC2UhzpIKA F56JugDX3tS6CjjXae71ytTkbvqmV8odAZMv3Uh9JXVB2RkItAUk6aEE96jnOwV0YVPAWy+3BdaD 3pQ4vXxZDjStDMneIFqbCZNaK5tavFKtVNgWLAQiPVW2DbW/nFDV2jJKgnqiVultaaensroWktIb b3PVyT48vyKROkqaVgbqAuulHdBQXYN4Qu8CgnYF2urzGxoC0JQkfYVaStsaQs1CM4Cqlgq9zd64 3LkqTtMasAjURjQuapXzpXuubndDSK5H6zDVEbwudlaUOYdmMhVaaG0Ynq+XEtYG24EvN+ZLr2tE +8K2dfnSs1JhU7C9Tq73DUM/llAZqGsNUnARjbBkjcvrXT0MY+QjFDavWiR7W4aaM0n7orHSuw6S 3C0V+Lz1qyvqGpraFoZkua1Vkn4hOYHaVNfctkrSkTSjMF5Fb93KZm91U2tD21qKI8MQkvRLwnXV QRSsKOpxrw9yDqCe+iB5wIXeVU2tAqID2m5UCfGZkaSnE6raGyBYnLo/we1rWxt/WibsTH12Qj+f aipAD0MECprrgmRh3+PzXhAKBNsC+dK3JVUQKNNVF6hryZeq3M6K+Dy4xWwvWemH3UrSZxo3WdQ6 uaCtmew6MYEeloQgtvQu9S1cjZn1Sr24bwZGHO/u+GppI+soFU/utuamhoWBUBDZ/b2Fi8SgDxPH 5SFvYL2nrjnkJSGkALUtafe2Lvaup4b8Qk++K44g7UrAspfbcPdzuquvw4h/l4Ahmpvb6qXXeFv7 etJdi9okvZ6gOgp4woRGchFSr0pjtSQd09SuCbaq1obISe2thP4qp+OD1H+d0OJt4RS/S3dBL8Yr SWisJxcCn5fQuDbQJOOuOqGxDTxL2zhmCwL5dpUaGFya0CiGcCTUC65K3Z6CikpVpj6p1ruuSZaK pdql9e3kETCF0qIE3ig9KdXW1bc0NLdKS6Xa2lVeuQX2UhdYFZSMmtqm1iYZwC3IaGprwVwo6CXv 5/MGwPsPgNngDwXl2saGpjWwH8C019bWt7XQ38GWpDb1uVF92qRSqIUTrJXXt6NlD/FV722Xa33c JQSQTr0qAb9VDrQ1N0JGF7dquS4gh9oXtTa25UvbNbUQuyHUPrG5mbgmronrP3RtQJkVnEXbNKmp pb0tIFva15PDakf2YB9xnyVqS0bgq7OCX/0avfUdapWRL1lEGibd39y0Mv6wZI03wB21BT41KCM5 sVCe8g0a5wv6gt9ISXFRbmRZ5nRb5DZLfkl1/jK3pe0LwDNT2jl02RICLnN6nBXjwhbklxU4Szhx 92LskeGlmxpCiBDrs0by1dYuN7W10r51TGZpyZgVJNGlURmuaL0qr72qXW0QW3OkKpYAAkigNWiZ 1UD6F1v2kY2ibRGizl0jO/i2nvbX99SsRUhqDco1jXVNzcEsHgklae1K5PgIojW0Dwda+9B/09DU uqYOmYGlLWBpqGtBYtbAc/22UHODhf7/hnrOrQVpE6wByStXoPRoQ0hytzXKa+sC3hrXetnX1iqq gja0zGrImtVQswhsQJeUEPP9Ne+f1UByrOV2VjMrmNXOO7mZBC1t9fWhQMDbYFnrI/WoNgbNSRRZ 2zlfosUCaWjeULVlZWVJX9BXL/pc62uXYBJbsJsoaq5bhWdYa60bJh5PljlMEQJ7M+04cE86blKf kHEgiyPKqgwqUdU4efCl0ZpUaSFLRcWSinssFd6HQrCToMCxwJqCsCLLbKgmDlOg/h8ZjbA8S13r eksoSMlsHENQrCPjw3iLRjxaaHa9DVy2Ue2kMkoiGyy8z7lODtTVDxs+cU6bmqCloq2lrlXYwqzg 6DkPiCzWspantpZ6ymZV2CzvOm/chtTEl6e6hE8C1rY0tdJ6x6zEPQXu64fuYb9t3BZkXyv2IpLc JDcP0RvFAyVznGfOXasXEjU01ZOMtJ9qaq1vC9AitNB/TGGpp20D91lD7T5vXQMkED1xKxcCBWlW Q62rW9vWqiqjqST1tXih+YZh+JVNsgWp6yrZB6W0eynZleS2NksLzZbooJUDddW11nstwfUtK9ua g0P4QXgJcL4SKedqAR9U+RT0eYea7dFFP9ZOb3RI9MdDTKgllDNeh3QUZR/KNq/aR3K2YCfWROYi LIvwV4YaGyG1V7hgwAXR0lTf5G2VIVwLfJbENSYgkCp64QSG4LnCx/S1jtDHkKD1PGUdam+GmwzU NX9dqET0qmdPdD61IlkcZOnFfy+iV884K/XqeWBFsnpuSO3tos4WBLporSWr51fUvkLUFtH/fPyA VNQbRe0Q/UcFfpJoXypqs+in/6bEnayeU1L7OlHnif59qMqT1TM/aveJOkP0vyye9aLeLOpi0X9a jK8T7ZWipp/fVenV808a3ybaZVHnCvxdYvwpor1B1FbR/1PxHKffIepC0R8V48f5qxF1uuh/juYh WT2fpfYNop4n+g+L+bletDeLOlP0bxPPBlFvFXWJ6B8U42tFe4WorxPyvyjknynaA6K+S+DvFPJP Fu0rRX276P+xeE4Q9WOiXij6/yjGTxbt94v6RtH/jJC/QLR/U9T3iP73hPzTRbtf1HeI/lfEc9w+ t4j6PtF/RoyfKNo9oqZv5LqE3ZL8OaJ9jajvFvhvC/mNor1R1F8R/S+J57h9/6Woi0T/CTH+JNG+ XNS3iP7vC/nrRfujol4g+t8X8t8k2ltFnSX6fyWep4r6CVGXif5LY9Z/ueifJuY/PGb9PyTq2QJ/ x5j1Xyfq20T/j8SzRtSbRJ0v+j8cs/6XifoG0f9XY9b/elHPFf0Hxqz/JlF/TfT/q3iO61cR9SLR /+mY9V8l6jRq16vffYxc/yFRzxH4e8asf6+oZ4n+/y2e4/bVKWqn6D8+Zv0/KOqbRf/3xqz/R0Q9 X/T/bsz6bxH1naL/NfEc5y8i6lLRf2HM+o+PM13Mf8+Y9R8UdY7Af3PM+o/b6UzR/7fiOU4/LOoC 0f/RmPX/gKhvEv3fGbP+Hxa1XfQfHLP+V4vaJvp/Lp7j/DFRLxb9Z8es/2pRX/8F63+tqP9C4L87 Zv2vEvVXRf8/iee4fI+L+l7Rf2rM+q8V9a2i/4dj1v+3RP0N0f/7Meu/TdRfF/2vi+c4f0+Keono v/Il43/3OPH/hXHi/7Fx4v/T48T//ePE/38ZJ/5/8iXj/+5x4v/fjxP/+8eJ/98dJ/7/dpz4/4tx 4v/5Lxn/3xgn/v9knPj/f8eJ/8+OE/9/M078/z/jxP/Pv2T8f2ec+P+P48T/k+PE/x+ME///bZz4 /+tx4v/lLxn/e8aJ/y+OE///ME78//Y48b9vnPj/s3Hi/2dfMv6/NU78/4dx4v/AOPH/f40T/4+M E/9/OU78v/gl43/vOPH/78aJ/38aJ/7/9Tjx/9A48f/VceL/uS8Z//eOE///eZz4//E48f9vxon/ H4wT/7ePE//phSZXoro+qxPVd2Pciep6eiBRfRemPFHVz7JE9V2ZqkR1/T6YqL4bQ/g0v0sT1Xdq KhPV9V+TqL5DU5Goynd/ovqOjSdR9QNdiep7NYSfIMbfJMa/IT6+WR0/OT5+kjp+XXx8ga+Lj69V x58dHz9bHX9KfHyDOn73iPHV8xo6mLM0rG+ta2mqH3G0FLTI9LUoHVYHQyuD9YGmlXTa9UVwI2iN OXbh3WPpXBPG29Iurx8+zaFGy9omdI86oxrmeSQg9Y3ldWx//N0lrXgfySjeCyObIvsim4gBIEZ/ IxQAMQDEAEB/vCv2rfhbcMKnT1wT18Q1cU1cE9fE9V94aXgOZr7qf2zX8D1H9jXak3XqOceKp5Af XeP/t+/S7+I4fO8mpWo+4PUi7CGDkowMqxn/6nDXhKyylaeNpdgfWFDqOAzdeaUA+hvFiBp+fFQp 7ZHuwo6zXxuLbQQM0QqoJycExWGeEDAJEsEUYKQ2UIynJxs5TLq0TfodYAa0LeirB4Vm1LVSO6i1 IdMOAD6Ifzn8NMI1pnW24CmB00qWXpKSkHyeAE+PCflIsnoxok7/LwIuGXAbpSjgNom+SeJYLFna irw3RTrF5ari/FrQtR6UfFxHFoyape4NSQppE8e7Q/oepJ0qfXwNmksEzdPj0Lx7aNbi8vwAOZue vxv+mFQISUhu0lEb7tar5yMj9D0IHtLAw6d8nCz+b+KauCauiWvimrgmrolr4pq4Jq6Ja+L6n3H9 Pzrvwu8= """ --------> end bdist_wininst.py <--------

4 7

Source and patch: swig support (and more)
by Thomas Heller June 21, 2000

June 21, 2000

The included source code and patch implements a swig class (derived from ccompiler). Currently the swig options used cannot be configured with command-line flags or somehow else although they certainly should. Simply include 'xxx.i' files into your extension source-files, and swig will be used to generate 'xxx.cpp' files, which will then be compiled and linked. Other stuff included (only useful for the windows crowd) Resource scripts (*.rc) and message compiler files (*.mc) can also be used as extension source files, and MSVC will invoke rc.exe and mc.exe to create .res files and pass them to the linker. Comments welcome! Thomas

2 1

Traceback in bdist_rpm
by Bastian Kleineidam June 21, 2000

June 21, 2000

Hi, I get the following traceback with bdist_rpm command: calvin@treasure:/~/projects/linkchecker> python setup.py bdist_rpm SSL header file ssl.h found, enabling SSL compilation. running bdist_rpm Traceback (innermost last): File "setup.py", line 116, in ? data_files = [('share/locale/de/LC_MESSAGES', File "/usr/lib/python1.5/site-packages/distutils/core.py", line 111, in setup dist.run_commands () File "setup.py", line 47, in run_commands self.run_command (cmd) File "/usr/lib/python1.5/site-packages/distutils/dist.py", line 787, in run_command cmd_obj.ensure_finalized () File "/usr/lib/python1.5/site-packages/distutils/cmd.py", line 95, in ensure_finalized self.finalize_options () File "/usr/lib/python1.5/site-packages/distutils/command/bdist_rpm.py", line 168, in finalize_options self.finalize_package_data() File "/usr/lib/python1.5/site-packages/distutils/command/bdist_rpm.py", line 191, in finalize_package_data self.changelog = self._format_changelog(self.changelog) File "/usr/lib/python1.5/site-packages/distutils/command/bdist_rpm.py", line 440, in _format_changelog for line in string.split(string.strip(changelog), '\n'): TypeError: read-only character buffer, None calvin@treasure:/~/projects/linkchecker> Reason is that the Command.ensure_string() function has default=None and so self.changelog is None and not "". Bastian

5 7

Re: PyXML build problems
by Greg Ward June 18, 2000

June 18, 2000

[cc'd to distutils-sig, in case anyone out there knows anything about OSF/1 and its progeny] On 18 June 2000, Mark Favas (in private email) said: > The generated ld command above is fine for using through the shell, but > will fail if the quotes are not stripped - the pattern will be a literal > *. If I change the definition for LDSHARED in my > /usr/local/lib/python1.6/config/Makefile from > LDSHARED= ld -shared -expect_unresolved "*" > to > LDSHARED= ld -shared -expect_unresolved * > and re-run "python setup.py build" the link step works fine. The > Makefile is attached. Good thinking -- I was afraid I'd have to implement a general quoting-and-unquoting mechanism when parsing Python's Makefile (or rather, the bits of it that are shell commands). I bet I can get away with an OSF1-specific hack to deal with this problem, though. ;-) Note that (I think) your fix will break builds with the old Makefile.pre.in mechanism, so you'll want to go back to the original Makefile once I've fixed Distutils. BTW, what do os.uname() and sys.platform return on your system? Do you know how consistent these are across various flavours of OSF/1? Also, didn't OSF/1 mutate into Digital Unix, and then Tru64 Unix? Do you know if these later versions are similarly affected? Thanks -- Greg -- Greg Ward - programmer-at-big gward(a)python.net http://starship.python.net/~gward/ Never try to outstubborn a cat.

1 0

OSF/1 glitch?
by A.M. Kuchling June 17, 2000

June 17, 2000

This was reported on the XML-SIG by Mark Favas, and looks like it might be a Distutils problem. ================= The link step also appears to have a wildcard quoting problem. The ld command used is: ld -shared -expect_unresolved "*" build/temp.osf1V-alpha/extensions/pyexpat.o build/temp.osf1V-alpha/extensions/expat/xmltok/xmltok.o build/temp.osf1V-alpha/extensions/expat/xmltok/xmlrole.o ... which works correctly if put into a /bin/sh script produces pyexpat.so without warnings of unresolved externals (the -expect_unresolved "*" pattern matches all). However, when run by Python via the "python setup.py build" command, ld complains about all the unresolved externals: ld: Warning: Unresolved: fread strlen strncpy strcmp ... as if the pattern that ld is trying to match is literally "*" ================= Presumably the link step quotes the * for the sake of the shell, and sysconfig.py doesn't know this, so it winds up passing "*" as the argument. --amk

3 2

remove_tree and PATH_CREATED
by Bastian Kleineidam June 17, 2000

June 17, 2000

Hi, in dir_util.py we have a cache which directories are created: PATH_CREATED. This is filled by mkpath. But it is not emptied by remove_tree because we use shutil.rmtree for this. Reproduce: run "python setup.py sdist bdist_rpm" sdist creates a distribution dir, then deletes it. bdist_rpm runs sdist again and the distribution dir is not created a second time because its in the cache PATH_CREATED. Solution 1: find all directories to be removed and remove them out of PATH_CREATED. However if rmtree gives an error we removed probably too much. Solution 2: get rid of the PATH_CREATED cache. Not a good solution. Solution 3: write your own rmtree function. I would prefer this solution. Bastian

2 3

Fw: CPAN for python?
by Thomas Heller June 8, 2000

June 8, 2000

[Doesn't this also belong to distutils?] From: "Andrew Kuchling" <akuchlin(a)mems-exchange.org> Newsgroups: comp.lang.python To: <python-list(a)python.org> Sent: Thursday, June 08, 2000 4:05 AM Subject: Re: CPAN for python? > [...] The distutils work seems to > be freezing down nicely; the discussions have gone from requirements > to design to implementation, and are now doing the i-dotting and > t-crossing fixes, with the occasional slightly larger upheaval. But > the basic principle of running setup.py seems stable. > > So, what would people want on top of distutils? A Debian-style "do > apt-get, upgrade" to update currently installed packages? A > CPAN-style "fetch and install this module for me, please"? Simple > version checking? > > --amk > -- > http://www.python.org/mailman/listinfo/python-list

1 0

New snapshot (soon)
by Greg Ward June 8, 2000

June 8, 2000

Hi all -- I have just thrown together a new Distutils code snapshot. This is the first of several that will lead up to Distutils 0.9, which I hope to release before Python 1.6a3 (whenever that comes). (And assuming that it's not 1.6b1!) It's not available right now, but should be soon: see http://www.python.org/sigs/distutils-sig/download.html#snapshot Greg -- Greg Ward - geek-on-the-loose gward(a)python.net http://starship.python.net/~gward/ "One world, one web, one program" --Microsoft "Eine volk, eine reich, eine führer" --Hitler

1 0

Re: [Distutils] cleaning up packages
by Michael Muller June 8, 2000

June 8, 2000

Greg Ward wrote: [lots of stuff about file formats for meta-info and for general use deleted] The patch that I submitted uses a format based on that of ConfigParser. It allows for the definition of arbitrary nested syntaxes for defining data. The system currently supports the specification of data elements as simple strings (no embedded newlines or whitespace), lists of simple strings (one per line), lists of words (words being defined as "no embedded whitespace"), and two more specialized types for describing dependencies. Alternate formats can be easily added. I would have liked to have used indentation to define structure, but ConfigParser replaces all indentation in continuation lines with a single blank space. The implementation necessary to parse this syntax is rather complex, but the data formats themselves end up being extremely clean. I have enclosed an example: the package information file generated for Distutils. Note that the "deps" and "compats" fields are not in use at this time. ============================================================================= michaelMuller = mmuller(a)enduden.com | http://www.cloud9.net/~proteus ----------------------------------------------------------------------------- There is no concept that is more demeaning to the human spirit than the notion that our freedom must be limited in the interests of our own protection. =============================================================================

2 1

cleaning up packages
by Randall Hopper June 7, 2000

June 7, 2000

As I install my new module distribution, sprinking .so's and .py's around the Python distribution tree, it occurs to me that I haven't yet read... With DistUtils, what's the command to clean up all the kibbles and bits in the Python tree associated with a package of a given name. Did I miss it? Or is it that not implemented yet? For those familiar with the FreeBSD or Redhat package tools, I'm talking about pkg_delete or rpm -e, respectively (in fact, FreeBSD registers Python packages with the FreeBSD package manager; but not all platforms have this capability). Some related distutils subtasks I also don't know about: 1) Listing what packages are currently installed (pyncurses-0.3, Numeric-15.3, etc.) 2) List what files in the python tree make up a package (/usr/local/python/PLATFORM/plat-irix646-n32/.../site-packages/my.so, etc.) 3) Delete the files for the specified package, and remove the package from the installed list. Is this supported? Slated for the future? Like most folks, I've hit package breakage due to stray files and libs lying around way too many times. And asking users to cd into system-specific paths 10 or more levels deep and rm specific files is a support nightmare. Sure hope we have (or will have) a "delete package" capability. Thanks, Randall -- Randall Hopper aa8vb(a)yahoo.com

5 9

-I paths and ext_modules
by Randall Hopper June 6, 2000

June 6, 2000

Thought I'd try packaging up an OpenDX wrapper using the new Distutils. I need to get a -I path on the cc command line (and a -L/-rpath on the linker line). Is there a way to do this with the current version (portably or UNIX-specific; either one)? I gather from the docs that the Setup Configuration File will eventually take care of this third-party software path configuration. I'm looking for a stopgap until then. If not, is there a "!shell <command>" backdoor that can be used in the meantime? Thanks, Randall -- Randall Hopper (mailto:aa8vb@yahoo.com) EPA Scientific Visualization Center US EPA MD/24 ERC-1A; RTP, NC 27711

2 4

Re: [Distutils] distutils & Cygwin compiler on Win32
by Rene Liebscher June 6, 2000

June 6, 2000

Greg Ward wrote: > > Second, the patch which provides the help-compiler > > option (and help-format, help-formats whatever > > you need.) This is against the cvs from last monday. > > Oh good. I used the current cvs to create an up-to-date patch. It only introduces this help-option option, nothing else. ( Did you have a problem with bdist, I found the current cvs wasn't working, in the run method you wrote self.format which I had to change to format. ) file: help-option.patch > > Finally, while I was working on this help patch, I > > found that everyone who creates a new compiler has > > to change ccompiler.py, which contains the base class > > for all other compilers. Wouldn't it be better, if > > we had a separate file for the compiler mapping, so > > no-one ever has to touch our base file? > > I'm not convinced. If we actually had to change the CCompiler class, > you'd have a point -- that would be a sign of inadequate design. But we > just have to change the tables that drive the factory function, and > those tables and the factory really belong in the same module as the > base class. What's the big deal with tweaking that file occasionally? You could introduce some other things like building the mapping table at runtime, so you only can choose compilers which are really available on your machine. I think such things don't belong in ccompiler.py, it would be to platform-specific. Look at this piece of code to understand what I mean. ----------------------------------- +# Map a platform ('posix', 'nt') to the default compiler type for +# that platform. +default_compiler = { 'posix': 'unix', + 'nt': 'msvc', + } + +# Map compiler types to (module_name, class_name) pairs -- ie. where to +# find the code that implements an interface to this compiler. (The module +# is assumed to be in the 'distutils' package.) +compiler_class = { + # standard for all platforms + 'unix': ('unixccompiler', 'UnixCCompiler',"standard UNIX-style compiler"), + } + +# on NT we have some compilers more +if os.name=='nt': + compiler_class.update({ + 'msvc': ('msvccompiler', 'MSVCCompiler',"Microsoft Visual C++"), + 'cygwin': ('cygwinccompiler', 'CygwinCCompiler',"Cygwin-Gnu-Win32-C-Compiler"), + 'mingw32': ('cygwinccompiler', 'Mingw32CCompiler',"MinGW32-C-Compiler (or cygwin in this mode)"), + }) + +# One could also check if the compiler is really available +# for example: (doesn't really work, because msvc's find_exe return always a name) +# import msvccompiler +# if msvccompiler.find_exe(...): +# compiler_class.update( ... msvc ... ) + ----------------------------------------- (Perhaps, we could divide it in ccompiler.py which contains only the class CCompiler and a file compiler_util.py or compiler_factory.py? for the rest.?) And now some words to your second email. > * constructing a fake Makefile fragment to set sysconfig globals is > excessively baroque: why not do it like this: (I took it directly from a older version of cygwinccompiler.py) > g['CC'] = "cc" # not gcc? I used 'cc' because it is the standard name for a C compiler. I overwrite UnixCCompilers self.cc to change it to 'gcc'. I think as a default assignment it should be set to the standard name 'cc'. (There are more free compilers for Windows out there, what they call their compiler? cc?) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> * I'd rather do nothing about guessing the user's home directory on Windows -- my innocent question started a surprisingly lively thread on the topic in python-dev, and it seems possible that some sort of "userdir" module will wind up in Python 1.6. I'd rather use whatever code comes out of that discussion. However, it does sound reasonable to respect os.environ['HOME'], in which case Mac OS will be the odd man out in 'find_config_files()' instead of Unix. That way, people who really care about having a personal directory on Windows can communicate it to Distutils unambigiously through HOME -- at least until someone figures out the "right way" to find a home directory on Windows. <<<<<<<<<<<<<<<<<<<<<<<<<<<<< Ok, they could set HOME in their login scripts. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Can you redo your modification of dist.py to unify the "posix" and "nt" branches of 'find_config_files()', and drop the HOME-setting code in util.py? Thanks. <<<<<<<<<<<<<<<<<<<<<<<<<<<<< Ok. file: dist_home.patch (It contains only this patch.) >Finally, what's your thought on simplifying the CCompiler API and >relying more on instance attributes? I'd rather do this now so you and >Lyle Johnson (who's doing the Borland C++ port) have to adapt your code >before I check it in. >evil smirk< Any feelings? It sounds good, but if you subclass a compiler class, as I do, only to (ex)change some parameters for the call of its base class method, then you probably had to save instance variables, call the base class method and then restore the instance variables. (Ok, for my class this isn't a big problem, because I could set most changes in __init__(). But it is worth to think about, which parameters are really constant for all cases.) If you have a new version of UnixCCompiler, send me an email and I will change my classes, too. (I will send you then the complete file, not an patch.) I also found some problems with building extensions using my classes. I tried to build a more complex extension (pygtk-0.6.5). This works without problems if you use msvc, but the resulting dll crashs if I use cygwin or mingw32, it is probably a problem with initialization of the dll's. If someone else has more experience with cygwin/mingw32, he could find out if there is a problem with my link parameters in the compiler classes. > I've just gone over your patch, and I think I'd like it better if you'd > "cvs update" and regenerate it. There's at least one bug that we both > fixed, so there may be other conflicts -- and those are easier to deal > with using "cvs" than using "patch". ;-) Most of it is either already checked in or attached to this mail. The rest concerns only my cygwinccompiler.py file, and I will send it as file not as patch. (later this week) I found some problems with sdist. If you add a new package in setup.py (I mean one more entry in the packages list), then it is not included in the resulting source distribution. I think this happens because sdist doesn't check the date of MANIFEST against the date of setup.py (or however this file is called, __file__ would give you the name.) I will see if I can change this. Another problem: If I have an empty package (which contains only an empty __init__.py file, file length=0), then it is included in the zip-file, but you can't find it in the tar.gz-file. Is this a problem of tar and it is worth to be treated specially? (makes it ever sense to have such a module) Kind regards Rene Liebscher diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/dist.py distutils.patched/distutils/dist.py --- distutils.orig/distutils/dist.py Tue Jun 6 11:17:02 2000 +++ distutils.patched/distutils/dist.py Tue Jun 6 12:47:42 2000 @@ -263,24 +263,25 @@ and setup.cfg in the current directory. """ files = [] - if os.name == "posix": - check_environ() + check_environ() - sys_dir = os.path.dirname(sys.modules['distutils'].__file__) - sys_file = os.path.join(sys_dir, "pydistutils.cfg") - if os.path.isfile(sys_file): - files.append(sys_file) + if os.name=='posix': + sys_dir = os.path.dirname(sys.modules['distutils'].__file__) + user_filename = ".pydistutils.cfg" + else: + sys_dir = sysconfig.PREFIX + user_filename = "pydistutils.cfg" + + sys_file = os.path.join(sys_dir, "pydistutils.cfg") + if os.path.isfile(sys_file): + files.append(sys_file) - user_file = os.path.join(os.environ.get('HOME'), - ".pydistutils.cfg") + if os.environ.has_key('HOME'): + user_file = os.path.join(os.environ.get('HOME'), + user_filename) if os.path.isfile(user_file): files.append(user_file) - else: - sys_file = os.path.join (sysconfig.PREFIX, "pydistutils.cfg") - if os.path.isfile(sys_file): - files.append(sys_file) - # All platforms support local setup.cfg local_file = "setup.cfg" if os.path.isfile(local_file): diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/archive_util.py distutils.patched/distutils/archive_util.py --- distutils.orig/distutils/archive_util.py Tue Jun 6 11:17:01 2000 +++ distutils.patched/distutils/archive_util.py Tue Jun 6 11:20:24 2000 @@ -110,11 +110,11 @@ ARCHIVE_FORMATS = { - 'gztar': (make_tarball, [('compress', 'gzip')]), - 'bztar': (make_tarball, [('compress', 'bzip2')]), - 'ztar': (make_tarball, [('compress', 'compress')]), - 'tar': (make_tarball, [('compress', None)]), - 'zip': (make_zipfile, []) + 'gztar': (make_tarball, [('compress', 'gzip')],"gzipped tar-file"), + 'bztar': (make_tarball, [('compress', 'bzip2')],"bzip2-ed tar-file"), + 'ztar': (make_tarball, [('compress', 'compress')],"compressed tar-file"), + 'tar': (make_tarball, [('compress', None)],"uncompressed tar-file"), + 'zip': (make_zipfile, [],"zip-file") } def check_archive_formats (formats): diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/ccompiler.py distutils.patched/distutils/ccompiler.py --- distutils.orig/distutils/ccompiler.py Tue Jun 6 11:17:02 2000 +++ distutils.patched/distutils/ccompiler.py Tue Jun 6 11:22:15 2000 @@ -726,10 +726,22 @@ # Map compiler types to (module_name, class_name) pairs -- ie. where to # find the code that implements an interface to this compiler. (The module # is assumed to be in the 'distutils' package.) -compiler_class = { 'unix': ('unixccompiler', 'UnixCCompiler'), - 'msvc': ('msvccompiler', 'MSVCCompiler'), +compiler_class = { 'unix': ('unixccompiler', 'UnixCCompiler',"standard UNIX-style compiler"), + 'msvc': ('msvccompiler', 'MSVCCompiler',"Microsoft Visual C++"), + 'cygwin': ('cygwinccompiler', 'CygwinCCompiler',"Cygwin-Gnu-Win32-C-Compiler"), + 'mingw32': ('cygwinccompiler', 'Mingw32CCompiler',"MinGW32-C-Compiler (or cygwin in this mode)"), } +# prints all possible arguments to --compiler +def show_compilers(): + from distutils.fancy_getopt import FancyGetopt + list_of_compilers=[] + for compiler in compiler_class.keys(): + list_of_compilers.append(("compiler="+compiler,None,compiler_class[compiler][2])) + list_of_compilers.sort() + pretty_printer=FancyGetopt(list_of_compilers) + pretty_printer.print_help("List of available compilers:") + def new_compiler (plat=None, compiler=None, @@ -755,7 +767,7 @@ if compiler is None: compiler = default_compiler[plat] - (module_name, class_name) = compiler_class[compiler] + (module_name, class_name,long_description) = compiler_class[compiler] except KeyError: msg = "don't know how to compile C/C++ code on platform '%s'" % plat if compiler is not None: diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/command/bdist.py distutils.patched/distutils/command/bdist.py --- distutils.orig/distutils/command/bdist.py Tue Jun 6 11:17:03 2000 +++ distutils.patched/distutils/command/bdist.py Tue Jun 6 11:35:12 2000 @@ -21,8 +21,7 @@ user_options = [('bdist-base=', 'b', "temporary directory for creating built distributions"), ('formats=', None, - "formats for distribution " + - "(gztar, bztar, zip, rpm, ... )"), + "formats for distribution"), ] # The following commands do not take a format option from bdist @@ -33,12 +32,28 @@ default_format = { 'posix': 'gztar', 'nt': 'zip', } - format_command = { 'gztar': 'bdist_dumb', - 'bztar': 'bdist_dumb', - 'ztar': 'bdist_dumb', - 'tar': 'bdist_dumb', - 'rpm': 'bdist_rpm', - 'zip': 'bdist_dumb', } + format_command = { 'gztar': ('bdist_dumb',"gzipped tar-file"), + 'bztar': ('bdist_dumb',"bzip2-ed tar-file"), + 'ztar': ('bdist_dumb',"compressed tar-file"), + 'tar': ('bdist_dumb',"tar-file"), + 'rpm': ('bdist_rpm',"rpm distribution"), + 'zip': ('bdist_dumb',"zip-file"), + } + + # prints all possible arguments to --format + def show_formats(): + from distutils.fancy_getopt import FancyGetopt + list_of_formats=[] + for format in bdist.format_command.keys(): + list_of_formats.append(("formats="+format,None,bdist.format_command[format][1])) + list_of_formats.sort() + pretty_printer=FancyGetopt(list_of_formats) + pretty_printer.print_help("List of available distribution formats:") + + help_options = [ + ('help-formats', None, + "lists available distribution formats",show_formats), + ] def initialize_options (self): @@ -74,14 +89,14 @@ for format in self.formats: try: - cmd_name = self.format_command[self.format] + cmd_name = self.format_command[format][0] except KeyError: raise DistutilsOptionError, \ - "invalid format '%s'" % self.format + "invalid format '%s'" % format sub_cmd = self.reinitialize_command(cmd_name) if cmd_name not in self.no_format_option: - sub_cmd.format = self.format + sub_cmd.format = format self.run_command (cmd_name) # run() diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/command/build.py distutils.patched/distutils/command/build.py --- distutils.orig/distutils/command/build.py Mon May 29 10:26:26 2000 +++ distutils.patched/distutils/command/build.py Tue Jun 6 11:20:24 2000 @@ -9,6 +9,7 @@ import sys, os from distutils.core import Command from distutils.util import get_platform +from distutils.ccompiler import show_compilers class build (Command): @@ -35,6 +36,10 @@ ('force', 'f', "forcibly build everything (ignore file timestamps)"), ] + help_options = [ + ('help-compiler', None, + "lists available compilers",show_compilers), + ] def initialize_options (self): self.build_base = 'build' diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/command/build_clib.py distutils.patched/distutils/command/build_clib.py --- distutils.orig/distutils/command/build_clib.py Thu May 25 03:10:04 2000 +++ distutils.patched/distutils/command/build_clib.py Tue Jun 6 11:20:24 2000 @@ -23,7 +23,7 @@ from types import * from distutils.core import Command from distutils.errors import * -from distutils.ccompiler import new_compiler +from distutils.ccompiler import new_compiler,show_compilers class build_clib (Command): @@ -42,6 +42,10 @@ ('compiler=', 'c', "specify the compiler type"), ] + help_options = [ + ('help-compiler', None, + "lists available compilers",show_compilers), + ] def initialize_options (self): self.build_clib = None diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/command/build_ext.py distutils.patched/distutils/command/build_ext.py --- distutils.orig/distutils/command/build_ext.py Tue Jun 6 11:17:04 2000 +++ distutils.patched/distutils/command/build_ext.py Tue Jun 6 11:25:34 2000 @@ -14,6 +14,7 @@ from distutils.errors import * from distutils.dep_util import newer_group from distutils.extension import Extension +from distutils.ccompiler import show_compilers # An extension name is just a dot-separated list of Python NAMEs (ie. # the same as a fully-qualified module name). @@ -72,6 +73,10 @@ ('compiler=', 'c', "specify the compiler type"), ] + help_options = [ + ('help-compiler', None, + "lists available compilers",show_compilers), + ] def initialize_options (self): diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/command/sdist.py distutils.patched/distutils/command/sdist.py --- distutils.orig/distutils/command/sdist.py Tue Jun 6 11:17:06 2000 +++ distutils.patched/distutils/command/sdist.py Tue Jun 6 11:20:24 2000 @@ -13,7 +13,7 @@ from distutils.core import Command from distutils.util import newer, create_tree, remove_tree, convert_path, \ write_file -from distutils.archive_util import check_archive_formats +from distutils.archive_util import check_archive_formats,ARCHIVE_FORMATS from distutils.text_file import TextFile from distutils.errors import DistutilsExecError, DistutilsOptionError @@ -35,11 +35,26 @@ ('force-manifest', 'f', "forcibly regenerate the manifest and carry on as usual"), ('formats=', None, - "formats for source distribution (tar, ztar, gztar, bztar, or zip)"), + "formats for source distribution"), ('keep-tree', 'k', "keep the distribution tree around after creating " + "archive file(s)"), ] + # prints all possible arguments to --formats + def show_formats(): + from distutils.fancy_getopt import FancyGetopt + list_of_formats=[] + for format in ARCHIVE_FORMATS.keys(): + list_of_formats.append(("formats="+format,None,ARCHIVE_FORMATS[format][2])) + list_of_formats.sort() + pretty_printer=FancyGetopt(list_of_formats) + pretty_printer.print_help("List of available distribution formats:") + + help_options = [ + ('help-formats', None, + "lists available distribution formats",show_formats), + ] + negative_opts = {'use-defaults': 'no-defaults'} default_format = { 'posix': 'gztar', diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/dist.py distutils.patched/distutils/dist.py --- distutils.orig/distutils/dist.py Tue Jun 6 11:17:02 2000 +++ distutils.patched/distutils/dist.py Tue Jun 6 11:20:24 2000 @@ -433,16 +433,38 @@ negative_opt = copy (negative_opt) negative_opt.update (cmd_class.negative_opt) + # Check for help_options in command class + # They have a different format (tuple of four) so we need to preprocess them here + help_options = [] + if hasattr(cmd_class,"help_options") and type (cmd_class.help_options) is ListType: + help_options = map(lambda x:(x[0],x[1],x[2]),cmd_class.help_options) + # All commands support the global options too, just by adding # in 'global_options'. parser.set_option_table (self.global_options + - cmd_class.user_options) + cmd_class.user_options + help_options) parser.set_negative_aliases (negative_opt) (args, opts) = parser.getopt (args[1:]) if hasattr(opts, 'help') and opts.help: self._show_help(parser, display_options=0, commands=[cmd_class]) return + if hasattr(cmd_class,"help_options") and type (cmd_class.help_options) is ListType: + help_option_found=0 + for help_option in cmd_class.help_options: + if hasattr(opts, parser.get_attr_name(help_option[0])): + help_option_found=1 + #print "showing help for option %s of command %s" % (help_option[0],cmd_class) + if callable(help_option[3]): + help_option[3]() + else: + raise DistutilsClassError, \ + ("command class %s must provide " + + "a callable object for help_option '%s'") % \ + (cmd_class,help_option[0]) + if help_option_found: + return + # Put the options from the command-line into their official # holding pen, the 'command_options' dictionary. opt_dict = self.get_option_dict(command) @@ -492,7 +514,11 @@ klass = command else: klass = self.get_command_class (command) - parser.set_option_table (klass.user_options) + if hasattr(klass,"help_options") and type (klass.help_options) is ListType: + parser.set_option_table (klass.user_options+ + map(lambda x:(x[0],x[1],x[2]),klass.help_options)) + else: + parser.set_option_table (klass.user_options) parser.print_help ("Options for '%s' command:" % klass.__name__) print @@ -500,7 +526,7 @@ return # _show_help () - + def handle_display_options (self, option_order): """If there were any non-global "display-only" options

1 0

Patch to bdist_rpm
by Harry Henry Gebel June 6, 2000

June 6, 2000

Here is a patch to bdist_rpm. It does the following: Fills in question marks in help Reads scripts in from files rather than strings Adds RPM 2 compatibility mode (untested). Use of this mode requires that --bdist-base be specified because bdist_rpm has no way of detecting where RPM wants to find spec files and source files. An unmodified RedHat 5.0 system would require '--bdist-base=/usr/src/RedHat'. (You would also have to be root.) If the rpmrc file has been modified to allow RPMs to be built by normal users then --build-base would need to be changed accordingly. Formats the changelog. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware

2 6

bug in install_scripts
by Greg Kochanski June 6, 2000

June 6, 2000

If you are installing from .../bin/foo to /usr/local/bin/foo, distutils installs correctly, but then reports an error when it incorrectly tries to chmod the file /usr/local/bin/bin/foo . The problem seems to be in .../distutils/cmd.py, in the function _copy_files(). It looks as if it should not just do os.path.join, but should drop off the directory parts of f, first with os.path.basename(). setup.py: from distutils.core import setup setup(name="promu1python", version="1.0", description = "Stem-ML level 1 tag set", author = "Greg Kochanski", author_email = "gpk(a)bell-labs.com", url="http://hce.research.bell-labs.com/promu1python", scripts = ["bin/promu1.sh"], packages = ["promu1python"])

3 3

bdist_rpm and RPM 2
by Greg Ward June 4, 2000

June 4, 2000

OK, I've tried out "bdist_rpm" with RPM 2 on my Red Hat 5.2 system. I had to make "rpm_base" an option to "bdist_rpm", so now I run this: ./setup.py bdist_rpm --rpm2-mode --rpm-base=/scratch/rpmtest because my /etc/rpmrc is this: topdir: /scratch/rpmtest pgp_path: /home/greg/.pgp signature: pgp pgp_name: Greg Ward <gward(a)python.net> With this change, bdist_rpm successfully launches RPM, which unpacks and builds. Things start to awry with the pseudo-installation, though: it appears that RPM 2 doesn't know about the %_tmpdir macro. I'll attach the complete output of running "bdist_rpm" on the Distutils, compressed because it's quite big (40k). (Both the Distutils and RPM are very verbose: this is a feature, dammit!) Greg -- Greg Ward - programmer-at-big gward(a)python.net http://starship.python.net/~gward/ I feel like I am sharing a ``CORN-DOG'' with NIKITA KHRUSCHEV ...

1 0

bdist_rpm patch
by Harry Henry Gebel June 3, 2000

June 3, 2000

Here is a patch against the current CVS version of Distutils to make it build RPMs with RPM 3. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware

2 1

Confusing options error msg
by Randall Hopper June 3, 2000

June 3, 2000

Something else I noticed a bit earlier. If you supply all three of: packages, py_modules, and ext_modules, you get an error that says: > setup.py build running build running build_py error: build_py: supplying both 'packages' and 'modules' options is not allowed It's not clear from the message which *_modules variable/variables are the problem. Based on PyNcurses's and Numerical's setup.py files, it's apparent that py_modules is the culprit. Removing it lets the build continue. That said, I do like how easy it appears it's going to be to build and distribution module dists with the new DistUtils. Copy setup.py, tweak, and build. Very nice. Randall

2 1

RPM questions
by Greg Ward June 2, 2000

June 2, 2000

[oops, meant to cc this to the sig] Hi Harry -- [and any other distutils-siggies who know more about RPM than me] I'm beating the hell out of the bdist_rpm command to make it use config files rather than the "package_data" file, and naturally a few questions about RPM arise. Thought I'd ask you and the SIG instead of RTFM'ing. (Hey, I don't have a copy of the RPM book at home... and I have to mooch off someone else's at work.) * are the {pre,post}_{install,uninstall} scripts specified as raw shell code or filenames? * if raw code, d'you think it would be acceptable to specify them as filenames for the Distutils instead of trying to deal with shell (or Python!) code in a config file? * I'm punting on preserving the 'summaries' and 'descriptions' dictionaries: either we craft a mapping syntax in config files, or we expand 'description' and 'long_description' in the setup script so they can be either a string (English description) or a dictionary mapping 2-letter language codes to description in that language. Opinions? * what is "prep" for? is that a pre-build script? is it basically the same as {pre,post}_{install,uninstall}? * what should the default for "packager" be? I initially made it default to "vendor" (which in turn defaults to the "contact" from the setup script, ie. maintainer if present, author otherwise), but then I had a dim recollection that packagers can set their name/address in an RPM config file. True? Should "packager" default to nothing, so RPM fills it in? * should "release" be a string or a number? I've never seen a Red Hat RPM with a non-integer "release", but what're the rules? * what is "serial"? * do you have an example Python module distribution that actually uses most of the RPM options? The Distutils distribution is pretty simple, so I can't fully test "bdist_rpm" with it. * is it really necessary to pass the "--define _topdir ..." to RPM? Recall that this breaks under RPM 2.x, and since I *still* haven't gotten around to upgrading my Red Hat 5.2 system, this bites me. (Who? me? procrastinating?) OK! Enough of that; the good news is, I've rebuild enough of "bdist_rpm" that we're back where we started, ie. it fails-to-work for me just as it failed-to-work before I started ripping it apart. IOW, it creates a reasonable-looking spec file, but dies because of the "rpm --define" option. Well, guess what's next on my agenda. Anyways, using the same ol' Distutils setup script that we're all familiar with, and this setup.cfg: """ [bdist_rpm] release = 3 packager = Harry Henry Gebel <hgebel(a)inet.net> doc_files = CHANGES.txt README.txt USAGE.txt doc/ examples/ changelog = * Wed May 31 2000 Greg Ward <gward(a)python.net> 0.8.3pre-1 - Hacked up bdist_rpm.py, moved meta-data into setup.cfg * Thu May 10 2000 Harry Henry Gebel <hgebel(a)inet.net> 0.8.2-3 - Added new options to package_data * Tue May 09 2000 Harry Henry Gebel <hgebel(a)inet.net> 0.8.2-2 - Include RPM_OPT_FLAGS in distutils * Wed Apr 26 2000 Harry Henry Gebel <hgebel(a)inet.net> 0.8.2-1 - First test of bdist_rpm """ I can now run "setup.py bdist_rpm --spec-only" and get this spec file: """ %define name Distutils %define version 0.8.3pre %define release 3 Summary: Python Distribution Utilities Name: %{name} Version: %{version} Release: %{release} Source0: %{name}-%{version}.tar.gz Copyright: Python Group: Development/Libraries BuildRoot: %{_tmppath}/%{name}-buildroot Prefix: %{_prefix} BuildArchitectures: noarch Vendor: Greg Ward <gward(a)python.net> Packager: Harry Henry Gebel <hgebel(a)inet.net> Url: http://www.python.org/sigs/distutils-sig/ %description A collection of modules to aid in the distribution and installation of Python modules, extensions, and (ultimately) applications. A standard part of Python 1.6, but also distributed separately for use with Python 1.5. %prep %setup %build python setup.py build %install python setup.py install --root=$RPM_BUILD_ROOT --record=INSTALLED_FILES %clean rm -rf $RPM_BUILD_ROOT %files -f INSTALLED_FILES %defattr(-,root,root) %doc CHANGES.txt README.txt USAGE.txt doc/ examples/ %changelog * Wed May 31 2000 Greg Ward <gward(a)python.net> 0.8.3pre-1 - Hacked up bdist_rpm.py, moved meta-data into setup.cfg * Thu May 10 2000 Harry Henry Gebel <hgebel(a)inet.net> 0.8.2-3 - Added new options to package_data * Tue May 09 2000 Harry Henry Gebel <hgebel(a)inet.net> 0.8.2-2 - Include RPM_OPT_FLAGS in distutils * Wed Apr 26 2000 Harry Henry Gebel <hgebel(a)inet.net> 0.8.2-1 - First test of bdist_rpm """ Cool! Note that the formatting of the changelog is slightly mutilated by ConfigParser. ;-( I dunno how sensitive RPM is about this; guess I'll find out soon enough! Greg -- Greg Ward - Unix bigot gward(a)python.net http://starship.python.net/~gward/ I'd rather have a bottle in front of me than have to have a frontal lobotomy.

2 1

Win32+Numpy+distutils 0.8 problem
by Robin Becker June 2, 2000

June 2, 2000

For some reason I'm getting this with the latest 15.3 tgz. This is with distutils 0.8. Seems as though the search for the python include directory has again failed somewhere. C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD /W3 -I""\include\python1.5 -IInclude -I""\Include /TcSrc/_numpymodule.c /Fobuild\tem p.win32\Release\Src/_numpymodule.obj _numpymodule.c Src/_numpymodule.c(1) : fatal error C1083: Cannot open include file: 'Python.h': No such file or directory error: command '"C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe"' fail ed with exit status 2 -- Robin Becker

1 1

Suggested directory convention
by Greg Ward June 1, 2000

June 1, 2000

Lots of distribution formats need a place to put files that aren't really temporary, can often be generated by the Distutils, but may be tweaked by the developer (and put under source control). I'm thinking of RPM's spec files, Debian's directory of package meta-data, Wise scripts, and similar stuff. Seems like a good idea to me to put this all in a directory "dist": the first time you use the Distutils to generate a .spec file, or a Wise script, or what-have-you, it would create "dist" and would always put those sort of files in there. Naturally, this would be a configurable option to the bdist_* commands, but "dist" strikes me as a sensible default. This is distinct from the "build" directory for two reasons: 1) it's for distribution, not building -- hence the domain of the module developer rather than the installer/packager; 2) it's not temporary -- it's always safe to blow away the "build" directory, but could be foolish to ditch "dist". (Eg. if someone has started with Distutils-generated files and customized them to suit.) In addition to the bdist_* commands, the sdist command could possibly use the dist tree for creating source archives. (Currently, it creates <distname>-<version> (eg. "Distutils-0.8.3") in the distribution root, fill it up with copies or hardlinks to all the files in MANIFEST, and creates an archive rooted at <distname>-<version>. If we move that source distribution tree down a level, we'd have to chdir to create the source archive.) Opinions? Sound like a good idea or just more complexity? Greg -- Greg Ward - nerd gward(a)python.net http://starship.python.net/~gward/ When the ship lifts, all bills are paid. No regrets.

3 4

Pondering multi-package packages
by Mark W. Alexander June 1, 2000

June 1, 2000

I apologize of this is documented somewhere. If it is, I haven't found it. I've done lots of python modules, but not any packages, so if I'm just package ignorant feel free to slap me..... It all started in the early Zope days when I loaded Zope only to discover that all my scripts using Marc Lemburg's mxDateTime bombed because Zope's DateTime produced a namespace collision. The solution then was to move Zope, since I didn't 'need' it at the time. Now I do. So, I contacted Marc who, of course, knew about the collision and has already started looking at packaging all his stuff under an umbrella "mx" package. When I asked about Distutils, he hadn't really looked at it so I volunteered to see what it would take. Since Distutils includes a sample mxDateTime setup.py, it seemed fairly easy. I hacked it up to push it down a level (see attempt below). No problem except, of course, that it doesn't import because there's no mx.__init__.py. Ok, so I add an mx.__init__.py with __all__ defined and appropriate imports. Everything's happy and Distutils does fine. Now, I add in mx.TextTools and things get murkier. How does mx.__init__.py determine what __all__ should be and what to import? How do I tell Distutils about the other packages? I tried a single all-purpose Distutils setup.py that searches the mx package directory and adds in the sub-packages that it finds. So far so good. Now, what about mx.__init__.py? Should it: 1) Search it's package directory at runtime to determine what __all__ should be and what subpackages to import? If it does that, then mx.__init__.py will exist in all possible mx packages. Distutils probably won't care and will happily copy the lastest __init__.py into place (since they "should" all be the same, that's not a problem). BUT -- what if I make packages with --bdist-WHATEVER. Package manager WHATEVER is going to not be pleased with multiple packages that all provide mx.__init__.py. Some type of package forcing is going to have to occur for all except the first subpackage installed. - OR - 2) Be created dynamically at "install" time. The all-purpose setup.py can scan when Distutils runs and programatically create an __init__.py at installation time that meets the needs of the currently installed subpacakges. BUT -- that doesn't help when I used --bdist-WHATEVER again, because the resulting package is going to be installed on a system that probably does not have the same set of subpackages installed. I'll have to provide a postinstall script to WHATEVER to create __init__.py on the install host. Do-able, but now I'm manually tacking stuff on to the package that --bdist-WHATEVER can't (unless I missed it) handle. And, mx.__init__.py is not registered to the package somewhat defeating the purpose. It looks like --bdist-WHATEVER needs information about pre- and post-installation processing. This would have to be included in setup.py somewhere. But what should it be? Package managers (that support pre/post install) expect shell scripts. It would be really nice if --bdist took a python function and wrapped it for us in a shell wrapper, e.g. #!/bin/sh python -i <<EOF def postinstall(): ... postinstall EOF So, am I missing something or are these issues real? FWIW, I've included the directory scanning setup.py below. If you try it, it "almost" works for mxDateTime, mxTextTools, and mxNewBuiltins. There's still some issues with mx sub-modules that I'm ignorant of, but they're not related to this discussion. Mark mwa(a)gate.net ############## mx.DateTime setup.py ################ #!/usr/bin/env python import os """ setup.py for Marc-Andr� Lemburg's mx Extension modules Will scan the 'mx' directory for Marc's packages (just DateTime, TextTools, and NewBuiltins so far....) and provide the Distutils infor for all found packages. .""" # created 1999/09/19, Greg Ward # pushed to mx package by Mark Alexander __revision__ = "$Id: mxdatetime_setup.py,v 1.4 2000/03/02 01:49:46 gward Exp $" from distutils.core import setup DateTimePackages=['mx.DateTime', 'mx.DateTime.Examples', 'mx.DateTime.mxDateTime'] DateTimeExtensions=[('mx.DateTime.mxDateTime.mxDateTime', { 'sources': ['mx/DateTime/mxDateTime/mxDateTime.c'], 'include_dirs': ['mxDateTime'], 'macros': [('HAVE_STRFTIME', None), ('HAVE_STRPTIME', None), ('HAVE_TIMEGM', None)], } )] TextToolsPackages=['mx.TextTools','mx.TextTools','mx.TextTools.Constants','mx.TextTools.Examples'] TextToolsExtensions=[('mx.TextTools.mxTextTools.mxTextTools', { 'sources': ['mx/TextTools/mxTextTools/mxTextTools.c'], 'include_dirs': ['mxTextTools'], 'macros': [('HAVE_STRFTIME', None), ('HAVE_STRPTIME', None), ('HAVE_TIMEGM', None)], } )] NewBuiltinsPackages=['mx.NewBuiltins','mx.NewBuiltins.Examples','mx.NewBuiltins.mxTools'] NewBuiltinsExtensions=[('mx.NewBuiltins.mxTools.mxTools', { 'sources': ['mx/NewBuiltins/mxTools/mxTools.c'], 'include_dirs': ['NewBuiltins'], 'macros': [('HAVE_STRFTIME', None), ('HAVE_STRPTIME', None), ('HAVE_TIMEGM', None)], } ), ('mx.NewBuiltins.mxTools.xmap', { 'sources': ['mx/NewBuiltins/mxTools/xmap.c'], 'include_dirs': ['NewBuiltins'], 'macros': [('HAVE_STRFTIME', None), ('HAVE_STRPTIME', None), ('HAVE_TIMEGM', None)], } )] mxPackages=['mx'] mxExtensions=[] if os.path.isdir('mx/DateTime'): mxPackages=mxPackages+DateTimePackages mxExtensions=mxExtensions+DateTimeExtensions if os.path.isdir('mx/TextTools'): mxPackages=mxPackages+TextToolsPackages mxExtensions=mxExtensions+TextToolsExtensions if os.path.isdir('mx/NewBuiltins'): mxPackages=mxPackages+NewBuiltinsPackages mxExtensions=mxExtensions+NewBuiltinsExtensions setup (name = "mxDateTime", version = "1.3.0", description = "", author = "Marc-Andr� Lemburg", author_email = "mal(a)lemburg.com", url = "http://starship.python.net/~lemburg/mxDateTime.html", packages = mxPackages, # XXX user might have to edit the macro definitions here: yuck! # Probably do need to support 'Setup' file or something similar. ext_modules = mxExtensions, )

6 22