From robin at jessikat.fsnet.co.uk Tue Jul 1 00:27:19 2003 From: robin at jessikat.fsnet.co.uk (Robin Becker) Date: Mon Jun 30 18:28:10 2003 Subject: [Distutils] wordlength etc In-Reply-To: <3F009A40.1040303@lemburg.com> References: <3EFF188F.3020607@lemburg.com> <3EFF2C69.2080606@lemburg.com> <1057002701.17461.25.camel@slothrop.zope.com> <3F009A40.1040303@lemburg.com> Message-ID: <3PMcULAHlLA$EwSY@jessikat.fsnet.co.uk> In article <3F009A40.1040303@lemburg.com>, M.-A. Lemburg writes >Jeremy Hylton wrote: >> On Sun, 2003-06-29 at 14:14, M.-A. Lemburg wrote: >> >>>>So we assume struct units are 8 bits and then use calcsize("i")*8 as the >>>>wordlength. >>> >>>sizeofint = len(struct.pack('i',1)) >> >> Why not >> >> sizeofint = struct.calcsize("i") >> >> ? > >Even better :-) > well if I wish to store 4 bits/int then this works >>> import struct >>> print struct.calcsize("i") 4 but I assume we can store more than 4 bits per int, so waht tells us we cans store 8 bits/struct unit? -- Robin Becker From Jens.Bloch.Helmers at dnv.com Tue Jul 1 09:52:56 2003 From: Jens.Bloch.Helmers at dnv.com (Jens.Bloch.Helmers@dnv.com) Date: Tue Jul 1 02:51:21 2003 Subject: [Distutils] Bug in distutils? Message-ID: <1792E196E6A6834CA92D4984BE0FDFA72E3587@osl45.verit.dnv.com> I have encoutered a strange problem with distutils on Win2k,WinXP using python 2.2.2. When I run 'python setup.py install' the file 'data.txt' is copied as expected to: C:\Python22\Lib\site-packages\PyTest\data.txt When I run 'python setup.py bdist_wininst' and select default on all options during installation the file 'data.txt' is copied to: C:\Python22\python22\Lib\site-packages\PyTest\data.txt ++++++++++++++++++ I guess this is a bug. Best regards, Jens B. Helmers #Begin setup.py-------------------------------------------------- import os from distutils.core import setup from distutils import sysconfig package = "PyTest" files = ['data.txt'] install_dir = os.path.join( sysconfig.get_python_lib(), package ) setup(name = package, packages = [ package ], data_files = [ (install_dir, files) ] ) #End setup.py---------------------------------------------------- ********************************************************************** Neither the confidentiality nor the integrity of this message can be guaranteed following transmission on the Internet. This message has been swept by MAILsweeper at DNV for the presence of computer viruses. ********************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20030701/697774cf/attachment.htm From mal at lemburg.com Tue Jul 1 10:14:44 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jul 1 03:15:09 2003 Subject: [Distutils] wordlength etc In-Reply-To: <3PMcULAHlLA$EwSY@jessikat.fsnet.co.uk> References: <3EFF188F.3020607@lemburg.com> <3EFF2C69.2080606@lemburg.com> <1057002701.17461.25.camel@slothrop.zope.com> <3F009A40.1040303@lemburg.com> <3PMcULAHlLA$EwSY@jessikat.fsnet.co.uk> Message-ID: <3F0134E4.10907@lemburg.com> Robin Becker wrote: >>>sizeofint = struct.calcsize("i") > > well if I wish to store 4 bits/int then this works s/bits/bytes calcsize returns the number of 8-bit characters the format string needs to store the given C types. >>>>import struct >>>>print struct.calcsize("i") > > 4 > > but I assume we can store more than 4 bits per int, so waht tells us we > cans store 8 bits/struct unit? characters map to 8 bits == 1 byte and it's rather unlikely that a C compiler will use a different mapping any time soon. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Jul 01 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ From robin at jessikat.fsnet.co.uk Tue Jul 1 10:00:09 2003 From: robin at jessikat.fsnet.co.uk (Robin Becker) Date: Tue Jul 1 04:00:55 2003 Subject: [Distutils] wordlength etc In-Reply-To: <3F0134E4.10907@lemburg.com> References: <3EFF188F.3020607@lemburg.com> <3EFF2C69.2080606@lemburg.com> <1057002701.17461.25.camel@slothrop.zope.com> <3F009A40.1040303@lemburg.com> <3PMcULAHlLA$EwSY@jessikat.fsnet.co.uk> <3F0134E4.10907@lemburg.com> Message-ID: In article <3F0134E4.10907@lemburg.com>, M.-A. Lemburg writes ...... >characters map to 8 bits == 1 byte and it's rather unlikely that >a C compiler will use a different mapping any time soon. > that's what I thought, but it's wise to be sure, and though I suppose there are few Pdp-18's or CDC 6000's running these days, it doesn't seem unreasonable given the changes over the last 20 years that unicode of 16/32 bits might become more acceptable as a 'char unit'. -- Robin Becker From jh at web.de Tue Jul 1 17:53:10 2003 From: jh at web.de (Juergen Hermann) Date: Tue Jul 1 10:56:29 2003 Subject: [Distutils] custom install directory with bdist_wininst In-Reply-To: <1057000270.17461.18.camel@slothrop.zope.com> Message-ID: On 30 Jun 2003 15:11:11 -0400, Jeremy Hylton wrote: >I'd like to give the user control over where the files get installed. >It looks like distutils installs into site-packages by default, and >there's no way to override it. The UI shows the destination directory >in a box that looks like it should be editable, but it isn't. > >If you run setup.py install, you can pass a --home that affects where >files are installed. I'm looking for something similar on Windows. --install-data should work on Windows (while --home is Unix centric). That is out of the box, and of course you can always overload the command class for more complex things. Ciao, J?rgen -- J?rgen Hermann, Developer WEB.DE AG, http://webde-ag.de/ From jeremy at zope.com Tue Jul 1 16:03:37 2003 From: jeremy at zope.com (Jeremy Hylton) Date: Tue Jul 1 11:03:38 2003 Subject: [Distutils] custom install directory with bdist_wininst In-Reply-To: References: Message-ID: <1057071796.22104.7.camel@slothrop.zope.com> On Tue, 2003-07-01 at 10:53, Juergen Hermann wrote: > --install-data should work on Windows (while --home is Unix centric). > That is out of the box, and of course you can always overload the > command class for more complex things. I'm not sure if I understand. Is this an argument that the user passes to the Windows installer upon execution? I'm not interested in arguments to install, but in allowing user similar control using a binary installer. Jeremy From mal at lemburg.com Tue Jul 1 18:39:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jul 1 11:40:25 2003 Subject: [Distutils] custom install directory with bdist_wininst In-Reply-To: <1057071796.22104.7.camel@slothrop.zope.com> References: <1057071796.22104.7.camel@slothrop.zope.com> Message-ID: <3F01AB47.7050003@lemburg.com> Jeremy Hylton wrote: > On Tue, 2003-07-01 at 10:53, Juergen Hermann wrote: > >>--install-data should work on Windows (while --home is Unix centric). >>That is out of the box, and of course you can always overload the >>command class for more complex things. > > I'm not sure if I understand. Is this an argument that the user passes > to the Windows installer upon execution? I'm not interested in > arguments to install, but in allowing user similar control using a > binary installer. While the source code for the wininst installer is available, I'm not sure whether it would be easy to add this kind of functionality. You will probably want to use a different installer on Windows for these things, such as InnoSetup -- a bdist_inno would be *really* nice to have, because Inno offers so much more flexibility. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Jul 01 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2003-07-01: Released mxODBC Zope DA for FreeBSD 1.0.6 beta 1 From theller at python.net Tue Jul 1 18:44:13 2003 From: theller at python.net (Thomas Heller) Date: Tue Jul 1 11:48:13 2003 Subject: [Distutils] Re: custom install directory with bdist_wininst References: <1057071796.22104.7.camel@slothrop.zope.com> <3F01AB47.7050003@lemburg.com> Message-ID: "M.-A. Lemburg" writes: > Jeremy Hylton wrote: >> On Tue, 2003-07-01 at 10:53, Juergen Hermann wrote: >> >>> --install-data should work on Windows (while --home is Unix >>> centric). That is out of the box, and of course you can always >>> overload the command class for more complex things. >> I'm not sure if I understand. Is this an argument that the user >> passes >> to the Windows installer upon execution? I'm not interested in >> arguments to install, but in allowing user similar control using a >> binary installer. > > While the source code for the wininst installer is available, I'm > not sure whether it would be easy to add this kind of functionality. Correct. > > You will probably want to use a different installer on Windows for > these things, such as InnoSetup -- a bdist_inno would be *really* > nice to have, because Inno offers so much more flexibility. This is one possibility, another one is to treat the bdist_wininst created installer as a zipfile, and use a Python script to extract the files and install them. I have no need for either of them, and no time (not motivation) to write them. Thomas From ijones at syntaxpolice.org Tue Jul 1 16:49:35 2003 From: ijones at syntaxpolice.org (Isaac Jones) Date: Tue Jul 1 15:50:32 2003 Subject: [Distutils] Haskell distutils-type system Message-ID: <87d6gu3u40.fsf@syntaxpolice.org> Hello Python Community. I bring greetings from the Haskell community (http://www.haskell.org) ;) There has been a lot of discussion of late about creating a grand-unified build & distribution system for "3rd party" Haskell libraries (those not distributed with the compilers). Python's Distutils has come up a few times. The Haskell Library Infrastructure Project's web page is just a wiki page which can be found here: http://www.haskell.org/hawiki/LibraryInfrastructure. I'm running this project. I also wear another hat in that I'm interested in maintaining Debian packages related to Haskell, so I want to make my job easier by 1) writing software support, and 2) making it easy for other people to maintain Debian packages so I don't have to :) I've read much of the documentation at http://www.python.org/sigs/distutils-sig/doc/. I've also made a toy Python program that uses distutils. It occurs to me that the issues that were facing the Python community are strikingly similar to those facing the Haskell community now, except perhaps for the fact that there are at least 3 very strong Haskell "compilers" that we want to support. One idea for this distribution system, which we're calling the Library Infrastructure Project, is to create a nice gmake-based build system, document it, and leave it at that. Another idea is to use a Haskell-based Distutils type system. Now I think that the Haskell-based system should work out-of-the-box for pure-haskell modules (no extensions), and maybe wrap a more complex make-based system where necessary (as when interfacing with C or using preprocessors). I definitely want to optimize for the common case of joe-haskell-programmer wanting a nice way to distribute modules to his friends, but of course I also want to allow Haskell developers to do more complex things. The main issues facing us are: 1) there are a variety of Haskell "compiler" implementations, one of which is an interpreter :) 2) not all Haskell implementations are available on all architectures (ghc for instance) 3) just about every Haskell "compiler" and release is binary-incompatible, (except maybe for nhc98). That is, if we were going to distribute binary libraries, we'd need different binaries for ghc4, ghc5, and ghc6. Also we'd need different binaries for profiling versions of the libraries, etc. For instance, if I were to create a binary package HUnit, which is a simple case since its pure Haskell code, I would need: hunit-{hugs,nhc98} hunit-ghc{4,5,6} hunit-ghc{4,5,6}-prof And whenever a new version of GHC6 is released (for instance), all of the packages like hunit-ghc6 would need to be updated at the same time. That doesn't even get into the issues of the wide variety of preprocessors that are common in this rapidly advancing language[1]. So all of this suggests to me that we want to keep a global list of installed libraries and recompile them whenever a new Haskell "compiler" gets installed. This is why I want an abstraction layer above make. So I want to ask you if you can think of any obvious things we should watch out for if we try to do something similar to what Python is doing. Also, there was some mention (in the related "summary of the Developer's Day session") of Python's distutils creating a Makefile and wrapping calls to make, is this what you're doing? Do you / did you find yourself duplicating a lot of what make already does, ie dependencies, etc, or do you utilize make? What about configuration, do you typically interface with autoconf somehow, or does distutils have its own way to figure out configuration details? Is a typical distutils setup.py program pretty much like what we see in the example documentation? The developer provides some meta-data and gets a distribution tool? Is there any support for more complex stuff like interfacing with external systems? Does distutils handle dependencies? I've hacked together something that creates a source tarball and a basic Debian package from a Haskell version of the distutils-type metadata. I can make that available in a few days if anyone is interested. peace, isaac [1] Haskell is designed to have a "stable" version, Haskell98, and the compilers come with a variety of extensions so that it is very useful as a research language as well. From wtbridgman at radix.net Wed Jul 23 23:20:50 2003 From: wtbridgman at radix.net (W.T. Bridgman) Date: Wed Jul 23 22:18:39 2003 Subject: [Distutils] Newbie building SWIG wrappers with distutils Message-ID: <7166806C-BD7D-11D7-B80C-0050E485FC7A@radix.net> Hello, I searched the list archives and found some mention of getting SWIG v1.3 working with distutils but I couldn't find anything on the results of that effort. I've got a set of python modules that I'm beginning to convert to C/C++ extensions and some C/C++ code I want to wrap for Python using SWIG v1.3. I can get the extensions to build and work on their own (MacOS X 10.2.4, MacPython 2.3b1) but I can't get a distutils module to build them. My package directory looks something like this: Lib/ Lib/moduleA.py Lib/moduleB.py Packages/ Packages/__init__.py Packages/moduleC/ Packages/moduleC/moduleC.i Packages/moduleC/Lib/__init__.py Packages/moduleC/Include/moduleC.h Packages/moduleC/Src/moduleC.c where moduleA, moduleB are currently pure python but which may eventually converted to wrappers around C code and moduleC is being built as an extension. Based on the docs and study of other setup.py scripts, my script looks something like: extra_compile_args=["-Ddarwin"] packages=["WTBlib"] package_dir={'WTBlib':"Lib"} include_dirs=[os.path.join('/usr','local','lib')] ext_modules=[] packages.append('WTBlib.moduleC') package_dir['WTBlib.moduleC']=os.path.join('Packages','moduleC','Lib') include_dirs.append(os.path.join('Packages','moduleC','Include')) ext_modules.append(Extension('moduleC', [os.path.join('Packages','moduleC','Src','moduleC.c'), os.path.join('Packages','moduleC','moduleC.i')], extra_compile_args = extra_compile_args, include_dirs=include_dirs)) setup(name='WTBlib',version = "0.1", packages = packages, package_dir = package_dir, description = "", include_dirs = include_dirs, ext_package = "WTBlib", ext_modules = ext_modules) Currently, it fails trying to build the SWIG wrapper. So I built the wrappers manually (moduleC_wrap.c and moduleC.py and modified setup.py accordingly. I expected it to build in site-packages something like: WTBlib/ WTBlib/moduleA.py WTBlib/moduleB.py WTBlib/moduleC/ WTBlib/moduleC/_moduleC.so WTBlib/moduleC/moduleC.py WTBlib/moduleC/__init__.py which I believe is what I want. However, after having to modify things like #include paths in the wrapper file I can finally get it to build something like: WTBlib/ WTBlib/__init__.py WTBlib/moduleA.py WTBlib/moduleB.py WTBlib/moduleC.so WTBlib/moduleC/ WTBlib/moduleC/moduleC.py WTBlib/moduleC/__init__.py which just doesn't work at all. Pretends to import but no guts in the routines. Part of my problem is clearly that I don't understand how each of the components entered into the setup.py gets transformed into a path for such things as file copy and compilation parameters. Is there a better source of info on that? What is the status of letting distutils build the wrapper files? Also, just what is the __init__.py file for and is there ever a reason to put routines in it? Thanks, Tom From jsibre at chironsys.com Fri Jul 25 13:06:40 2003 From: jsibre at chironsys.com (Jason Sibre) Date: Fri Jul 25 13:07:37 2003 Subject: [Distutils] How do you get data_files and bdist_wininst to cooperate? Message-ID: Hi folks, I'm very new to this list and to distutils (this is my first stab at using it), so don't be afraid to point out the obvious... I'm trying to make a setup.py that will work on Linux and Win32, and be able to produce sdists and bdists for both platforms (I understand that I should use the targeted platform to build the bdist). The package I'm trying to distribute is actually a Quixote application, which (for those unfamiliar with Quixote) means it's a web application. I'd like to install it as a package in site-packages anyway, because that makes it easier to run multiple instances of the application (with different configuration data) on a machine without having multiple copies of it. As a web application, it has a few images, and a style.css file to distribute, and it also has a misc directory in the package (which perhaps shouldn't go there, but that's the way I'm trying to do it for now...) which includes a sample *.cgi file, *.conf file, and a python script intended to be run as a script (rather than imported as a module/package). I'm using the data_files argument to pass in those files, and I determine the directory to install to by extrapolating from the value of distutils.sysconfig.get_python_lib(), but that doesn't work right when I do a bdist_wininst (I haven't tried to do an RPM, yet, so I don't know if that works)... The files end up in "c:\python23\python23\projectTasks...." instead of "c:\python23\Lib\site-packages\projectTasks....". I've figured out a hack to do to the data_files (in code below) to make it work, but then the sdist doesn't work right, on Linux or Win32. Is there a way to achieve what I'm attempting, or do I just need to figure out at run time what the user is trying to do (build a bdist, or run an sdist), and decide then whether to apply my hack or not? Thanks, Jason Sibre Here's my setup.py file: --------------------------- #!/usr/bin/python import os, os.path from distutils.core import setup from distutils.sysconfig import get_python_lib from quixote.qx_distutils import qx_build_py def getFiles(path): fullFiles = [] files = os.listdir(path) for f in files: if f == "CVS": continue fullFiles.append(os.path.join(path,f)) return fullFiles webdir = os.path.join(get_python_lib(),'projectTasks','web') miscFiles = getFiles('web/misc') staticFiles = getFiles('web/staticFiles') #I think this is the 'right' way to do it, #and creates sdists that play nicely data_files = [ (os.path.join(webdir, 'misc'), miscFiles), (os.path.join(webdir, 'staticFiles'), staticFiles), ] #This works (as a hack) to get a win binary to install nicely #But of course makes a mess if you install from an sdist #data_files = [ # ('../PURELIB/projectTasks/web/misc', miscFiles), # ('../PURELIB/projectTasks/web/staticFiles', staticFiles), # ] setup( name = 'projectTasks', version = "0.1.0", description = "Project Task manager app for Quixote framework.", author = "Jason Sibre", author_email = "jsibre@chironsys.com", package_dir = {'projectTasks':'.'}, packages = ['projectTasks','projectTasks.web'], data_files = data_files, cmdclass = {'build_py': qx_build_py}, ) From hurtberman at earthlink.net Thu Jul 31 03:47:51 2003 From: hurtberman at earthlink.net (Shoreng) Date: Wed Jul 30 22:47:53 2003 Subject: [Distutils] distutils-sig,Sending file now Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20030731/68f54be7/attachment.htm From corydodt at yahoo.com Thu Jul 31 09:53:18 2003 From: corydodt at yahoo.com (Cory Dodt) Date: Thu Jul 31 11:59:47 2003 Subject: [Distutils] Python 2.3/mingw32 Message-ID: <3F293B6E.1020001@yahoo.com> What is this, and how can I get rid of it? cory@cory2k ~/cvs/Twisted $ python setup.py build -c mingw32 running build running build_py running build_ext error: Python was built with version 6 of Visual Studio, and extensions need to be built with the same version of the compiler, but it isn't installed. I had no problems building these extensions on Python 2.2 following the instructions at http://sebsauvage.net/python/mingw.html . I did the same thing substituting 2.3 for 2.2, and got the message above. Why doesn't it work any more? --compiler=mingw32 is still valid on the command line. From mal at lemburg.com Thu Jul 31 19:28:40 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jul 31 12:29:15 2003 Subject: [Distutils] Python 2.3/mingw32 In-Reply-To: <3F293B6E.1020001@yahoo.com> References: <3F293B6E.1020001@yahoo.com> Message-ID: <3F2943B8.8060402@lemburg.com> Cory Dodt wrote: > What is this, and how can I get rid of it? > > cory@cory2k ~/cvs/Twisted > $ python setup.py build -c mingw32 > running build > running build_py > running build_ext > error: Python was built with version 6 of Visual Studio, and extensions > need to > be built with the same version of the compiler, but it isn't installed. > > I had no problems building these extensions on Python 2.2 following the > instructions at http://sebsauvage.net/python/mingw.html . I did the > same thing substituting 2.3 for 2.2, and got the message above. > > Why doesn't it work any more? --compiler=mingw32 is still valid on the > command line. The above message is generated by the MSVC code, so the only reason I can see is that your option didn't pass through to build_ext. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Jul 31 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ From corydodt at yahoo.com Thu Jul 31 10:36:58 2003 From: corydodt at yahoo.com (Cory Dodt) Date: Thu Jul 31 12:43:10 2003 Subject: [Distutils] Python 2.3/mingw32 In-Reply-To: <3F2943B8.8060402@lemburg.com> References: <3F293B6E.1020001@yahoo.com> <3F2943B8.8060402@lemburg.com> Message-ID: <3F2945AA.2040900@yahoo.com> M.-A. Lemburg wrote: > Cory Dodt wrote: > What is this, and how can I get rid of it? > >> $ python setup.py build -c mingw32 > > running build > >> running build_py > > running build_ext > >> error: Python was built with version 6 of Visual Studio, and extensions > >> need to > >> be built with the same version of the compiler, but it isn't installed. > > > > The above message is generated by the MSVC code, so the only > > reason I can see is that your option didn't pass through to > > build_ext. The same thing happens invoking build_ext directly, alas: $ python setup.py build_ext -c mingw32 running build_ext error: Python was built with version 6 of Visual Studio, and extensions need to be built with the same version of the compiler, but it isn't installed. From pje at telecommunity.com Thu Jul 31 14:41:53 2003 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu Jul 31 13:42:29 2003 Subject: [Distutils] Re: [Twisted-Python] Re: Twisted - Python 2.3 - Windows In-Reply-To: References: <20030731114303.19165.89412.Mailman@pyramid.twistedmatrix.com> <3F294288.4000009@yahoo.com> Message-ID: <5.1.1.6.0.20030731133337.01dc7020@telecommunity.com> At 07:05 PM 7/31/03 +0200, Thomas Heller wrote: >Cory Dodt writes: > > >>Subject: [Twisted-Python] Twisted - Python 2.3 - Windows > >> > >>Hi, > >> > >> anyone who knows when the first Python 2.3 build of twisted for > >> windows will be available? Which version will it be? > >> > >> I tried to build it myself but got into trouble. I first installed > >> Cygwin and then tried 'setup.py build --compiler=mingw32' as per > >> documentation, but I got an error message that Python itself is > >> build with Visual Studio 6. > >>I don't feel building python myself and I don't have VS6. > >> > > > > I'm with you man, I don't feel like building Python myself either. I > > have asked the appropriate list > > (http://mail.python.org/pipermail/distutils-sig/2003-July/003333.html ) > > about this problem. I also tried using distutils from CVS instead of > > the bundled copy with Python 2.3, and no luck. It looks like the error occurs when an MSVCCompiler instance is created; I haven't yet figured out *why* such an instance is being created. I don't have 2.3 installed on Win32, so as an experiment, I added a 'raise' statement to 2.2's MSVCCompiler. If I specified compilation with msvc, I get the error I raised. If I specify mingw32, I don't. So, evidently 2.2's distutils don't create an MSVCCompiler instance when specifying mingw32. I can't fathom why 2.3 would do so. From amk at asti-usa.com Thu Jul 31 15:58:04 2003 From: amk at asti-usa.com (A.M. Kuchling) Date: Thu Jul 31 14:58:37 2003 Subject: [Distutils] Re: [Twisted-Python] Re: Twisted - Python 2.3 - Windows In-Reply-To: <5.1.1.6.0.20030731133337.01dc7020@telecommunity.com> References: <20030731114303.19165.89412.Mailman@pyramid.twistedmatrix.com> <3F294288.4000009@yahoo.com> <5.1.1.6.0.20030731133337.01dc7020@telecommunity.com> Message-ID: <20030731185804.GA20994@vail.asti-usa.com> On Thu, Jul 31, 2003 at 01:41:53PM -0400, Phillip J. Eby wrote: > It looks like the error occurs when an MSVCCompiler instance is created; I > haven't yet figured out *why* such an instance is being created. I don't Surely the resulting traceback tells you the line of code where it's being instantiated? --amk From corydodt at yahoo.com Thu Jul 31 13:09:31 2003 From: corydodt at yahoo.com (Cory Dodt) Date: Thu Jul 31 15:15:48 2003 Subject: [Distutils] solved Re: [Twisted-Python] Re: Twisted - Python 2.3 - Windows - mingw In-Reply-To: <5.1.1.6.0.20030731133337.01dc7020@telecommunity.com> References: <20030731114303.19165.89412.Mailman@pyramid.twistedmatrix.com> <3F294288.4000009@yahoo.com> <5.1.1.6.0.20030731133337.01dc7020@telecommunity.com> Message-ID: <3F29696B.60808@yahoo.com> Phillip J. Eby wrote: > > It looks like the error occurs when an MSVCCompiler instance is > created; I > haven't yet figured out *why* such an instance is being created. I don't > have 2.3 installed on Win32, so as an experiment, I added a 'raise' > statement to 2.2's MSVCCompiler. If I specified compilation with msvc, I > get the error I raised. If I specify mingw32, I don't. So, evidently > 2.2's distutils don't create an MSVCCompiler instance when specifying > mingw32. I can't fathom why 2.3 would do so. Well, I figured out why. This was a bug in Twisted's setup.py, which has a function _check_header that is supposed to invoke the compiler on a tiny test module to make sure the module being built will build successfully. The new compiler is constructed with new_compiler(), but no arguments were passed to it; it was this invocation that fails with the error message I was getting. This bug was introduced some time ago; I'm not sure why I didn't see it before now. Using self.compiler instead worked (there's no need to call new_compiler() when it's already been done for you). C From jeremy at alum.mit.edu Thu Jul 31 16:44:44 2003 From: jeremy at alum.mit.edu (Jeremy Hylton) Date: Thu Jul 31 15:30:59 2003 Subject: [Distutils] Python 2.3/mingw32 In-Reply-To: <3F293B6E.1020001@yahoo.com> Message-ID: > What is this, and how can I get rid of it? > > cory@cory2k ~/cvs/Twisted > $ python setup.py build -c mingw32 > running build > running build_py > running build_ext > error: Python was built with version 6 of Visual Studio, and extensions > need to > be built with the same version of the compiler, but it isn't installed. > > I had no problems building these extensions on Python 2.2 following the > instructions at http://sebsauvage.net/python/mingw.html . I did the > same thing substituting 2.3 for 2.2, and got the message above. > > Why doesn't it work any more? --compiler=mingw32 is still valid on the > command line. 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.) When I was working on this, I was not even aware of the --compiler option. I don't know how dangerous it is to use DLLs from one compiler with a Python from a different compiler. I believe David Abrahams was involved in those discussions, and I've seen him here; perhaps he can offer an explanation. Assuming it is safe to change compilers, it sounds like we need a patch to get 2.3 distutils working with custom compilers. I've never used a compiler other than MSVC on Windows, so I can't be of much help. I can merely confirm it doesn't break things for MSVC. Jeremy From pf_moore at yahoo.co.uk Thu Jul 31 22:10:35 2003 From: pf_moore at yahoo.co.uk (Paul Moore) Date: Thu Jul 31 16:24:46 2003 Subject: [Distutils] Re: Python 2.3/mingw32 References: <3F293B6E.1020001@yahoo.com> Message-ID: <1xw6wj7o.fsf@yahoo.co.uk> "Jeremy Hylton" writes: > 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. > When I was working on this, I was not even aware of the --compiler option. > I don't know how dangerous it is to use DLLs from one compiler with a Python > from a different compiler. I believe David Abrahams was involved in those > discussions, and I've seen him here; perhaps he can offer an explanation. Code compiled with mingw32 is, by default, compatible with Python built with MSVC6 (both link to msvcrt.dll). There would be incompatibilities if Python was built with MSVC7, as this uses a different C runtime DLL, but it should be possible to supply suitable command line options to the mingw32 compiler to allow compatible extensions to be built. Indeed, I have committed to making sure that happens - although I have no way of doing so until I have access to a Python built with MSVC7 (I don't have that compiler myself, and am not likely to get it). > Assuming it is safe to change compilers, it sounds like we need a patch to > get 2.3 distutils working with custom compilers. I've never used a compiler > other than MSVC on Windows, so I can't be of much help. I can merely > confirm it doesn't break things for MSVC. As I say, --compiler=mingw32 works fine with the distributed Python 2.3 binary. I imagine that it won't (either the build fails, or the extension is incompatible) with a custom-built-with-MSVC7 Python. 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. Paul. -- This signature intentionally left blank