From sophiec@scripps.edu Mon Aug 6 20:40:04 2001 From: sophiec@scripps.edu (Sophie Coon) Date: Mon Aug 6 19:40:04 2001 Subject: [Distutils] Intermediat library and sdist problem Message-ID: <3B6F29E3.FA33C7C9@scripps.edu> Hi, I am trying to write a setup.py to create a source distribution for a wrapped library. The trick is that I need to build an intermediate library and the sdist command doesn't seem to like it. Here is the setup.py that I wrote. ========================================================================================= import os, sys, string from distutils.sysconfig import get_python_inc from distutils.core import setup, Extension # key is python version : value is the correspondent python directory name versionPath = {'2.0':'python2.0', '1.5.2':'python1.5', '2.1':'python2.1'} # Where the source file for the amber library are. libamberSrcs = ['./src/binpos.c', './src/conjgrad.c', './src/memutil.c', './src/prm.c', './src/sff.c', './src/rand2.c'] # Here could be replace by sys.prefix and sys.exec_prefix. # That will be for the distribution purpose. version = string.split(sys.version)[0] depInclude = sys.exec_prefix + '/include/%s/'%versionPath[version] numInclude = sys.prefix+'/include/%s/Numeric/'%versionPath[version] shareInclude = sys.prefix+'/include/%s/'%versionPath[version] setup( name = 'amber', version = '94', description = 'Simple Force Field (SFF) package from Amber', author = "Tom Mackle, David Case", packages = [''], libraries = [('libamber', {'sources':libamberSrcs, 'include_dirs':['./src/',depInclude, numInclude, shareInclude ], 'macros':[]}, ),], ext_modules = [Extension('sffCmodule', ['sffCmodule.c',], include_dirs = ['./src/',depInclude, numInclude,shareInclude,], libraries=['libamber']) ]) ========================================================================================================================= python2.0 setup.py sdist gives me the following error message: Traceback (innermost last): File "setup.py", line 44, in ? libraries=['libamber']) File "/tsri/python/share/lib/python1.5/site-packages/distutils/core.py", line 138, in setup dist.run_commands() File "/tsri/python/share/lib/python1.5/site-packages/distutils/dist.py", line 829, in run_commands self.run_command(cmd) File "/tsri/python/share/lib/python1.5/site-packages/distutils/dist.py", line 849, in run_command cmd_obj.run() File "/tsri/python/share/lib/python1.5/site-packages/distutils/command/sdist.py", line 143, in run self.get_file_list() File "/tsri/python/share/lib/python1.5/site-packages/distutils/command/sdist.py", line 242, in get_file_list self.add_defaults() File "/tsri/python/share/lib/python1.5/site-packages/distutils/command/sdist.py", line 319, in add_defaults self.filelist.extend(build_clib.get_source_files()) File "/tsri/python/share/lib/python1.5/site-packages/distutils/cmd.py", line 107, in __getattr__ raise AttributeError, attr AttributeError: get_source_files I can very successfully run the following command: python2.0 setup.py bdist python2.0 setup.py build In the last case I have a working package that I can import from a python interpreter. I am pretty sure that the sdist command doesn't work because the intermediate library has not benn build yet when trying to do the tar ball. Did I make a mistake in the setup.py? if not is there a way around that problem? Thanks for any suggestions ! Sophie -- ############################################################ Sophie COON The Scripps Research Institute Research Programmer III Molecular Graphics Laboratory 10550 North Torrey Pines Road Phone: (858) 784-9556 La Jolla, CA 92037 Fax : (858) 784-2860 ############################################################ From R.Liebscher@gmx.de Tue Aug 7 05:42:01 2001 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Tue Aug 7 04:42:01 2001 Subject: [Distutils] Intermediat library and sdist problem References: <3B6F29E3.FA33C7C9@scripps.edu> Message-ID: <3B6F9DE9.679952EE@gmx.de> Sophie Coon wrote: > > Hi, > I am trying to write a setup.py to create a source distribution for a > wrapped library. The trick is that I need to build an intermediate > library and the sdist command doesn't seem to like it. > > ... > > python2.0 setup.py sdist gives me the following error message: > > Traceback (innermost last): > File "setup.py", line 44, in ? > libraries=['libamber']) > ... > File > "/tsri/python/share/lib/python1.5/site-packages/distutils/cmd.py", line > 107, in __getattr__ > raise AttributeError, attr > AttributeError: get_source_files > > I can very successfully run the following command: > python2.0 setup.py bdist > python2.0 setup.py build > In the last case I have a working package that I can import from a > python interpreter. > > I am pretty sure that the sdist command doesn't work because the > intermediate library has not benn build yet when trying to do the tar > ball. Did I make a mistake in the setup.py? if not is there a way around > that problem? > > Thanks for any suggestions ! > Sophie Your setup.py is probably ok, it is a distutils bug, it is already filed in the bugs database ([ #414032 ] clib option is broken) http://sourceforge.net/tracker/index.php?func=detail&aid=414032&group_id=5470&atid=105470 Kind regards Rene Liebscher From just@letterror.com Tue Aug 7 05:58:00 2001 From: just@letterror.com (Just van Rossum) Date: Tue Aug 7 04:58:00 2001 Subject: [Distutils] unixcompile.py, Darwin (MacOSX), ranlib? Message-ID: <20010807105742-r01010700-86bd5066-0910-010c@10.0.0.17> I've noticed that when building a static library as part of a setup.py, I have to do ranlib build/temp./*.a and then run "python setup.py build" again before it works. is "darwin-1.3.7-Power Macintosh-2.1". Can anyone suggest a patch to unixcompiler.py so that ranlib is invoked under Darwin? I've seen the comment "Not many Unices required ranlib anymore", so apparently Darwin is one of these... Just From robin@jessikat.fsnet.co.uk Tue Aug 7 06:11:01 2001 From: robin@jessikat.fsnet.co.uk (Robin Becker) Date: Tue Aug 7 05:11:01 2001 Subject: [Distutils] configuration Message-ID: Just v.R has been having some problems compiling a particular library that needed libart. libart has a configuration script that should properly be invoked before building the library. Are there any plans to ease the invocation of such scripts or alternatively how to I determine in python things like endianness in size, short size long size etc etc. For all I know Darwin might run on both big and little endian machines so it's wrong to rely simply on the platform for this sort of thing. -- Robin Becker From mal@lemburg.com Tue Aug 7 12:13:06 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue Aug 7 11:13:06 2001 Subject: [Distutils] configuration References: Message-ID: <3B6FCD9C.DDFCDB01@lemburg.com> Robin Becker wrote: > > Just v.R has been having some problems compiling a particular library > that needed libart. libart has a configuration script that should > properly be invoked before building the library. This should be possible by subclassing build_ext. I've been doing this in the eGenix mx Extensions (see mxSetup.py which comes with them) for doing autoconf work at build time. Works fine for me, but the tools are still somewhat limited -- nothing which a extra Python module couldn't solve though ;-) > Are there any plans to ease the invocation of such scripts or > alternatively how to I determine in python things like endianness in > size, short size long size etc etc. For all I know Darwin might run on > both big and little endian machines so it's wrong to rely simply on the > platform for this sort of thing. The sys module has recently grown a few attributes which let you query the endianess. My platform.py also provides you with a lot of interesting information in that area. If you want to use Python 1.5.2, I think the best solution is by using the struct module and testing the resulting string data for size and position of the various bits. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From just@letterror.com Thu Aug 9 13:13:59 2001 From: just@letterror.com (Just van Rossum) Date: Thu Aug 9 12:13:59 2001 Subject: [Distutils] behavior when failing to build an extension? Message-ID: <20010809181406-r01010700-145ed294-0910-010c@10.0.0.20> What's the intended behavior if an extension fails to build? Should it print an error message and continue, or should it stop? (On the Mac distutils currently stops, which is kindof a nuisance, so I'm tempted to "fix" it...) Just From bh@intevation.de Thu Aug 9 13:25:03 2001 From: bh@intevation.de (Bernhard Herzog) Date: Thu Aug 9 12:25:03 2001 Subject: [Distutils] behavior when failing to build an extension? In-Reply-To: <20010809181406-r01010700-145ed294-0910-010c@10.0.0.20> References: <20010809181406-r01010700-145ed294-0910-010c@10.0.0.20> Message-ID: <6qelqltd6g.fsf@abnoba.intevation.de> Just van Rossum writes: > What's the intended behavior if an extension fails to build? Should it > print an error message and continue, or should it stop? (On the Mac > distutils currently stops, which is kindof a nuisance, so I'm tempted > to "fix" it...) I think distutils should print an error and stop by default. That way users trying to build an extension immediately know that something went wrong. A command line option to make distutils try to go on if an error occurs might be useful, though, as long a clear message that an error occurred and the commands weren't completed successfully is printed at the end. Bernhard -- Intevation GmbH http://intevation.de/ Sketch http://sketch.sourceforge.net/ MapIt! http://mapit.de/ From just@letterror.com Thu Aug 9 13:43:10 2001 From: just@letterror.com (Just van Rossum) Date: Thu Aug 9 12:43:10 2001 Subject: [Distutils] behavior when failing to build an extension? In-Reply-To: <6qelqltd6g.fsf@abnoba.intevation.de> Message-ID: <20010809184242-r01010700-653decee-0910-010c@10.0.0.20> Bernhard Herzog wrote: > I think distutils should print an error and stop by default. That way > users trying to build an extension immediately know that something went > wrong. Is that what happens under Unix? Just From bh@intevation.de Thu Aug 9 14:22:02 2001 From: bh@intevation.de (Bernhard Herzog) Date: Thu Aug 9 13:22:02 2001 Subject: [Distutils] behavior when failing to build an extension? In-Reply-To: <20010809184242-r01010700-653decee-0910-010c@10.0.0.20> References: <20010809184242-r01010700-653decee-0910-010c@10.0.0.20> Message-ID: <6qae19taob.fsf@abnoba.intevation.de> Just van Rossum writes: > Bernhard Herzog wrote: > > > I think distutils should print an error and stop by default. That way > > users trying to build an extension immediately know that something went > > wrong. > > Is that what happens under Unix? Yes, distutils stops with a message along the lines of error: command 'gcc' failed with exit status 1 That's also what e.g. make does by default, unless you run it with the -k flag. Bernhard -- Intevation GmbH http://intevation.de/ Sketch http://sketch.sourceforge.net/ MapIt! http://mapit.de/ From just@letterror.com Thu Aug 9 15:00:04 2001 From: just@letterror.com (Just van Rossum) Date: Thu Aug 9 14:00:04 2001 Subject: [Distutils] behavior when failing to build an extension? Message-ID: <20010809200010-r01010700-2cb1a7b1-0910-010c@10.0.0.20> Bernhard Herzog wrote: > Yes, distutils stops with a message along the lines of > error: command 'gcc' failed with exit status 1 > > That's also what e.g. make does by default, unless you run it with the > -k flag. Ok, thanks, then there's not much for me to do, except perhaps at some point make the error message nicer: it now crashes with a nasty traceback... Btw. does really nobody have any advice on my ranlib question of a couple of days ago? Just From mal@lemburg.com Thu Aug 9 18:09:00 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu Aug 9 17:09:00 2001 Subject: [Distutils] behavior when failing to build an extension? References: <20010809200010-r01010700-2cb1a7b1-0910-010c@10.0.0.20> Message-ID: <3B72E55B.30171521@lemburg.com> Just van Rossum wrote: > > Bernhard Herzog wrote: > > > Yes, distutils stops with a message along the lines of > > error: command 'gcc' failed with exit status 1 > > > > That's also what e.g. make does by default, unless you run it with the > > -k flag. > > Ok, thanks, then there's not much for me to do, except perhaps at some point > make the error message nicer: it now crashes with a nasty traceback... distutils is your friend here: you just have subclass build_ext. > Btw. does really nobody have any advice on my ranlib question of a couple of > days ago? Nope. Why don't you write up a patch which then only affects distutils on Macs ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From just@letterror.com Thu Aug 9 18:43:00 2001 From: just@letterror.com (Just van Rossum) Date: Thu Aug 9 17:43:00 2001 Subject: [Distutils] behavior when failing to build an extension? In-Reply-To: <3B72E55B.30171521@lemburg.com> Message-ID: <20010809234306-r01010700-500d88cb-0910-010c@10.0.0.20> M.-A. Lemburg wrote: > > Ok, thanks, then there's not much for me to do, except perhaps at some point > > make the error message nicer: it now crashes with a nasty traceback... > > distutils is your friend here: you just have subclass build_ext. I have no idea what that has to do with what I wrote... > > Btw. does really nobody have any advice on my ranlib question of a couple of > > days ago? > > Nope. Why don't you write up a patch which then only affects distutils > on Macs ?! Ok, I'll try. I didn't know whether that was a nono or not. Just From sophiec@scripps.edu Tue Aug 14 13:51:00 2001 From: sophiec@scripps.edu (Sophie Coon) Date: Tue Aug 14 12:51:00 2001 Subject: [Distutils] Headers files Message-ID: <3B7955BD.8803BD66@scripps.edu> Hi , I am pretty new with distutils and I am using it for creating source distibution of my packages. I don't understand why distutils doesn't include automatically headers files needed for extension modules ? Thanks for any feed back. Sophie -- ############################################################ Sophie COON The Scripps Research Institute Research Programmer III Molecular Graphics Laboratory 10550 North Torrey Pines Road Phone: (858) 784-9556 La Jolla, CA 92037 Fax : (858) 784-2860 ############################################################ From oliphant.travis@ieee.org Tue Aug 14 23:37:00 2001 From: oliphant.travis@ieee.org (Travis Oliphant) Date: Tue Aug 14 22:37:00 2001 Subject: [Distutils] Headers files In-Reply-To: <3B7955BD.8803BD66@scripps.edu> References: <3B7955BD.8803BD66@scripps.edu> Message-ID: <01081420395800.23323@travis> On Tue, 14 Aug 2001, you wrote: > Hi , > I am pretty new with distutils and I am using it for creating source > distibution of my packages. I don't understand why distutils doesn't > include automatically headers files needed for extension modules ? > Thanks for any feed back. > Sophie If you make a MANIFEST.in file which contains the header files it will include them. Good luck, -Travis Oliphant From R.Liebscher@gmx.de Wed Aug 15 03:57:27 2001 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Wed Aug 15 02:57:27 2001 Subject: [Distutils] Headers files References: <3B7955BD.8803BD66@scripps.edu> Message-ID: <3B7A1CB6.E50E7A32@gmx.de> Sophie Coon wrote: > > Hi , > I am pretty new with distutils and I am using it for creating source > distibution of my packages. I don't understand why distutils doesn't > include automatically headers files needed for extension modules ? > Thanks for any feed back. > Sophie Distutils doesn't know which header files are needed by your code. May be we should think about some kind of parser which extracts all #include lines from the code. You could safely ignore any #defines and #ifdef, because for a source distribution any possible #include must be considered. This parsing had to be done in a recursive way. And when we know all header files, we could add any header files which resides in the directory of setup.py or in one of its sub directories to the MANIFEST file. What does the other people at this mailing list think of such an extension? (It had to be put in the get_source_files methods of build_clib and build_ext.) Kind regards Rene Liebscher From akuchlin@mems-exchange.org Thu Aug 16 18:04:01 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu Aug 16 17:04:01 2001 Subject: [Distutils] build_scripts and #!/usr/bin/env Message-ID: The build_scripts command changes the #! line of Python scripts to match the Python installation being used to run the setup.py script. Currently it only fixes lines of the form #!/a/b/c/python, but leaves '#!/usr/bin/env python' alone. It used to also change #!/usr/bin/env lines, but I changed that behaviour because I think it's wrong and leaves you with no way at all to install a script that uses /usr/bin/env . A bug caused by this is at http://sourceforge.net/tracker/index.php?func=detail&aid=409430&group_id=5470&atid=105470 I think this is a silly use case, where you want pydoc to use a different Python from the default interpreter you get by running 'python', but will bow to the SIG's opinion. So, fix /usr/bin/env lines or not? --amk From eric@scipy.org Mon Aug 20 22:54:01 2001 From: eric@scipy.org (eric jones) Date: Mon Aug 20 21:54:01 2001 Subject: [Distutils] first cut at fortran support for distutils Message-ID: <002101c129da$f167de10$ec88fea9@ericlaptop> Travis Oliphant and I have hacked together Fortran support for distutils in the course of putting together scipy (www.scipy.org). I won't pretend its pretty, but it does seem to do the job on Linux and W2000/W98 using the mingw32 version of gcc/g77. We're also working on Sun and Irix. Basically, the static_clib has been modified to build static libraries of the fortran code that are then linked with the extension module interface (written in C). We'd like to work toward this becoming a standard part of distutils. Are others interested in this? Also, opinions on how to best pursue its inclusion are welcomed. If your interested, please grab the source version of scipy from the site and take a look at fortran_support.py, build_flib.py, build_clib_new.py, and setup.py. thanks, eric From Paul.Moore@atosorigin.com Thu Aug 23 13:17:03 2001 From: Paul.Moore@atosorigin.com (Moore, Paul) Date: Thu Aug 23 12:17:03 2001 Subject: [Distutils] Swig for Windows Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AFAB@UKRUX002.rundc.uk.origin-it.com> Hi, Where can I get a working version of swig (suitable for use with Python distutils) for Windows? The downloads from the web site don't work out of the box - distutils uses a -dnone argument, which they don't support, and they don't seem to find the python.swg file when run by hand - I get errors >swig -python example.i Generating wrappers for Python SWIG : Fatal error. Unable to locate python.swg. (Possible installation problem) This is just downloading and extracting to a new directory which I put into my PATH (not how I'd like to do it, but the simplest guess in the absence of any obvious installation instructions :-() Thanks, Paul From thomas.heller@ion-tof.com Thu Aug 23 13:31:01 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Aug 23 12:31:01 2001 Subject: [Distutils] Swig for Windows References: <714DFA46B9BBD0119CD000805FC1F53B01B5AFAB@UKRUX002.rundc.uk.origin-it.com> Message-ID: <054401c12bf0$d429d020$e000a8c0@thomasnotebook> > Hi, > Where can I get a working version of swig (suitable for use with Python > distutils) for Windows? The downloads from the web site don't work out of > the box - distutils uses a -dnone argument, which they don't support, and > they don't seem to find the python.swg file when run by hand - I get errors Distutils probably works with SWIG1.1, which has the -dnone flag. It seems you can still download this one (maybe only the source distro). > > >swig -python example.i > Generating wrappers for Python > SWIG : Fatal error. Unable to locate python.swg. (Possible installation > problem) > > This is just downloading and extracting to a new directory which I put into > my PATH (not how I'd like to do it, but the simplest guess in the absence of > any obvious installation instructions :-() IIRC, you have to set a SWIG_LIB environment variable, but it should be somewhere in the docs. Thomas From jeremy@zope.com Thu Aug 23 16:14:03 2001 From: jeremy@zope.com (Jeremy Hylton) Date: Thu Aug 23 15:14:03 2001 Subject: [Distutils] syntax errors in Python source files Message-ID: <15237.21954.298958.713598@slothrop.digicool.com> I just tried to build and install a distutils package using Python 1.5.2. The package uses some features added after 1.5.2 and a few files have SyntaxErrors as a result. I did a "setup.py build" and didn't get any complaints, but I did get errors when I tried the install. Does setup.py build generate .pyc files? It seems like it must not, or I should have seen errors when I did the build. If it doesn't, it seems like it should; otherwise you'll fail to catch SyntaxErrors until install time. Jeremy From Paul.Moore@atosorigin.com Fri Aug 24 04:54:00 2001 From: Paul.Moore@atosorigin.com (Moore, Paul) Date: Fri Aug 24 03:54:00 2001 Subject: [Distutils] Swig for Windows Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5AFAC@UKRUX002.rundc.uk.origin-it.com> From: Thomas Heller [mailto:thomas.heller@ion-tof.com] > Distutils probably works with SWIG1.1, which has the > -dnone flag. It seems you can still download this one > (maybe only the source distro). [...] > IIRC, you have to set a SWIG_LIB environment variable, > but it should be somewhere in the docs. Thanks to Thomas, and all who replied. I found sources for SWIG 1.1, and built them from scratch. They work fine for me. By the way, I made a minor modification to the sources so that rather than looking in a hard-coded location, followed by the SWIG_LIB environment variable, it looks for the libraries relative to the location of the executable, and then in SWIG_LIB. This makes it easier to package up and move around... I assume a similar thing could be done for the new version, as well... Paul. From fdrake@acm.org Fri Aug 24 13:34:02 2001 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri Aug 24 12:34:02 2001 Subject: [Distutils] Re: [XML-SIG] Problem installing PyXMLv0.6.6 In-Reply-To: <01d601c12cb9$2872ab20$e000a8c0@thomasnotebook> References: <87DAC3BFA900D41199FF00E018A0042F2E7C82@HOBBES> <01d601c12cb9$2872ab20$e000a8c0@thomasnotebook> Message-ID: <15238.33009.608095.827060@grendel.digicool.com> In a message to the XML-SIG, Thomas Heller writes: > From: "G=F6ran Rolfsson" > > Hi! I first tried the exe-version ( I have NT), but it wants me to= select > > the Python installation to use, without showing me any to choose a= mong, and > > without the possibility to specify a path. And yes, I have Python = installed > > on my machine (actually in several versions). >=20 > G=F6ran, >=20 > the exe-version is probably built with distutils bdist_wininst comma= nd. > This looks in the registry under > HKEY_LOCAL_MACHINE\Software\Python\PythonCore\x.y\InstallPath > to find the location where Pythin is installed. (x.y is the required= > version 2.0, 2.1, whatever). > This registry key is created by the installer when you install Pytho= n > itself. If you compiled it from source, it will not be present. Would it make sense to enhance the search strategy a bit? I'll propose the following strawman: 1. Start with what it already does. 2. Search the PATH for "python.exe" 3. Ask the user to specify exactly where is should go. I don't know how much work this would be, but it might help people that do build from source, or who use an alternate installer that doesn't upt things in the registry (PythonWare, for instance). -Fred --=20 Fred L. Drake, Jr. PythonLabs at Zope Corporation From thomas.heller@ion-tof.com Fri Aug 24 15:43:22 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Fri Aug 24 14:43:22 2001 Subject: [Distutils] Re: [XML-SIG] Problem installing PyXMLv0.6.6 References: <87DAC3BFA900D41199FF00E018A0042F2E7C82@HOBBES><01d601c12cb9$2872ab20$e000a8c0@thomasnotebook> <15238.33009.608095.827060@grendel.digicool.com> Message-ID: <033d01c12ccc$72cca7d0$e000a8c0@thomasnotebook> From: "Fred L. Drake, Jr." > > In a message to the XML-SIG, > Thomas Heller writes: > > From: "G=F6ran Rolfsson" > > > Hi! I first tried the exe-version ( I have NT), but it wants me to= select > > > the Python installation to use, without showing me any to choose a= mong, and > > > without the possibility to specify a path. And yes, I have Python = installed > > > on my machine (actually in several versions). > > > > G=F6ran, > > > > the exe-version is probably built with distutils bdist_wininst comma= nd. > > This looks in the registry under > > HKEY_LOCAL_MACHINE\Software\Python\PythonCore\x.y\InstallPath > > to find the location where Pythin is installed. (x.y is the required > > version 2.0, 2.1, whatever). > > This registry key is created by the installer when you install Pytho= n > > itself. If you compiled it from source, it will not be present. > > Would it make sense to enhance the search strategy a bit? I'll > propose the following strawman: > > 1. Start with what it already does. > 2. Search the PATH for "python.exe" > 3. Ask the user to specify exactly where is should go. Actually it's a little more complicated than this. It does not only need the directory where python.exe is found, it must also make sure this is the correct python version. How can you find out from python.exe? > > I don't know how much work this would be, but it might help people > that do build from source, or who use an alternate installer that > doesn't upt things in the registry (PythonWare, for instance). It's strange that nobody has complained so far... Maybe people compiling python from source also compile extensions from source? And everyone else either run ActiveState Python or PythonLabs? Thomas From fdrake@acm.org Fri Aug 24 15:55:00 2001 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri Aug 24 14:55:00 2001 Subject: [Distutils] Re: [XML-SIG] Problem installing PyXMLv0.6.6 In-Reply-To: <033d01c12ccc$72cca7d0$e000a8c0@thomasnotebook> References: <87DAC3BFA900D41199FF00E018A0042F2E7C82@HOBBES> <01d601c12cb9$2872ab20$e000a8c0@thomasnotebook> <15238.33009.608095.827060@grendel.digicool.com> <033d01c12ccc$72cca7d0$e000a8c0@thomasnotebook> Message-ID: <15238.41443.603440.529861@grendel.digicool.com> Thomas Heller writes: > Actually it's a little more complicated than this. > It does not only need the directory where python.exe is found, > it must also make sure this is the correct python version. How > can you find out from python.exe? Good question; I have no idea how to extract that information. > It's strange that nobody has complained so far... > Maybe people compiling python from source also compile > extensions from source? And everyone else either run ActiveState > Python or PythonLabs? Part of it may be that distutils-based installers for Windows are still fairly new, and they're only now being used on enough installation flavors to turn up the more complicated conditions. Or maybe it just doesn't matter. ;-) -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From thomas.heller@ion-tof.com Fri Aug 24 16:03:03 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Fri Aug 24 15:03:03 2001 Subject: [Distutils] Re: [XML-SIG] Problem installing PyXMLv0.6.6 References: <87DAC3BFA900D41199FF00E018A0042F2E7C82@HOBBES><01d601c12cb9$2872ab20$e000a8c0@thomasnotebook><15238.33009.608095.827060@grendel.digicool.com><033d01c12ccc$72cca7d0$e000a8c0@thomasnotebook> <15238.41443.603440.529861@grendel.digicool.com> Message-ID: <03fb01c12ccf$27773220$e000a8c0@thomasnotebook> From: "Fred L. Drake, Jr." > > Thomas Heller writes: > > Actually it's a little more complicated than this. > > It does not only need the directory where python.exe is found, > > it must also make sure this is the correct python version. How > > can you find out from python.exe? > Good question; I have no idea how to extract that information. There is a Windows api to find out which pythonxx.dll python.exe binds to, so it should be possible. Thomas From fdrake@acm.org Fri Aug 24 16:18:01 2001 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri Aug 24 15:18:01 2001 Subject: [Distutils] Re: [XML-SIG] Problem installing PyXMLv0.6.6 In-Reply-To: <03fb01c12ccf$27773220$e000a8c0@thomasnotebook> References: <87DAC3BFA900D41199FF00E018A0042F2E7C82@HOBBES> <01d601c12cb9$2872ab20$e000a8c0@thomasnotebook> <15238.33009.608095.827060@grendel.digicool.com> <033d01c12ccc$72cca7d0$e000a8c0@thomasnotebook> <15238.41443.603440.529861@grendel.digicool.com> <03fb01c12ccf$27773220$e000a8c0@thomasnotebook> Message-ID: <15238.42846.990755.185752@grendel.digicool.com> Thomas Heller writes: > There is a Windows api to find out which pythonxx.dll python.exe > binds to, so it should be possible. Cool! So there is hope for people who build from source but don't or can't build the installer. (Wise was generous in giving us a copy of their current installer builder, but it was only one license.) -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From bh@intevation.de Tue Aug 28 10:21:00 2001 From: bh@intevation.de (Bernhard Herzog) Date: Tue Aug 28 09:21:00 2001 Subject: [Distutils] generate MANIFEST from CVS Message-ID: <6qbsl08goe.fsf@abnoba.intevation.de> Hi all, over the last few weeks, I've been using distutils for the first time on a real and non-trivial project and so far it works fine. I am currently tweaking the MANIFEST.in file to include all the files that have to be distributed and no others. This turns out to be quite time-consuming because there are quite a few files with that aren't included by default. It seems to me that for a project managed by CVS there's a much more convenient way to get at the list of files. Normally, all files controlled by CVS should be distributed. In most cases, that will be enough, but there may some generated files that should be included anyway, such as perhaps swigged wrappers so that he user doesn't have to install SWIG to compile a package. Getting the list of files under CVS control is quite simple, you just extract them from the CVS/Entries files and recurse into subdirectories which are under CVS control. I'm not sure yet how to integrate this with distutils properly. At the moment I think having a cvs command in MANIFEST.in would be best. That way you could add or remove files from the list of CVS controlled files. The one problem I see with that is that when you unpack a source distribution its impossible to generate the list of CVS controlled files again, so another setup.py sdist command won't include all the files. This is easy to work round though, as you can simply distribute a MANIFEST.cvs file containing the CVS filenames which would have to be included in the MANIFEST somehow. The cvs command could do this, too: if run in a directory checked out from CVS, i.e. if CVS/Entries exists, generate the list of CVS-controlled files, write them into MANIFEST.cvs and include them in MANIFEST. If not run in a CVS directory, MANIFEST.cvs must exist and the files listed there are included in MANIFEST. In both cases MANIFEST.cvs will have to be in MANIFEST, too. Thoughts? Bernhard -- Intevation GmbH http://intevation.de/ Sketch http://sketch.sourceforge.net/ MapIt! http://mapit.de/ From R.Liebscher@gmx.de Tue Aug 28 11:00:01 2001 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Tue Aug 28 10:00:01 2001 Subject: [Distutils] generate MANIFEST from CVS References: <6qbsl08goe.fsf@abnoba.intevation.de> Message-ID: <3B8BA340.4820694D@gmx.de> Bernhard Herzog wrote: > > Hi all, > > over the last few weeks, I've been using distutils for the first time on > a real and non-trivial project and so far it works fine. I am currently > tweaking the MANIFEST.in file to include all the files that have to be > distributed and no others. This turns out to be quite time-consuming > because there are quite a few files with that aren't included by > default. > > It seems to me that for a project managed by CVS there's a much more > convenient way to get at the list of files. Normally, all files > controlled by CVS should be distributed. In most cases, that will be > enough, but there may some generated files that should be included > anyway, such as perhaps swigged wrappers so that he user doesn't have to > install SWIG to compile a package. > > Getting the list of files under CVS control is quite simple, you just > extract them from the CVS/Entries files and recurse into subdirectories > which are under CVS control. > > I'm not sure yet how to integrate this with distutils properly. At the > moment I think having a cvs command in MANIFEST.in would be best. That > way you could add or remove files from the list of CVS controlled files. > > The one problem I see with that is that when you unpack a source > distribution its impossible to generate the list of CVS controlled files > again, so another setup.py sdist command won't include all the files. > This is easy to work round though, as you can simply distribute a > MANIFEST.cvs file containing the CVS filenames which would have to be > included in the MANIFEST somehow. > > The cvs command could do this, too: if run in a directory checked out > from CVS, i.e. if CVS/Entries exists, generate the list of > CVS-controlled files, write them into MANIFEST.cvs and include them in > MANIFEST. If not run in a CVS directory, MANIFEST.cvs must exist and the > files listed there are included in MANIFEST. In both cases MANIFEST.cvs > will have to be in MANIFEST, too. > > Thoughts? > > Bernhard > It is not necessary to add such a MANIFEST.cvs file. If you are start creating a file which contains filenames, you could also write a complete MANIFEST file. (So you don't need a MANIFEST.in file.) If a MANIFEST file contains its own name, it is also included in the source distribution. (People who want to run another sdist on this unpacked distribution would use this file. Except there is a newer MANIFEST.in file.) Rene From bh@intevation.de Tue Aug 28 11:27:02 2001 From: bh@intevation.de (Bernhard Herzog) Date: Tue Aug 28 10:27:02 2001 Subject: [Distutils] generate MANIFEST from CVS In-Reply-To: <3B8BA340.4820694D@gmx.de> References: <6qbsl08goe.fsf@abnoba.intevation.de> <3B8BA340.4820694D@gmx.de> Message-ID: <6q7kvo8dmy.fsf@abnoba.intevation.de> Rene Liebscher writes: > Bernhard Herzog wrote: > > > > The cvs command could do this, too: if run in a directory checked out > > from CVS, i.e. if CVS/Entries exists, generate the list of > > CVS-controlled files, write them into MANIFEST.cvs and include them in > > MANIFEST. If not run in a CVS directory, MANIFEST.cvs must exist and the > > files listed there are included in MANIFEST. In both cases MANIFEST.cvs > > will have to be in MANIFEST, too. > > > > Thoughts? > > > > Bernhard > > > It is not necessary to add such a MANIFEST.cvs file. If you are start > creating a file which contains filenames, you could also write a > complete > MANIFEST file. (So you don't need a MANIFEST.in file.) Well, the reason I think it might be useful to have the MANIFEST.cvs in addition to the MANIFEST.in is that it may be useful to autogenerate part of MANIFEST from CVS and add or remove some specific files. If I generate MANIFEST directly I'll have to create my own mechanisms for this sort of thing and lose some of the automatism distutils provides. > If a MANIFEST file contains its own name, it is also included > in the source distribution. (People who want to run another sdist on > this unpacked distribution would use this file. Except there is a > newer MANIFEST.in file.) Ok. That's a solution to that part of the problem. I think for a start I'll write my own sdist command as an extension of the standard sdist that simply builds the MANIFEST file and then calls the base-class' run method. Thanks, Bernhard -- Intevation GmbH http://intevation.de/ Sketch http://sketch.sourceforge.net/ MapIt! http://mapit.de/ From bh@intevation.de Tue Aug 28 15:08:14 2001 From: bh@intevation.de (Bernhard Herzog) Date: Tue Aug 28 14:08:14 2001 Subject: [Distutils] bdist_inno again Message-ID: <6qd75g6oud.fsf@abnoba.intevation.de> Hi all, a bdist_inno command to generate an installer with Inno Setup has been discussed previously but I don't know whether anybody has done anything about it. Has anything changed in this regard? Has anybody started to write it? I'll start writing it myself, otherwise. I don't know how general it will be, though. All I really need at the moment is an implementation that's good enough for my needs. Bernhard -- Intevation GmbH http://intevation.de/ Sketch http://sketch.sourceforge.net/ MapIt! http://mapit.de/ From dubois@users.sourceforge.net Thu Aug 30 13:03:02 2001 From: dubois@users.sourceforge.net (Paul F. Dubois) Date: Thu Aug 30 12:03:02 2001 Subject: [Distutils] first cut at fortran support for distutils In-Reply-To: <002101c129da$f167de10$ec88fea9@ericlaptop> Message-ID: <000001c1316d$137deaa0$0301a8c0@plstn1.sfba.home.com> The concern I have is that Fortran is not in the same boat here that C is. C compilations can get their command-line arguments by default at least by using the settings that Python was compiled with, and that was determined by a configuration process. For Fortran, there is no such crutch so any new compiler will have to be added to distutils by hand. And Fortran users are much more likely IMHO to want to fool around with the flags. The approach I took in Pyfort was to assume that the USER could make the static library. That reduces the question to (a) getting the right run-time modules linked and (b) writing a wrapper so the functions can be called from Fortran. But (a) actually depends on the compiler flags used, and of course (b) has to be done some way or the other, either by hand or with a tool. Pyfort therefore uses distutils to do the link and by default includes the basic libraries into the libdir and dirlist lists, and the user can then add to that via the Pyfort command line. So I didn't need any changes to distutils itself, I just used it from my Python. -----Original Message----- From: distutils-sig-admin@python.org [mailto:distutils-sig-admin@python.org] On Behalf Of eric jones Sent: Monday, August 20, 2001 5:48 PM To: distutils-sig@python.org Cc: oliphant.travis@ieee.org Subject: [Distutils] first cut at fortran support for distutils Travis Oliphant and I have hacked together Fortran support for distutils in the course of putting together scipy (www.scipy.org). I won't pretend its pretty, but it does seem to do the job on Linux and W2000/W98 using the mingw32 version of gcc/g77. We're also working on Sun and Irix. Basically, the static_clib has been modified to build static libraries of the fortran code that are then linked with the extension module interface (written in C). We'd like to work toward this becoming a standard part of distutils. Are others interested in this? Also, opinions on how to best pursue its inclusion are welcomed. If your interested, please grab the source version of scipy from the site and take a look at fortran_support.py, build_flib.py, build_clib_new.py, and setup.py. thanks, eric _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig From Pearu Peterson Fri Aug 31 14:03:01 2001 From: Pearu Peterson (Pearu Peterson) Date: Fri Aug 31 13:03:01 2001 Subject: [Distutils] first cut at fortran support for distutils In-Reply-To: <000001c1316d$137deaa0$0301a8c0@plstn1.sfba.home.com> Message-ID: Hi, I completely agree with Paul's concerns below but I don't think that nothing should be done in this matter. Playing with compiler flags is rare (you can find optimal flag configuration once, later may be change it a bit) relative to the actual compilation of Fortran programs that are developed in connection with Python (here talking based on my experience). So, it would be very useful if Fortran codes could be compiled within setup.py. And more importantly, one could crab, say from Internet, a Python package containing Fortran codes and build it from scratch (rather than messing with Makefiles that are platform dependent even on unices). Here assuming that support for Fortran compilers is set up properly locally - this is not a problem on unices, don't know about windows. So, I think that that the work of Eric and Travis is relevant and very useful. Regards, Pearu On Thu, 30 Aug 2001, Paul F. Dubois wrote: > The concern I have is that Fortran is not in the same boat here that C > is. C compilations can get their command-line arguments by default at > least by using the settings that Python was compiled with, and that was > determined by a configuration process. > > For Fortran, there is no such crutch so any new compiler will have to be > added to distutils by hand. And Fortran users are much more likely IMHO > to want to fool around with the flags. > > The approach I took in Pyfort was to assume that the USER could make the > static library. That reduces the question to (a) getting the right > run-time modules linked and (b) writing a wrapper so the functions can > be called from Fortran. > > But (a) actually depends on the compiler flags used, and of course (b) > has to be done some way or the other, either by hand or with a tool. > > Pyfort therefore uses distutils to do the link and by default includes > the basic libraries into the libdir and dirlist lists, and the user can > then add to that via the Pyfort command line. So I didn't need any > changes to distutils itself, I just used it from my Python. >