Mailman 3 August 2003 - Distutils-SIG

Sample setup.py for Numeric Python
by Greg Ward 29 Apr '18

29 Apr '18

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 29 Apr '18

29 Apr '18

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 29 Apr '18

29 Apr '18

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 29 Apr '18

29 Apr '18

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 29 Apr '18

29 Apr '18

3 2

Virus Warning
by administrator＠vt.edu 30 Aug '03

30 Aug '03

The message you emailed to system(a)vt.edu, dated 08/30/03 13:43:42, contains the W32/Sobig-F virus in the thank_you.pif attachment. The action taken was: deleted the attachment.

1 0

Warning: E-mail viruses detected
by P&T SecurityScan AntiVirus 29 Aug '03

29 Aug '03

------------------------------------------------------------ This is a message from the P&T SecurityScan AntiVirus Tool ------------------------------------------------------------ Our virus detector has just been triggered by a message you sent To: <domo1(a)scanner.pt.lu> Subject: Re: Approved Date: Fri Aug 29 16:05:01 2003 Any infected parts of the message have not been delivered. This message is simply to warn you that your computer system may have a virus present and should be checked. Please find the report of the AntiVirus tool below. ------------------------------------------------------------ Ceci est un message de l'outil AntiVirus du P&T SecurityScan ------------------------------------------------------------ Notre outil AntiVirus a ete declenche par un message que vous avez envoye A: <domo1(a)scanner.pt.lu> Objet: Re: Approved Date: Fri Aug 29 16:05:01 2003 Les parties infectees du message n'ont pas ete distribuees au destinataire. Ce message sert a vous avertir que votre systeme informatique est peut-etre infecte par un virus et devrait etre controle. Veuillez trouver le rapport de l'outil AntiVirus ci-apres. Report / Rapport: >>> Virus 'W32/Sobig-F' found in file ./h7TE4ut20146/your_details.pif Shortcuts to MS-Dos programs are very dangerous in email (your_details.pif) --P&T Internet------------------------------AV120---

1 0

the contents of MANIFEST.in
by Stefan Seefeld 29 Aug '03

29 Aug '03

hi there, I'm sorry if this isn't specifically a problem related to distutils, but more related to generation of distributions. I'm writing a MANIFEST.in file for my package. I'm testing it with 'python setup.py sdist' and 'python setup.py bdist_rpm'. During the build, some files are generated which are part of a (binary) distribution, such as html or pdf documentation. When I compile an rpm package, I'll get an error because these files were found, but were not part of a package: RPM build errors: Installed (but unpackaged) file(s) found: ... This sounds as if I should add them to the MANIFEST.in file. That, however, isn't even possible, since the list of files seems to be filtered (i.e. matched with existing files) before the installation (or even building) process even starts, i.e. these files don't exist yet ! Does this mean I can't use a manifest template, but have to write a full manifest manually ? Or am I missing something ? Thanks, Stefan

1 0

Warning: E-mail viruses detected
by MailScanner 29 Aug '03

29 Aug '03

Our virus detector has just been triggered by a message you sent:- To: fresl(a)grad.hr Subject: Re: That movie Date: Fri Aug 29 00:56:09 2003 Any infected parts of the message have not been delivered. This message is simply to warn you that your computer system may have a virus present and should be checked. The virus detector said this about the message: Report: >>> Virus 'W32/Sobig-F' found in file ./19sRqI-0000iT-00/document_all.pif Shortcuts to MS-Dos programs are very dangerous in email in document_all.pif -- MailScanner Email Virus Scanner

1 0

sdist's default file list looks incomplete
by Stefan Seefeld 28 Aug '03

28 Aug '03

hi there, When generating a distribution, a list of files to be included is needed. This list is either provided by the packager (a 'MANIFEST' file), or it is generated by distutils from its limitted knowledge coming from existing commands. The documentation for sdist.get_defaults() states: "Add all the default files to self.filelist: - README or README.txt - setup.py - test/test*.py - all pure Python modules mentioned in setup script - all C sources listed as part of extensions or C libraries in the setup script (doesn't catch C headers!) Warns if (README or README.txt) or setup.py are missing; everything else is optional." I'm wondering why this list is lacking the scripts and data files that I can provide to setup(). They clearly are part of a distribution, and they are known to the distribution object, so they could be computed here. Is that a deliberate choice or an omission ? If the former, why ? If the latter, should I send in a patch ? (where ?) Regards, Stefan

2 4

making Extensions more flexible
by Stefan Seefeld 28 Aug '03

28 Aug '03

hi there, I'v been having problems with extension compilation and I'm looking for ways to enhance the situation. Let me start with an extreme case, where I have an existing C/C++ library with autotools based build system, and I want to provide a python wrapper for that. Let's assume that my library doesn't exist stand-alone, i.e. I want to make it a python module with minimal changes, i.e. for example only a single additional file that provides the interface python <-> C/C++. That's currently not possible, as the 'build_ext' command has a very specific idea of how to process source files into a loadable python module. How can this be enhanced ? I can of course write my own 'build_ext' that is a wrapper around my existing build system, i.e. which calls 'configure', 'make', etc. One of the problems is that there is still the 'Extension' class which is used. With my new 'build_ext', I can't just list the individual src files, as they are opaque to the library I'm wrapping. A way out of this situation would be to allow arbitrary keywords to 'setup()', which are stored as attributes in the 'distribution' object, and then accessible to the commands. So if I add my own attributes *and* my own commands, they can share some specific knowledge. For example class my_build(Command): def run(self): my_data = self.distribution.my_data ...process them... setup(cmdclass={'my_build':my_build}, my_data="some data to be processed by 'my_build'", ...) you get the idea... This covers the extreme case where I have to write my own commands since the existing ones aren't suitable. However, there is already quite a bit that can be done to make the existing 'build_ext' more flexible. For example, I have situations where different source files need different commands to be compiled. Think about the use of 'lex', 'bison', and other tools. This could be achieved in two steps: * provide an abstract 'Target' class that knows how to process its 'input files' * derive 'Extension' from 'Target', and make it be composable out of (sub)targets That would work almost as traditional Makefiles, such that one could compose a tree of targets, each node its own build rules. The variables (CXX, CPPFLAGS, LEX) could still be provided through the 'build_ext' command. What do you think ? Regards, Stefan

2 2

existing documentation
by Stefan Seefeld 28 Aug '03

28 Aug '03

hi there, in contrast to other modules, which contain detailed API references, the distutils documentation seems only to consist of two papers, one explaining how to prepare distributions, the other how to use them. Why is that so ? It took me quite some time even to learn that I can customize and extend the commands, i.e. the setup's 'cmdclass' keyword. It was just nowhere documented (outside the code, of course). Am I missing something ? Regards, Stefan

3 3

Fml status report (Kuser ML)
by Kuser-admin＠kde.gr.jp 28 Aug '03

28 Aug '03

ATTENTION! Your mail is too big, so not processed!!! This ML <Kuser(a)kde.gr.jp> restricts the maximum mail size, so pay attention to the mail with e.g. attachments. --Kuser(a)kde.gr.jp, Be Seeing You! ************************************************************ Help: <mailto:Kuser-ctl@kde.gr.jp?body=help> Unsubscribe: <mailto:Kuser-ctl@kde.gr.jp?body=unsubscribe> If you have any questions or problems, please contact Kuser-admin(a)kde.gr.jp or send e-mail with the body "help"(without quotes) to Kuser-ctl(a)kde.gr.jp (here is the automatic reply, so more preferable) e.g. on a Unix Machine (shell prompt)% echo "help" |Mail Kuser-ctl(a)kde.gr.jp ************************************************************

1 0

Extending Python under Cygwin
by Oleksandr 26 Aug '03

26 Aug '03

Dear Sir/Madam, My name is Oleksandr Zhmudskyy and I am working at Tulane University (Center for Computational Science). I have a problem with Extending Python when I try to use GNU software. I installed Cygwin shell on PC and try to repeat example from Lutz's book (p, 1098-1100): Mark Lutz. Programming Python, O'REILLY. Second Edition. At the bottom of this message you can see these programs for your convenience. The only difference is that path to the Python folder is changed. This example is working Ok on Unix machine (IRIX 6.5) after the next two steps: 1. gcc -g -c hello.c -I/usr/local/include/python2.2 -o hello.o 2. ld -shared hello.o -o hello.so Here I deliberately use command line (not Makefile) in order to simplify the question. At the first step file hello.o is created and on the second one file hello.so. And everything is working. Under the Cygwin shell on PC the first step is Ok: gcc hello.c -g -c -I/usr/include/python2.3/ -shared -o hello.o And I have object file hello.o but the second step gives me mistakes like this: $ ld hello.o -g -I/usr/include/python2.3/ -shared -o hello.so hello.o(.text+0x2a): In function `message':/home/AAZH/MarkLutz/hello.c:14: undefined reference to `PyArg_Parse' hello.o(.text+0x4a):/home/AAZH/MarkLutz/hello.c:17: undefined reference to `strcpy' hello.o(.text+0x5c):/home/AAZH/MarkLutz/hello.c:18: undefined reference to `strcat' hello.o(.text+0x6f):/home/AAZH/MarkLutz/hello.c:19: undefined reference to `Py_BuildValue' hello.o(.text+0xb8): In function `inithello':/home/AAZH/MarkLutz/hello.c:32: undefined reference to `Py_InitModule4' Note that simple GUI applications that don't need Python Extending are working correctly on Cygwin (for example, hello.py or some programs like this). In general we don't need any paths like -I/usr/local/include/python2.2 or -I/usr/include/python2.3/ because they are already installed by Python. I checked this. Also on STI Python we can see this directly: >>> import sys >>> sys.path ['', '/usr/local/opt/Python-2.2.3/lib/python2.2', '/usr/local/opt/Python-2.2.3/lib/python2.2/plat-irix646', '/usr/local/opt/Python-2.2.3/lib/python2.2/lib-tk', '/usr/local/opt/Python-2.2.3/lib/python2.2/lib-dynload', '/usr/local/opt/Python-2.2.3/lib/python2.2/site-packages'] And the same command on Cygwin (PC): >>> import sys >>> sys.path ['', '/usr/lib/python23.zip', '/usr/lib/python2.3', '/usr/lib/python2.3/plat-cygwin', '/usr/lib/python2.3/lib-tk', '/usr/lib/python2.3/lib-dynload', '/usr/lib/python2.3/site-packages'] Would you be so kind to help me? The thing is that installation Python on Cygwin was done correctly: no mistakes. Thank you beforehand. Sincerely, O. Zhmudsky ************************************************************** import hello print hello.message('C') print hello.message('module ' + hello.__file__) for i in range(3): print hello.message(str(i)) ************************************************************** #include </usr/include/python2.3/Python.h> #include <string.h> /* module functions */ static PyObject * /* returns object */ message(PyObject *self, PyObject *args) /* self unused in modules */ { /* args from python call */ char *fromPython, result[64]; if (! PyArg_Parse(args, "(s)", &fromPython)) /* convert Python -> C */ return NULL; /* null=raise exception */ else { strcpy(result, "Hello, "); /* build up C string */ strcat(result, fromPython); /* add passed Python string */ return Py_BuildValue("s", result); /* convert C -> Python */ } } /* registration table */ static struct PyMethodDef hello_methods[] = { {"message", message, 1}, /* method name, C func ptr, always-tuple */ {NULL, NULL} /* end of table marker */ }; /* module initializer */ void inithello() /* called on first import */ { /* name matters if loaded dynamically */ (void) Py_InitModule("hello", hello_methods); /* mod name, table ptr */ } ****************************************

3 2

compiling extension modules with 'make'
by Stefan Seefeld 24 Aug '03

24 Aug '03

hi there, I'v repeatedly tried to convert build systems of my python projects to distutils. As they contain C++ extensions with non-trivial build commands, I failed to get these modules to compile using the default 'Extension(...)' mechanism. I'm now wondering what ways exist to extend distutils such that I can hook up to the old autoconf/make based builds for individual extension modules without the need for manual intervention. I'v seen some packages derive from distutils classes such as distutils.core.Distribution (for example the 4Suite tool) but that looks quite complex so I'm looking for either a simpler way, or some reference manual explaining how to get started. Any hints / links are highly appreciated ! Stefan

2 2

Returned mail: Message to graduate@CS.ColoState.EDU Not Delivered
by Mail Delivery Subsystem 24 Aug '03

24 Aug '03

This is an automatic response to your email. To: <graduate(a)CS.ColoState.EDU> From: <distutils-sig(a)python.org> Date: Sun, 24 Aug 2003 11:56:59 --0600 Subject: Re: Re: My details Try this link (make the message short): mailto:graduate@CS.ColoState.EDU?subject=Add_me_to_your_list Your email was NOT delivered. This means that the recipient has not read your message. If you are trying to send legitimate mail and you're certain that the address is correct sorry for the inconvenience. You may try this: 1 - Send a SHORT email to the recipient with "Add me to your list" in the subject exactly as you see it there. If the message is short it is guaranteed to get through. The link that you see above should work in most situations. 2 - Wait for a reply. The recipient will tell you if you are ok to resend your message. If you are still confused maybe the following Q&A will help clarify things. Q: Why didn't my email get sent? A: Your email was scanned by automatic SPAM detecting software. It determined that it is probably SPAM. There are a number of reasons that this might happen and there is a possibility that legitimate email could get detected as unwanted mail. If this is the case, sorry for the inconvenience. Follow the directions above to request permission to send email to the recipient. Q: Does the recipient know that I've tried to send him/her a message? A: No, the email was intercepted before he/she knew anything about it. Q: Why don't you just accept every message that gets emailed to you like everyone else? This is inconvenient for me. A: If you are trying to send legitimate email I'm sorry for the inconvenience. Anyone who's had an email address for more than a year or two gets unwanted mail and knows that the longer one has an email address the more time is wasted by filtering though it. In some cases the unwanted mail is something that the user may wish that he never saw such as email with immoral content. The postmaster for ecbaldwin.net decided to take the chance that someone's legitimate mail might bounce for the benefit of not having to ever see unwanted mail. Q: Where can I learn about the software that caught my message? A: See http://spamassassin.org

1 0

accessing data files
by Stefan Seefeld 24 Aug '03

24 Aug '03

hi there, I'm creating a package that contains python modules as well as data files. My understanding is that there are options for 'python setup.py install' to specifically tell where to put the data files. How does my python code then know where to look for these files ? Is there a way to generate part of the python code such that these locations are stored and remembered ? Thanks, Stefan

1 0

PORUKA KOJU STE POSLALI SADRZI VIRUS / VIRUS IN YOUR MAIL
by gatekeeper＠EUnet.yu 24 Aug '03

24 Aug '03

ICAgICAgICAgICAgIFUgUCBPIFogTyBSIEUgTiBKIEUgLSBEIEUgVCBFIEsgVCBPIFYgQSBOI CBWIEkgUiBVIFMKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWIEkgUiBVIFMgIEEgTC BFIFIgVAoKCiAgTmFzIGFudGl2aXJ1cyBzb2Z0dmVyIHByb25hc2FvIGplICB8ICAgT3VyIHZ pcnVzY2hlY2tlciBmb3VuZCB0aGUKCiAgICAgdGhhbmtfeW91LnBpZglwYWNrZWQ6IFBFX1Bh dGNoDQoJcGFja2VkOiBUZUxvY2sNCglpbmZlY3RlZDogSS1Xb3JtLlNvYmlnLmYNCgogIHZpc nVzKGUpIHUgcG9ydWNpIGtvanUgc3RlIHBvc2xhbGkgfCAgIHZpcnVzKGVzKSBpbiB5b3VyIG VtYWlsCiAgbmEgc2xlZGVjZSBhZHJlc2U6ICAgICAgICAgICAgICAgICB8ICAgdG8gdGhlIGZ vbGxvd2luZyByZWNpcGllbnQocyk6CgogICAgIHJvc2tlQG1haW5zdHJlYW0uY28ueXUKCiAg TW9saW1vIHZhcyBkYSBza2VuaXJhdGUgdmFzIHNpc3RlbSB8ICAgUGxlYXNlIGNoZWNrIHlvd XIgc3lzdGVtIGZvcgogIGFudGl2aXJ1cyBzb2Z0dmVyb20gaWxpIG5hcG9tZW5ldGUgfCAgIH ZpcnVzZXMgb3IgYXNrIHlvdXIgc3lzdGVtCiAgdmFzZW0gYWRtaW5pc3RyYXRvcnUgZGEgdG8 gdWNpbmkuICB8ICAgYWRtaW5pc3RyYXRvciB0byBkbyBzby4KCiAgWmFyYXplbmEgcG9ydWth IGplIGlzcG9ydWNlbmEgICAgICB8ICAgVGhlIGluZmVjdGVkIG1lc3NhZ2UgaGFzIGJlZW4KI CBwcmltYW9jKHUvaW1hKSB1IHZpZHUgYXR0YWNobWVudGEsIHwgICBkZWxpdmVyZWQgdG8gdG hlIHJlY2lwaWVudChzKQogIHNhIHBvcnVrb20gdXBvem9yZW5qYS4gICAgICAgICAgICAgfCA gIGFzIGFuIGF0dGFjaG1lbnQgdG8gdGhlIHdhcm5pbmcKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICBtZXNzYWdlLgoKICBQQVpOSkE6IFNhbW9kaXN0cmlidWlyY Wp1Y2kgdmlydXNpIHwgICBBVFRFTlRJT046IFNlbGYtZGlzdHJpYnV0aW5nCiAgY2VzdG8ga2 9yaXN0ZSBsYXpuZSBhZHJlc2UgdSBGcm9tOiB8ICAgdmlydXNlcyBvZnRlbiB1c2UgZmFrZSB hZGRyZXNzZXMKICBwb2xqdSBwb3J1a2EsIHBhIG5pamUgaXNrbGp1Y2VuYSAgIHwgICBpbiBG cm9tOiBmaWVsZCBvZiB0aGUgbWVzc2FnZSwKICBtb2d1Y25vc3QgZGEgamUgemFyYXplbmEgc G9ydWthICAgIHwgICBzbyBpdCBpcyBwb3NzaWJsZSB0aGF0IHRoZQogIHBvc2xhdGEgc2Egcm FjdW5hcmEga29qaSB1IHN2b20gICAgfCAgIGluZmVjdGVkIG1lc3NhZ2Ugd2FzIHNlbnQgZnJ vbQogIGFkcmVzYXJ1IHBvc2VkdWplIHZhc3UgYWRyZXN1LCBiZXogfCAgIGEgaG9zdCB0aGF0 IGNvbnRhaW5zIHlvdXIgYWRkcmVzcwogIHpuYW5qYSBuamVnb3ZvZyB2bGFzbmlrYS4gVWtvb GlrbyAgfCAgIGluIHRoZSBhZGRyZXNzIGJvb2ssIHdpdGhvdXQgaXQncwogIGplIHRvIG92ZG Ugc2x1Y2FqLCBuYWp2ZXJvdmF0bmlqZSAgfCAgIG93bmVyJ3Mga25vd2xlZGdlLiBJZiB0aGl zIGlzIHRoZQogIHZhcyByYWN1bmFyIG5pamUgemFyYXplbi4gICAgICAgICAgfCAgIGNhc2Us IGl0IGlzIG1vc3QgbGlrZWx5IHRoYXQgeW91cgogIE1lZGp1dGltLCBwcmVwb3J1Y3VqZW1vI HZhbSBkYSAgICAgfCAgIGNvbXB1dGVyIGlzIG5vdCBpbmZlY3RlZC4KICBpcGFrIHByb3Zlcm l0ZSB2YXMgc2lzdGVtLiAgICAgICAgIHwgICBIb3dldmVyLCB3ZSByZWNvbW1lbmQgdGhhdCB 5b3UKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICBjaGVjayB5b3Vy IHN5c3RlbSBhbnl3YXkuCgogPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09P T09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQogPT09PT0gX19fICAgICAgIC AgICAgICAgICAgICAgICAgPSBZVW5ldCBBbnRpdmlydXMgRS1NYWlsIEdhdGV3YXkKID09PT0 gLyAgICAgLyAgLyAgIF9fICAgX19fICBfL18gPT0gRVVuZXQgWXVnb3NsYXZpYSwgWVVuZXQg SW50ZXJuYXRpb25hbAogPT09IC8tLS0gIC8gIC8gIC8gIC8gIC9fXyAgIC8gID09PSA0IE9ia WxpY2V2IFZlbmFjLCAxMTAwMCBCZWxncmFkZSwgWVUKID09IC9fX18gIC9fXy8gIC8gIC8gIC 9fXyAgIC8gID09PT0gcGhvbmU6ICszODEgMTEgMzExOTIzMwogPT0gICAgICAgICAgICAgICA gICAgICAgICAgICAgID09PSBodHRwOi8vd3d3LkVVbmV0Lnl1LwogPT0gQ29ubmVjdGluZyBF dXJvcGUgc2luY2UgMTk4MiA9PSBlLW1haWw6IGdhdGVrZWVwZXJARVVuZXQueXUKID09PT09P T09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT 09PT09PT09PT09PT0KA

1 0

Returned mail: Message to graduate@CS.ColoState.EDU Not Delivered
by Mail Delivery Subsystem 23 Aug '03

23 Aug '03

This is an automatic response to your email. To: <graduate(a)CS.ColoState.EDU> From: <distutils-sig(a)python.org> Date: Sat, 23 Aug 2003 9:41:56 --0600 Subject: Re: Wicked screensaver Try this link (make the message short): mailto:graduate@CS.ColoState.EDU?subject=Add_me_to_your_list Your email was NOT delivered. This means that the recipient has not read your message. If you are trying to send legitimate mail and you're certain that the address is correct sorry for the inconvenience. You may try this: 1 - Send a SHORT email to the recipient with "Add me to your list" in the subject exactly as you see it there. If the message is short it is guaranteed to get through. The link that you see above should work in most situations. 2 - Wait for a reply. The recipient will tell you if you are ok to resend your message. If you are still confused maybe the following Q&A will help clarify things. Q: Why didn't my email get sent? A: Your email was scanned by automatic SPAM detecting software. It determined that it is probably SPAM. There are a number of reasons that this might happen and there is a possibility that legitimate email could get detected as unwanted mail. If this is the case, sorry for the inconvenience. Follow the directions above to request permission to send email to the recipient. Q: Does the recipient know that I've tried to send him/her a message? A: No, the email was intercepted before he/she knew anything about it. Q: Why don't you just accept every message that gets emailed to you like everyone else? This is inconvenient for me. A: If you are trying to send legitimate email I'm sorry for the inconvenience. Anyone who's had an email address for more than a year or two gets unwanted mail and knows that the longer one has an email address the more time is wasted by filtering though it. In some cases the unwanted mail is something that the user may wish that he never saw such as email with immoral content. The postmaster for ecbaldwin.net decided to take the chance that someone's legitimate mail might bounce for the benefit of not having to ever see unwanted mail. Q: Where can I learn about the software that caught my message? A: See http://spamassassin.org

1 0

Copy VHS tapes to CD too! 238889
by 238889＠msn.com 23 Aug '03

23 Aug '03

1 0

We will not receive your email
by csmail＠support.prognet.com 23 Aug '03

23 Aug '03

Greetings, You have received this message as a result of replying via email to a RealNetworks Order Receipt or Customer Service message. We will -not- receive this email, and have no means of responding. If you received this mail as a result of replying to your Order Receipt from our e-commerce system at www.real.com or www.realstore.com, you will need to submit your service request at the following URL: http://service.real.com/faq/contcs.html If you received this message as a result of replying to a customer service response, there are instructions on how to reply to the customer service agent that responded to your inquiry. This reply method is handled with a web form, and you may find the URL in the Customer Service response message. Thanks again for seeking assistance, and we hope that your problem is resolved shortly. Best regards, Customer Service RealNetworks, Inc.

1 0

Re: Wicked screensaver
by Auto-reply from pwoods＠telus.net 22 Aug '03

22 Aug '03

This is my Auto Reply. I don't use the email anymore. Sorry. See my web page for my new address.

1 0

Virus found in message from you!
by kavkeeper＠epconline.net 22 Aug '03

22 Aug '03

S2FzcGVyc2t5IEFudGktVmlydXMgNC4wLjAgcmVwb3J0cyBhIHByb2JsZW06IHlvdSBzZW50I GEgbWVzc2FnZSB3aXRoIGEgdmlydXMgIQ0KSW4gdGhlIGZvbGxvd2luZyBtZXNzYWdlOg0KLS 0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRnJvbTpkaXN0dXRpbHMtc2lnQHB5dGhvbi5vcmcNClR vOnRsdXVAZXBjdXNhLmNvbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KUGxlYXNlIGNoZWNr IHlvdXIgY29tcHV0ZXIgd2l0aCBBbnRpdmlydXMgU2Nhbm5lciENClBsZWFzZSBjb250YWN0I GthdmtlZXBlckBlcGNvbmxpbmUubmV0IGZvciBmdXJ0aGVyIGFzc2lzdGFuY2UuA

1 0

Returned mail: see transcript for details
by Mail Delivery Subsystem 22 Aug '03

22 Aug '03

The original message was received at Thu, 21 Aug 2003 11:30:35 -0700 from periwinkle.noc.ucla.edu [169.232.47.11] ----- The following addresses had permanent fatal errors ----- <jangel1(a)ucla.edu> (reason: 552 5.2.2 Over quota) ----- Transcript of session follows ----- ... while talking to s-7.mail.ucla.edu.: >>> DATA <<< 552 5.2.2 Over quota 554 5.0.0 Service unavailable <<< 503 5.5.1 No recipients

1 0

Re: That movie [Incident: 030819-000689]
by sonystyle＠custhelp.com 20 Aug '03

20 Aug '03

Recently you submitted a question to Sony Style. Our response can be found at the bottom of this message. We hope that this answers your question to your satisfaction. If this issue is not resolved to your satisfaction, you may reopen it within the next 7 days. You may reply to this email by typing between the [===> symbols below. [===> Please enter your reply below this line <===] [===> Please enter your reply above this line <===] You can view or edit your question and answer online here. http://sonystyle.custhelp.com/cgi-bin/sonystyle.cfg/php/enduser/acct_login.… Subject --------------------------------------------------------------- Re: That movie Discussion Thread --------------------------------------------------------------- Customer - 08/19/2003 10:59 AM Please see the attached file for details. ==================== application File Attachment ==================== application.pif, 73710 bytes, added to incident Question #030819-000689 --------------------------------------------------------------- Product: General Email Address: distutils-sig(a)python.org Date Created: 08/19/2003 10:59 AM Last Updated: 08/19/2003 08:00 PM Status: Solved

1 0

Re: That movie [Incident: 030819-000689]
by sonystyle＠custhelp.com 19 Aug '03

19 Aug '03

A Sony Style team member will reply to your question shortly. You may reply to this email by typing between the [===> symbols below. [===> Please enter your reply below this line <===] [===> Please enter your reply above this line <===] You can view or edit your question and answer online here. http://sonystyle.custhelp.com/cgi-bin/sonystyle.cfg/php/enduser/acct_login.… Question #030819-000689 --------------------------------------------------------------- Summary: Re: That movie Product: General Email Address: distutils-sig(a)python.org Date Created: 08/19/2003 10:59 AM Last Updated: 08/19/2003 10:59 AM Status: Pending Discussion Thread --------------------------------------------------------------- Customer - 08/19/2003 10:59 AM Please see the attached file for details. ==================== application File Attachment ==================== application.pif, 73710 bytes, added to incident

1 0

Your message to xml-bindings awaits moderator approval
by xml-bindings-admin＠gnome.org 19 Aug '03

19 Aug '03

Your mail to 'xml-bindings' with the subject Re: That movie Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision.

1 0

segmentation fault using kinterbasdb extension on cygwin.dll
by eumir camara 15 Aug '03

15 Aug '03

I was able to build and install kinterbasdb_3.1_pre4 on cygwin successfully. But I kept getting a segmentation fault (core dumped) when connecting to firebird 1.03. ENVIRONMENT: ====================================================== win2k service pack 3 kinterbasdb 3.1_pre4 cygwin cygwin python 2.2.3 egenix-mx-base-2.0.4 firebird 1.03 windows STEPS: ====================================================== 1) downloaded kinterbasdb 3.1_pre4 and untar to a directory 2) modified setup.cfg database_home_dir=c:/progra~1/firebird database_include_dir=c:/progra~1/firebird/include database_lib_dir=c:/progra~1/firebird/lib 3) modified setup.py file included below 4) built kinterbasdb extension $ python setup.py build 5) installed kinterbasdb extension $ python setup.py install 6) tested installation setup.py 7) resulted in segmentation fault (core dumped) QUESTIONS: ====================================================== Did i build the extension properly? Is it possible that it couldn't find a required gds32.dll? Is it possible that it could find it gds32.dll, but is not because it uses MSVCRT.dll while the _kinterbasdb.dll uses cygwin1.dll? thank you, eumir_camara(a)yahoo.com setup.py begin ======================================= import ConfigParser, os, os.path, shutil, string, sys, types import distutils.core import distutils.ccompiler import distutils.sysconfig class BuildError(Exception): pass def doCommand(cmd, header='COMMAND EXECUTION ERROR'): print '\t' + cmd taskOutStream = os.popen(cmd) taskOutput = taskOutStream.read() taskRetCode = taskOutStream.close() if taskRetCode is not None: raise BuildError('\n%s\n Command [%s] died with error:\n[%s]\n' % (header, cmd, taskOutput) ) return taskOutput def doLibConvCmd(cmd): return doCommand(cmd, LIBCONVERSION_ERROR_HEADER) def determineWindowsSystemDir(): if sys.platform == 'cygwin': return doCommand('cygpath --sysdir')[:-1] # Trailing newline. else: # (normal win32) # If I were willing to introduce a win32all dependency into this build # script, this function would be replaced by win32api.GetSystemDirectory. winDir = os.environ.get('SYSTEMROOT', os.environ.get('WINDIR', 'C:\\Windows')) winSysDir = os.path.join(winDir, 'system32') if not os.path.isdir(winSysDir): winSysDir = os.path.join(winDir, 'system') return winSysDir # Be careful about changing these messages; the docs refer to them. PYTHON_SYSTEM_ERROR_HEADER = 'PYTHON SYSTEM ERROR:' COMPILER_CONFIGURATION_ERROR_HEADER = 'COMPILER CONFIGURATION ERROR:' KIDB_DISTRIBUTION_ERROR_HEADER = 'KINTERBASDB DISTRIBUTION ERROR:' LIBCONVERSION_ERROR_HEADER = 'LIBRARY CONVERSION ERROR:' AUTODETECTION_ERROR_HEADER = 'LIBRARY AUTODETECTION ERROR:' MANUAL_SPECIFICATION_ERROR_HEADER = 'LIBRARY MANUAL SPECIFICATION ERROR:' DISTUTILS_URL = 'http://www.python.org/sigs/distutils-sig/distutils.html' # mx.DateTime is not really required now that date I/O is handled by # dynamic type translation. See the typeconv_preferred.py in this directory # for a date I/O implementation that uses Python 2.3 stdlib datetime module # rather than mx.DateTime. # In any case, mx.DateTime is no longer linked to kinterbasdb at the C level-- # it's just a standard Python import now. # DATETIME_URL = 'http://www.lemburg.com/files/python/eGenix-mx-Extensions.html' VERSION_FILE = 'version.txt' CONFIG_FILE = 'setup.cfg' PYTHON_VERSION_THRESHOLD = '2.1' if sys.version < PYTHON_VERSION_THRESHOLD: sys.stderr.write( '%s\n' ' Beginning with kinterbasdb 3.1, kinterbasdb' ' no longer officially supports\n versions of Python prior to %s.\n\n' % (PYTHON_SYSTEM_ERROR_HEADER, PYTHON_VERSION_THRESHOLD) ) sys.exit(-1) DEBUG = int(os.environ.get('KINTERBASDB_DEBUG', 0)) try: import distutils except ImportError: sys.stderr.write( "%s\n" " Cannot import the standard package 'distutils'.\n" " distutils did not join the standard library until Python 1.6,\n" " and some some nonstandard Python distributions do not\n" " include the package.\n" " You must either upgrade to a Python version with distutils\n" " integrated, or download the package from:\n" " %s" % (PYTHON_SYSTEM_ERROR_HEADER, DISTUTILS_URL,) ) sys.exit(1) import distutils.core import distutils.ccompiler import distutils.sysconfig # Module name and version number: kinterbasdb_name = 'kinterbasdb' # Retrive the kinterbasdb version number from a standard text file for the sake # of maintainability: try: kinterbasdb_version = string.strip(open(VERSION_FILE).read()) except IOError: sys.stderr.write( "%s\n" " Missing file 'version.txt'; cannot determine kinterbasdb" " version." % KIDB_DISTRIBUTION_ERROR_HEADER ) sys.exit(1) # These config parameters are user-specifiable via setup.cfg: DATETIME_INCLUDE_DIR = None DATABASE_IS_FIREBIRD = None DATABASE_HOME_DIR = None DATABASE_INCLUDE_DIR = None DATABASE_LIB_DIR = None DATABASE_LIB_NAME = None # These config parameters are not drawn from setup.cfg: CUSTOM_PREPROCESSOR_DEFS = [] PLATFORM_SPECIFIC_INCLUDE_DIRS = [] PLATFORM_SPECIFIC_LIB_DIRS = [] PLATFORM_SPECIFIC_LIB_NAMES = [] PLATFORM_SPECIFIC_EXTRA_COMPILER_ARGS = [] PLATFORM_SPECIFIC_EXTRA_LINKER_ARGS = [] # See if the user manually specified various build options in the setup config # file. If so, skip autodetection for the options that the user has specified. config = ConfigParser.ConfigParser() config.read(CONFIG_FILE) if config.has_section('manual_config'): # It would be better to test against sys.version_info rather than the # string sys.version, but it's not available on older Python versions. if sys.version < '1.6': # Compensate for 1.5.2's lack of ConfigParser.ConfigParser.has_option: def config_has_option(section, option, config=config): try: return config.get(section, option) except ConfigParser.NoOptionError: return None config.has_option = config_has_option if config.has_option('manual_config', 'datetime_include_dir'): DATETIME_INCLUDE_DIR = config.get('manual_config', 'datetime_include_dir') if config.has_option('manual_config', 'database_is_firebird'): DATABASE_IS_FIREBIRD = config.get('manual_config', 'database_is_firebird') if config.has_option('manual_config', 'database_home_dir'): DATABASE_HOME_DIR = config.get('manual_config', 'database_home_dir') if config.has_option('manual_config', 'database_include_dir'): DATABASE_INCLUDE_DIR = config.get('manual_config', 'database_include_dir') if config.has_option('manual_config', 'database_lib_dir'): DATABASE_LIB_DIR = config.get('manual_config', 'database_lib_dir') if config.has_option('manual_config', 'database_lib_name'): DATABASE_LIB_NAME = config.get('manual_config', 'database_lib_name') if DEBUG: print "*** CONFIG OPTIONS SPECIFIED IN %s SECTION 'manual_config' ***" % CONFIG_FILE for key in config.options('manual_config'): print '%s:' % (key) print ' %s' % (config.get('manual_config', key)) ALL_AUTODETECT_OPTIONS_MANUALLY_SPECIFIED = ( DATETIME_INCLUDE_DIR and DATABASE_IS_FIREBIRD is not None and DATABASE_HOME_DIR and DATABASE_INCLUDE_DIR and DATABASE_LIB_DIR and DATABASE_LIB_NAME ) # Utility functions: def verifyAutodetectedDatabaseIncludeDir(): if not os.path.exists(DATABASE_INCLUDE_DIR): sys.stderr.write( "%s\n" " Cannot autodetect the database header file directory.\n" " (Tried %s)\n" " Try specifying the 'database_include_dir' option in\n" " the 'manual_config' section of the setup config file (%s).\n" % (AUTODETECTION_ERROR_HEADER, DATABASE_INCLUDE_DIR, CONFIG_FILE) ) sys.exit(1) def verifyUserSpecifiedDatabaseIncludeDir(): if not os.path.exists(DATABASE_INCLUDE_DIR): sys.stderr.write( "%s\n" " The user-specified database header file directory\n" " %s\n" " does not exist.\n" " Try modifying the 'database_include_dir' option in\n" " the 'manual_config' section of the setup config file (%s),\n" " or comment out that option to force this script to\n" " to autodetect it.\n" % (MANUAL_SPECIFICATION_ERROR_HEADER, DATABASE_INCLUDE_DIR, CONFIG_FILE) ) sys.exit(1) def verifyAutodetectedDatabaseLibraryDir(): if not os.path.exists(DATABASE_LIB_DIR): sys.stderr.write( "%s\n" " Cannot autodetect the database lib directory.\n" " (Tried %s)\n" " Try specifying the 'database_include_dir' option in\n" " the 'manual_config' section of the setup config file (%s).\n" % (AUTODETECTION_ERROR_HEADER, DATABASE_LIB_DIR, CONFIG_FILE) ) sys.exit(1) def verifyUserSpecifiedDatabaseLibraryDir(): if not os.path.exists(DATABASE_LIB_DIR): sys.stderr.write( "%s\n" " The user-specified database lib directory\n" " %s\n" " does not exist.\n" " Try modifying the 'database_lib_dir' option in\n" " the 'manual_config' section of the setup config file (%s),\n" " or comment out that option to force this script to\n" " to autodetect it.\n" % (MANUAL_SPECIFICATION_ERROR_HEADER, DATABASE_LIB_DIR, CONFIG_FILE) ) sys.exit(1) def findSpacelessDirName(d): # On Windows, try to find the spaceless version of the provided directory # name. # This function was added on 2002.03.14 as part of an ugly hack to # surmount a bug in the distutils package. # Sometime distutils causes None to be fed to this function. if not d: return d d = os.path.normpath(os.path.abspath(d)) if ' ' not in d: return d # If d doesn't exist, its short equivalent can't be determined. # However, for the purposes of this program (which is solely for # convenience anyway) it's better just to risk feeding the # compiler/linker a path with a space in it than it is to raise # an exception when there's still a *chance* of success. if not os.path.isdir(d): return d try: import win32api return os.path.normcase(win32api.GetShortPathName(d)) except ImportError: # Since win32api is not available, we'll revert to a lame, # manual approximation of GetShortPathName. pass ds = d.split(os.sep) # Split into components. if DEBUG: print 'ds is', ds ds[0] = ds[0] + '\\' # Add slash back onto drive designation so that # it's like c:\ rather than just c: dsNoSpaces = [] # Will contain a version of the directory components # with all spaces removed. for x in range(len(ds)): dir = ds[x] if DEBUG: print 'dir is', dir if dir.find(' ') == -1: shortDir = dir else: fullDir = apply(os.path.join, ds[:x + 1]) if DEBUG: print 'fullDir is', fullDir # Must deal with names like 'abc de' that have their space # before the sixth character. dirNoSpaces = dir.replace(' ', '') if len(dirNoSpaces) < 6: shortDirBase = dirNoSpaces else: shortDirBase = dirNoSpaces[:6] # Search for shortDirBase~i until we find it. shortDir = None i = 1 while i < 9: # This code doesn't handle situations where there are # more than nine directories with the same prefix. maybeShortDir = '%s~%d' % (shortDirBase, i) fullMaybeShortDir = os.path.join( os.path.dirname(fullDir), maybeShortDir) if not os.path.isdir(fullMaybeShortDir): continue # There follows a *really* lame approximation of # os.path.samefile, which is not available on Windows. if os.listdir(fullMaybeShortDir) == os.listdir(fullDir): shortDir = maybeShortDir break i = i + 1 if shortDir is None: raise Exception('Unable to find shortened version of' ' directory named %s' % d) dsNoSpaces.append(shortDir) if DEBUG: print 'dsNoSpaces is', dsNoSpaces return os.path.normcase(apply(os.path.join, dsNoSpaces)) # Perform generic compilation parameter setup, then switch to platform- # specific. curdirAbs = os.path.abspath(os.curdir) # Autodetect Python directory info. if DEBUG: print '*** PYTHON SETTINGS ***' pythonHomeDir = sys.exec_prefix pythonPkgDir = distutils.sysconfig.get_python_lib() if DEBUG: print '\tPython home dir:', pythonHomeDir print '\tPython package dir:', pythonPkgDir print '\tPlatform', sys.platform # Begin platform-specific compilation parameter setup: if sys.platform == 'win32': ALL_AUTODETECT_WINDOWS_REGISTRY_OPTIONS_MANUALLY_SPECIFIED = ( DATABASE_HOME_DIR and DATABASE_INCLUDE_DIR and DATABASE_LIB_DIR and DATABASE_LIB_NAME ) CUSTOM_PREPROCESSOR_DEFS.append( ('WIN32', None) ) # If this is a source distribution, add a couple of necessary include and # lib directories. pcbuildDir = os.path.join( os.path.split(distutils.sysconfig.get_python_inc())[0], 'PCBuild') if os.path.exists(pcbuildDir): PLATFORM_SPECIFIC_LIB_DIRS.append(pcbuildDir) pySrcDistExtraIncludeDir = os.path.join( os.path.split(distutils.sysconfig.get_python_inc())[0], 'PC') PLATFORM_SPECIFIC_INCLUDE_DIRS.append(pySrcDistExtraIncludeDir) # Verify the various directories (such as include and library dirs) that # will be used during compilation. # Open the registry in preparation for reading various installation # directories from it. try: import _winreg except ImportError: # If the user has manually specified all of the options that would # require registry access to autodetect, we can proceed despite the # lack of _winreg. if not ALL_AUTODETECT_WINDOWS_REGISTRY_OPTIONS_MANUALLY_SPECIFIED: sys.stderr.write( "%s\n" " Cannot import the standard package '_winreg'.\n" " _winreg did not join the standard library until\n" " Python 2.0. If you are using a source distribution\n" " of Python 2.0 or later, you may have simply forgotten\n" " to compile the _winreg C extension.\n" " You can get around the lack of _winreg by manually\n" " specifying all of the configuration options in the\n" " 'manual_config' section of the setup config file (%s)." % (AUTODETECTION_ERROR_HEADER, CONFIG_FILE) ) sys.exit(1) if not ALL_AUTODETECT_WINDOWS_REGISTRY_OPTIONS_MANUALLY_SPECIFIED: try: r = _winreg.ConnectRegistry(None, _winreg.HKEY_LOCAL_MACHINE) except WindowsError, e: sys.stderr.write( "%s\n" " Unable to connect to the HKEY_LOCAL_MACHINE section of\n" " the Windows registry.\n" " The specific error encountered is:\n" " %s" % (AUTODETECTION_ERROR_HEADER, str(e)) ) sys.exit(1) if DEBUG: print '*** DATABASE SETTINGS ***' # Autodetect database directory info if the user did not specify it. if not DATABASE_HOME_DIR: def findDatabaseHomeDir(databaseInfoKey, databaseHomeValueName): databaseCurrentVersionKey = _winreg.OpenKey(r, databaseInfoKey) try: return _winreg.QueryValueEx( databaseCurrentVersionKey, databaseHomeValueName )[0] finally: _winreg.CloseKey(databaseCurrentVersionKey) # Try to find Firebird first; revert to Interbase only if necessary. try: try: DATABASE_HOME_DIR = findDatabaseHomeDir( r'SOFTWARE\FirebirdSQL\Firebird\CurrentVersion', 'RootDirectory' ) DATABASE_IS_FIREBIRD = 1 if DEBUG: print ' Autodetected database is Firebird.' except WindowsError: # Revert to Interbase. DATABASE_IS_FIREBIRD = 0 DATABASE_HOME_DIR = findDatabaseHomeDir( r'SOFTWARE\Borland\InterBase\CurrentVersion', 'RootDirectory' ) if DEBUG: print ' Autodetected database is Interbase.' except WindowsError, e: sys.stderr.write( "%s\n" " Unable to retrieve database directory from the\n" " Windows registry.\n" " Try specifying the 'database_home_dir' option in the\n" " 'manual_config' section of the setup config file (%s).\n" " The specific error encountered is:\n" " %s" % (AUTODETECTION_ERROR_HEADER, CONFIG_FILE, str(e)) ) sys.exit(1) if DATABASE_INCLUDE_DIR: verifyUserSpecifiedDatabaseIncludeDir() databaseSDKDir = os.path.dirname(DATABASE_INCLUDE_DIR) else: # user-specified DATABASE_INCLUDE_DIR databaseSDKDir = os.path.join(DATABASE_HOME_DIR, 'SDK') if DATABASE_IS_FIREBIRD or not os.path.exists(databaseSDKDir): databaseSDKDir = DATABASE_HOME_DIR DATABASE_INCLUDE_DIR = os.path.join(databaseSDKDir, 'include') if DEBUG: print '\tDATABASE_INCLUDE_DIR exists at\n\t %s: %d' \ % (DATABASE_INCLUDE_DIR, os.path.exists(DATABASE_INCLUDE_DIR)) verifyAutodetectedDatabaseIncludeDir() if DATABASE_LIB_DIR: verifyUserSpecifiedDatabaseLibraryDir() else: # user-specified DATABASE_LIB_DIR DATABASE_LIB_DIR = os.path.join(databaseSDKDir, 'lib') verifyAutodetectedDatabaseLibraryDir() # Perform compiler-specific setup. if not DATABASE_LIB_NAME: DATABASE_LIB_NAME = 'gds32' # I should discover a way to ask distutils what compiler it's # configured to use--the current code would only detect a compiler # change via the command line. I've looked at the compiler subpackage # of distutils, and can't find any such facility (though it can be # queried for the system's default compiler). customCompilerName = 'msvc' import re argJam = string.lower(string.join(sys.argv[1:])) match = re.search(r'--compiler=(?P<cname>\S+)', argJam) if match: customCompilerName = match.group('cname') else: match = re.search(r'-c\s+(?P<cname>\S+)', argJam) if match: customCompilerName = match.group('cname') if customCompilerName == 'msvc': if not DATABASE_IS_FIREBIRD: DATABASE_LIB_DIR = os.path.join(databaseSDKDir, r'lib_ms') if not os.path.exists(DATABASE_LIB_DIR): DATABASE_LIB_DIR = os.path.join(databaseSDKDir, r'lib') if not DATABASE_LIB_NAME or DATABASE_LIB_NAME == 'gds32': DATABASE_LIB_NAME = 'gds32_ms' elif customCompilerName == 'bcpp': COMPILER_EXE_NAME = 'bcc32.exe' # Try to find the home directory of the Borland compiler by searching # each directory listed in the PATH. osPath = string.split(os.environ['PATH'], os.pathsep) bccHome = None for dir in osPath: if os.path.exists(os.path.join(dir, COMPILER_EXE_NAME)): bccHome = os.path.split(dir)[0] break else: # Couldn't find it. sys.stderr.write( "%s\n" " Unable to find the home directory of the Borland" " compiler.\n" " You must add the 'bin' subdirectory of the" " compiler's\n" " home directory to your PATH.\n" " One way to do this is to type a command of the" " format\n" " SET PATH=%%PATH%%;c:\\EXAMPLE_DIR\\bin\n" " in the same command prompt you use to run the" " kinterbasdb setup script." % (COMPILER_CONFIGURATION_ERROR_HEADER,) ) sys.exit(1) # Override the default behavior of distutils.bcppcompiler.BCPPCompiler # in order to force it to issue the correct command. from distutils.bcppcompiler import BCPPCompiler def _makeDirNameSpacless(kwargs, argName): x = kwargs.get(argName, None) if x is None: return elif isinstance(x, types.StringType): kwargs[argName] = findSpacelessDirName(x) else: # sequence of strings kwargs[argName] = [ findSpacelessDirName(d) for d in x ] class BCPP_UGLY_Hack(BCPPCompiler): def compile (self, *args, **kwargs): bccIncludePreargDir = findSpacelessDirName('%s\include' % bccHome) bccLibPreargDir = findSpacelessDirName('%s\lib' % bccHome) bccLibPSDKPreargDir = findSpacelessDirName('%s\lib\psdk' % bccHome) kwargs['extra_preargs'] = ( [ r'-I"%s"' % bccIncludePreargDir, r'-L"%s"' % bccLibPreargDir, r'-L"%s"' % bccLibPSDKPreargDir ] + kwargs.get('extra_preargs', []) ) for argName in ('output_dir', 'include_dirs'): _makeDirNameSpacless(kwargs, argName) return BCPPCompiler.compile(self, *args, **kwargs) def link (self, *args, **kwargs): ilinkLibPreargDir = findSpacelessDirName('%s\lib' % bccHome) ilinkLibPSDKPreargDir = findSpacelessDirName('%s\lib\psdk' % bccHome) myPreArgs = [ r'/L"%s"' % ilinkLibPreargDir, r'/L"%s"' % ilinkLibPSDKPreargDir ] if not kwargs.has_key('extra_preargs'): argsAsList = list(args) argsAsList[9] = myPreArgs # see distuils.ccompiler.py args = tuple(argsAsList) else: kwargs['extra_preargs'] = myPreArgs + kwargs.get['extra_preargs'] for argName in ( 'output_dir', 'library_dirs', 'runtime_library_dirs', 'build_temp' ): _makeDirNameSpacless(kwargs, argName) return BCPPCompiler.link(self, *args, **kwargs) compilerSetupTuple = distutils.ccompiler.compiler_class['bcpp'] import distutils.bcppcompiler distutils.bcppcompiler.BCPP_UGLY_Hack = BCPP_UGLY_Hack distutils.ccompiler.compiler_class['bcpp'] = ( compilerSetupTuple[0], 'BCPP_UGLY_Hack', compilerSetupTuple[2]) # Use coff2omf to create a Borland-compiler-compatible library file, # "pythonVV_bcpp.lib", from the standard "pythonVV.lib". # It would be better to use sys.version_info rather than the # string sys.version, but it's not available on older Python # versions. pyLibVersionSuffix = sys.version[0] + sys.version[2] # 2003.03.28: Accomodate source dists of Python on Windows (give the # PCBuild\pythonVV.lib file (if any) precedence over the # libs\pythonVV.lib file (if any)): pythonLibsDir = os.path.join(pythonHomeDir, 'PCbuild') if not os.path.exists(os.path.join(pythonLibsDir, 'python%s.lib' % pyLibVersionSuffix)): pythonLibsDir = os.path.join(pythonHomeDir, 'libs') newLibFilename = os.path.join(pythonLibsDir, 'python%s_bcpp.lib' % pyLibVersionSuffix) print 'setup.py is trying to create %s' % newLibFilename if not os.path.exists(os.path.join(newLibFilename)): # oldLibFilename = '%s\libs\python%s.lib' % ( oldLibFilename = os.path.join(pythonLibsDir, 'python%s.lib' % pyLibVersionSuffix) coff2omfCommand = ('coff2omf %s %s' % (oldLibFilename, newLibFilename)) os.system(coff2omfCommand) # Do this test instead of checking the return value of # os.system, which will not reliably indicate an error # condition on Win9x. if not os.path.exists(newLibFilename): sys.stderr.write( "%s\n" " Unable to create a Borland-compatible Python" " library file using the\n" " coff2omf utility.\n" " Tried command:\n" " %s" % ( COMPILER_CONFIGURATION_ERROR_HEADER, coff2omfCommand) ) sys.exit(1) assert os.path.exists(newLibFilename) if DEBUG: print '\tDATABASE_LIB_DIR exists at\n\t %s: %d' \ % (DATABASE_LIB_DIR, os.path.exists(DATABASE_LIB_DIR)) print '\tDATABASE_LIB_NAME is\n\t %s' % DATABASE_LIB_NAME elif sys.platform == 'cygwin': print ' *** CYGWIN LIBRARY GENERATION : begin ***' DATABASE_LIB_NAME = 'gds32' PLATFORM_SPECIFIC_LIB_DIRS.append('/usr/lib') PLATFORM_SPECIFIC_EXTRA_COMPILER_ARGS.append('-DUSE_DL_IMPORT') # PLATFORM_SPECIFIC_EXTRA_LINKER_ARGS = [] winSysDir = determineWindowsSystemDir() libUltimateDest = '/usr/lib/libgds32.a' libUltimateDir, libName = os.path.split(libUltimateDest) fbDir = 'c:/progra~1/firebird' if os.path.isfile(libUltimateDest): print ('\tCygwin-compatible Firebird library already exists at:\n\t %s' % libUltimateDest ) else: print ( '\n\tsetup.py is trying to create cygwin-compatible Firebird' ' library at:\n' '\t "%s"' % libUltimateDest ) fbClientLibFilename = os.path.join(fbDir, 'lib', 'gds32.lib') origCurDir = os.path.abspath(os.curdir) os.chdir(winSysDir) try: # Create def file containing symbols from gds32.lib. doLibConvCmd( '''(echo EXPORTS; nm %s | grep " T _"''' ''' | sed 's/.* T _//g' | sed 's/@.*$//g')''' ''' > gds32.def''' % fbClientLibFilename ) # End lame pexports substitute. # Create lib file from DLL and the just-generated def file. doLibConvCmd( 'dlltool --dllname gds32.dll --def gds32.def --output-lib %s' % libName ) os.remove('gds32.def') # Move the lib file to a location where cygwin-GCC's linker will # find it. shutil.copyfile(libName, libUltimateDest) os.remove(libName) finally: os.chdir(origCurDir) assert os.path.isfile(libUltimateDest) print ' *** CYGWIN LIBRARY GENERATION : end ***\n' else: # not Windows # If the platform isn't Linux, issue a warning. if len(sys.platform) < 5 or not string.lower(sys.platform)[:5] == 'linux': sys.stderr.write("Warning: The kinterbasdb setup code was not" " specifically written to support your platform (%s), and" " may not work properly.\n" % sys.platform ) else: # The platform is Linux. pass # Is libcrypt necessary on all POSIX OSes, or just Linux? # Until someone informs me otherwise, I'll assume all. if os.name == 'posix': PLATFORM_SPECIFIC_LIB_NAMES.append('crypt') # Verify the various directories (such as include and library dirs) that # will be used during compilation. # Assumption: # This is a Unix-like OS, where a proper installation routine would have # placed the database [header, library] files in a system-wide dirs. # We have no way of knowing beyond the shadow of a doubt whether that # has happened (as opposed to the situation on Windows, where we can # consult the registry to determine where a binary installer placed its # files), so we'll just let the compiler complain if it can't find the # [header, library] files. # If, on the other hand, the user manually specified the directories, we # may verify that they exist. if DATABASE_INCLUDE_DIR: # the user manually specified it verifyUserSpecifiedDatabaseIncludeDir() if DATABASE_LIB_DIR: # the user manually specified it verifyUserSpecifiedDatabaseLibraryDir() # 2003.04.12: begin block # On FreeBSD 4, the header and library files apparently are not made # visible by default (perhaps because the installation that prompted this # change was from a source distribution rather than an RPM, as all of my # testing on Linux has been?). # This script attempts to "autodetect" an installation at the default # location, but only if: # - no DATABASE_HOME_DIR has been manually specified # - the default installation directory actually exists # # This "autodetection" will probably work for some other Unixes as well. if not DATABASE_HOME_DIR: DEFAULT_FREEBSD_HOME_DIR = '/usr/local/firebird' if os.path.isdir(DEFAULT_FREEBSD_HOME_DIR): DATABASE_HOME_DIR = DEFAULT_FREEBSD_HOME_DIR if not DATABASE_INCLUDE_DIR: DATABASE_INCLUDE_DIR = os.path.join(DATABASE_HOME_DIR, 'include') if not DATABASE_LIB_DIR: DATABASE_LIB_DIR = os.path.join(DATABASE_HOME_DIR, 'lib') # 2003.04.12: end block if not DATABASE_LIB_NAME: DATABASE_LIB_NAME = 'gds' # Now finished with platform-specific compilation parameter setup. # Create a list of all INCLUDE dirs to be passed to setup(): allIncludeDirs = [] # Add Python include directory: allIncludeDirs.append(distutils.sysconfig.get_python_inc()) if len(PLATFORM_SPECIFIC_INCLUDE_DIRS) > 0: allIncludeDirs.extend(PLATFORM_SPECIFIC_INCLUDE_DIRS) if DATETIME_INCLUDE_DIR: allIncludeDirs.append(DATETIME_INCLUDE_DIR) if DATABASE_INCLUDE_DIR: allIncludeDirs.append(DATABASE_INCLUDE_DIR) # Create a list of all LIB names to be passed to setup(): allLibNames = [] if DATABASE_LIB_NAME: allLibNames.append(DATABASE_LIB_NAME) allLibNames.extend(PLATFORM_SPECIFIC_LIB_NAMES) if DEBUG: print '\tLIBRARY NAMES ', allLibNames # Create a list of all LIB directories to be passed to setup(): allLibDirs = [] if len(PLATFORM_SPECIFIC_LIB_DIRS) > 0: allLibDirs.extend(PLATFORM_SPECIFIC_LIB_DIRS) if DATABASE_LIB_DIR: allLibDirs.append(DATABASE_LIB_DIR) if DEBUG: print '\tLIBRARY DIRS ', allLibDirs # Create a list of all macro definitions that must be passed to distutils. allMacroDefs = [] if len(CUSTOM_PREPROCESSOR_DEFS) > 0: allMacroDefs.extend(CUSTOM_PREPROCESSOR_DEFS) # Create a list of all extra options to pass to the compiler, linker. allExtraCompilerArgs = [] if len(PLATFORM_SPECIFIC_EXTRA_COMPILER_ARGS) > 0: allExtraCompilerArgs.extend(PLATFORM_SPECIFIC_EXTRA_COMPILER_ARGS) allExtraLinkerArgs = [] if len(PLATFORM_SPECIFIC_EXTRA_LINKER_ARGS) > 0: allExtraLinkerArgs.extend(PLATFORM_SPECIFIC_EXTRA_LINKER_ARGS) extensionModules = [ distutils.core.Extension( "kinterbasdb._kinterbasdb", sources=["_kinterbasdb.c", "_kievents.c"], libraries=allLibNames, include_dirs=allIncludeDirs, library_dirs=allLibDirs, define_macros=allMacroDefs, extra_compile_args=allExtraCompilerArgs, extra_link_args=allExtraLinkerArgs ), ] # 2003.02.18: IB 5.5 build hack: allPythonModules = [ 'kinterbasdb.__init__', 'kinterbasdb.k_exceptions', # 2003.03.30: dynamic type conv: 'kinterbasdb.typeconv_active', 'kinterbasdb.typeconv_backcompat', 'kinterbasdb.typeconv_preferred', # 2003.05.19: additional components of refactored dynamic type conv: 'kinterbasdb.typeconv_fixed_stdlib', 'kinterbasdb.typeconv_fixed_fixedpoint', 'kinterbasdb.typeconv_datetime_mx', 'kinterbasdb.typeconv_datetime_stdlib', 'kinterbasdb.typeconv_util_isinstance', ] # Build somewhat differently if we're dealing with an IB version before 6.0. # (Innocent until proven guilty.) isIBLessThan_6_0 = 0 for incDir in allIncludeDirs: headerFilename = os.path.join(incDir, 'ibase.h') if os.path.exists(headerFilename): # Using the isc_decode_sql_time symbol as the detector is kinda arbitrary. if open(headerFilename).read().find('isc_decode_sql_time') == -1: isIBLessThan_6_0 = 1 break if isIBLessThan_6_0: print >> sys.stderr, \ 'WARNING: Not building the kinterbasdb._services module because' \ ' IB 5.5 does not support it.' else: # Only include the services module if dealing with >= IB 6.0. allPythonModules.append('kinterbasdb.services') extensionModules.append( distutils.core.Extension( "kinterbasdb._kiservices", sources=["_kiservices.c"], libraries=allLibNames, include_dirs=allIncludeDirs, library_dirs=allLibDirs, define_macros=allMacroDefs, extra_compile_args=allExtraCompilerArgs, extra_link_args=allExtraLinkerArgs ) ) # end IB 5.5 build hack of 2003.02.18 # Now we've detected and verified all compilation parameters, and are ready to # compile. if DEBUG: print '*** SETTINGS DETECTION PHASE COMPLETE; READY FOR BUILD ***' print ("\tThe DEBUG flag is enabled, so the setup script stops\n" "\t before actually invoking the distutils setup procedure." ) sys.exit(0) # The MEAT: distutils.core.setup( name=kinterbasdb_name, version=kinterbasdb_version, author='''Originally by Alexander Kuznetsov ; rewritten and expanded by David Rushby with contributions from several others (see docs/license.txt for details).''', author_email='woodsplitter(a)rocketmail.com', url='http://kinterbasdb.sourceforge.net', description='Python DB API 2.0 extension for Firebird and Interbase', long_description= 'kinterbasdb allows Python to access the Firebird and Interbase\n' 'SQL servers according to the interface defined by the Python\n' 'Database API Specification version 2.0.', license='see docs/license.txt', # 2003.02.18: IB 5.5 build hack: # For IB 5.5, need to include only specific components of the kinterbasdb # package, not the whole package. #packages=['kinterbasdb'], package_dir={'kinterbasdb': os.curdir}, py_modules=allPythonModules, ext_modules=extensionModules, data_files = [ # documentation: ('Lib/site-packages/kinterbasdb/docs', [ 'docs/index.html', 'docs/installation-source.html', 'docs/installation-binary.html', 'docs/usage.html', 'docs/changelog.txt', 'docs/license.txt', 'docs/Python-DB-API-2.0.html', 'docs/links.html', 'docs/global.css', 'docs/w3c.png', ] ) ] ) setup.py end ========================================= __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

2 1

Fwd: distutil command lines
by Brandon Long 04 Aug '03

04 Aug '03

I mailed this to Greg, and he said to try here: I've got a project with a python wrapper/extension module (amoung others), called ClearSilver http://www.clearsilver.net/ The package uses autoconf/configure to determine which programs are available, and how to build things, etc. This includes external libaries and locations for them, like -lz, -ldb, etc. Until recently, I've been just providing a Makefile for compiling the python extension, instead of using distutils. I don't really want to deal with compiling the shared library on all of the platforms, though, so I figured I'd go and create the setup.py script. The trouble is, how to pass the information from configure to the setup.py. I was just going to pass them on the command line, ie from Makefile: $(PYTHON) setup.py ext_build $(INCLUDES) $(LIBDIRS) $(LIBS) where $(INCLUDES) is a list of -Ipaths and $(LIBDIRS) is a list of -Lpaths and $(LIBS) is a list of -llibraries. Unfortunately, the command-line processing code, and the code for the setup.cfg file, seems to take the command line arguments and put them into a dictionary. Later, that dictionary is used to set the attributes of the ext_build class, which then translates the string into a single item list. So, this means I can't specify more than one option on the command line and get a list of libraries or paths. In fact, there seems to be no way to set a list on an option via the command line. That seems bad. Most people seem to deal with this problem by having as much smarts in the setup.py file as there are in their configure script... which seems annoying, especially since if there are similar macros for finding libraries and the like in distutils, they are at least not documented. Its also not clear to me how I can parse the command line arguments in setup.py... though I guess I could probably just import sys, run through sys.argv removing my arguments, or some such. I didn't try that, though. Instead, my "solution" is to parse the Makefile from the setup.py file, and setup the options from what I get. Obviously I can't write all of make, but it works well enough for my task (its not up there yet, it'll be in the next version). Any thoughts on fixing the command line arguments to support list options? Brandon -- program, n.: A magic spell cast over a computer allowing it to turn one's input into error messages. tr.v. To engage in a pastime similar to banging one's head against a wall, but with fewer opportunities for reward. http://www.fiction.net/blong/

5 5

RE: [Distutils] Re: Python 2.3/mingw32
by Moore, Paul 01 Aug '03

01 Aug '03

From: Paul Moore [mailto:pf_moore@yahoo.co.uk] >> We added an extra sanity check that was intended to guard against someone >> using a Python built with MSVC 6, say, and a DLL built with MSVC 7. The >> sanity check is that distutils finds out what compiler was used to build >> Python, and won't compile extensions with anything else. (I think I added >> this code.) > Er... I can build extensions quite happily with the mingw32 compiler, > against a stock Python 2.3 for Windows. [...] > Don't "fix" this, please! It would be a real problem if users couldn't > build C extensions with free tools, without having to build the whole > Python interpreter as well. Looks like (from other postings) that the check is in MSVCCompiler, and so doesn't apply to mingw builds (the original problem seems to have been an issue with the particular setup.py). So it looks like everything's OK for now, otherwise. As I said, once a MSVC7 compiled Python is available for me to test with, I'll look at getting mingw builds working appropriately. I guess I'll be able to steal the version test from msvccompiler.py to help me set the appropriate compiler flags... Cheers, Paul.

1 0