From michel.vandenbergh@luc.ac.be Mon Jan 1 21:06:04 2001 From: michel.vandenbergh@luc.ac.be (Michel Van den Bergh) Date: Mon Jan 1 21:06:04 2001 Subject: [Distutils] SWIG+distutils+Windows??? Message-ID: <3A513786.2E9FE780@luc.ac.be> Hi I am trying to generate an extension module using distutils on windows. I am using the plain vanilla command python setup.py build_ext -ccygwin (the corresponding command without the -ccygwin works fine on Linux). The source for the extension module was generated by SWIG on Linux (as I don't have SWIG on windows). Compiling seems to go fine but then I get a bunch of undefined symbols: Cannot export init_hintmodule: symbol not defined build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0x165):hint_wrap.c: undefined reference to `_imp__PyExc_NameError' build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0x1f1):hint_wrap.c: undefined reference to `_imp__PyExc_NameError' build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0x230):hint_wrap.c: undefined reference to `_imp__PyType_Type' build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0x9e2):hint_wrap.c: undefined reference to `_imp___Py_NoneStruct' build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0x9e9):hint_wrap.c: undefined reference to `_imp___Py_NoneStruct' build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0xa22):hint_wrap.c: undefined reference to `_imp___Py_NoneStruct' build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0xa29):hint_wrap.c: undefined reference to `_imp___Py_NoneStruct' build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0xa99):hint_wrap.c: undefined reference to `_imp__PyExc_TypeError' build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0xb3d):hint_wrap.c: undefined reference to `_imp__PyExc_TypeError' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 I have no idea what the problem is here. Is there anybody than can help? I suspect this must be trivial for a knowledgeable person. The version numbers are as follows: gcc 2.95.2 ld 2.10.90 dllwrap 2.10.90 Best regards. Michel ====================================== Linux: the choice of a GNU generation. From michel.vandenbergh@luc.ac.be Wed Jan 3 13:57:01 2001 From: michel.vandenbergh@luc.ac.be (Michel Van den Bergh) Date: Wed Jan 3 13:57:01 2001 Subject: [Distutils] SWIG+distutils+Windows??? References: Message-ID: <3A5375D7.C8518403@luc.ac.be> "John J. Lee" wrote: > > On Tue, 2 Jan 2001, Michel Van den Bergh wrote: > [...] > > Compiling seems to go fine but then I get a bunch of undefined symbols: > [...] > > Do you have a libpython20.so? > > John Hello, I am having problems on Windows (on Linux everything works without a hitch). I do have python20.dll as well as python20.lib (which is the import library I presume). The strange thing is that the symbols that the linker is missing on Windows are also the ones which are undefined in Linux (I checked with nm). So this seems to be normal. Unfortunately under Windows the linker views it as an error. This must have something to do with the peculiar nature of the dll file format. I would really like to solve this problem. I tried to compile manually but I always get the same error. Do you know anybody who is knowledgeable in cygwin? Regards, Michel From michel.vandenbergh@luc.ac.be Wed Jan 3 16:28:03 2001 From: michel.vandenbergh@luc.ac.be (Michel Van den Bergh) Date: Wed Jan 3 16:28:03 2001 Subject: [Distutils] SWIG+distutils+Windows??? References: <000c01c075b9$9efdb300$e436ba8c@nhv> Message-ID: <3A53995F.9D57235E@luc.ac.be> Norman Vine wrote: > > Michel Van den Bergh writes: > > > > > >Hi I am trying to generate an extension module using distutils on windows. > >I am using the plain vanilla command > > > >python setup.py build_ext -ccygwin > > > >(the corresponding command without the -ccygwin works fine on Linux). > > > >The source for the extension module was generated by SWIG on > >Linux (as I don't have SWIG on windows). > > FWIW SWIG compiles OTB with Cygwin > > Are you building this against a Cygwin compiled python > > if so you probably need to add > -DUSE_DLL_IMPORT to the gcc flags > > Norman Thanks for the suggestion, but I am just using the vanilla ActiveState Python2.0. I tried to add USE_DLL_IMPORT to the gcc flags anyway but it didn't make any difference. The same symbols remain undefined. I really don't understand what goes on here. These symbols are referenced in Python.h and descendants as externals but they don't seem to be in python20.lib (I checked with nm). I also tried SWIG on Windows but that didn't help either (I didn't think it would). Regards, Michel From michel.vandenbergh@luc.ac.be Wed Jan 3 17:09:02 2001 From: michel.vandenbergh@luc.ac.be (Michel Van den Bergh) Date: Wed Jan 3 17:09:02 2001 Subject: [Distutils] SWIG+distutils+Windows??? References: <000601c075ce$9f2e5360$3937ba8c@nhv> Message-ID: <3A53A2E4.2B87354B@luc.ac.be> Norman Vine wrote: > > Michel Van den Bergh writes: > >>> > >> Norman > >Thanks for the suggestion, but I am just using the vanilla ActiveState > >Python2.0. > >I tried to add USE_DLL_IMPORT to the gcc flags anyway but it > >didn't make > >any difference. The same symbols remain undefined. I really don't > >understand what goes on here. These symbols are referenced in Python.h > >and descendants as externals but they don't seem to be in python20.lib > >(I checked with nm). > >I also tried SWIG on Windows but that didn't help either (I > >didn't think it would). > > I do not think you will have much luck compiling against a non-cygwin > python with Cygwin unless you are using the --no-cygwin switch > > FWIW > These undefined symbols are coming from PY_SRC / include / object.h > > Python compiles fine as a dll with this patch > http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 > > I haven't tried to get this working with Distutils > > Also when using the Cygwin compiler and embedding python > I had to add the -DUSE_DLL_IMPORT flag when using a cygwin > compiled python in dll form. I did not need this flag with a static > library. Again this is all using the above patch and a recent Cygwin > > Sorry I can not be of more help > > Norman Thanks anyway! Michel From R.Liebscher@gmx.de Thu Jan 4 03:57:00 2001 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Thu Jan 4 03:57:00 2001 Subject: [Distutils] SWIG+distutils+Windows??? References: <3A513786.2E9FE780@luc.ac.be> Message-ID: <3A543A0C.7A11438B@gmx.de> Michel Van den Bergh wrote: > > Hi I am trying to generate an extension module using distutils on > windows. > I am using the plain vanilla command > > python setup.py build_ext -ccygwin > > (the corresponding command without the -ccygwin works fine on Linux). > > The source for the extension module was generated by SWIG on Linux (as I > don't have > SWIG on windows). > > Compiling seems to go fine but then I get a bunch of undefined symbols: > > Cannot export init_hintmodule: symbol not defined > build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0x165):hint_wrap.c: > undefined reference to `_imp__PyExc_NameError' > build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0x1f1):hint_wrap.c: > undefined reference to `_imp__PyExc_NameError' > build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0x230):hint_wrap.c: > undefined reference to `_imp__PyType_Type' > build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0x9e2):hint_wrap.c: > undefined reference to `_imp___Py_NoneStruct' > build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0x9e9):hint_wrap.c: > undefined reference to `_imp___Py_NoneStruct' > build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0xa22):hint_wrap.c: > undefined reference to `_imp___Py_NoneStruct' > build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0xa29):hint_wrap.c: > undefined reference to `_imp___Py_NoneStruct' > build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0xa99):hint_wrap.c: > undefined reference to `_imp__PyExc_TypeError' > build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0xb3d):hint_wrap.c: > undefined reference to `_imp__PyExc_TypeError' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > I have no idea what the problem is here. Is there anybody than can help? > I suspect this must be trivial for a knowledgeable person. > > The version numbers are as follows: > gcc 2.95.2 > ld 2.10.90 > dllwrap 2.10.90 > I think the main problem is you are not using a special import library for cygwin. All missing symbols are data stuctures. Cygwin can obviously read only text (=code) information from foreign library formats. So you have to build a special import library for cygwin. 1. create a def-file for python20.dll with all symbols (also the data symbols) You can find this def-file also at http://www.informatik.htw-dresden.de/~liebschr/distutils-cygwin/python20.def is was created with Pexports see also http://starship.python.net/crew/kernr/mingw32/Notes.html 2. create a import library dlltool --dllname python20.dll --def python20.def --output-lib libpython20.a 3. place this file libpython20.a in your libs directory to the other import library (Cygwinccompiler from distutils will choose the right one.) If you call 'nm libpython20.a' you should get a list of all symbols in it. There you find entries like this: ds00510.o: 00000000 b .bss 00000000 d .data 00000000 i .idata$4 00000000 i .idata$5 00000000 i .idata$6 00000000 i .idata$7 00000000 t .text 00000000 T _Py_SetPythonHome <============ U __head_libpython20_a 00000000 I __imp__Py_SetPythonHome These are normal function calls (it has a line ?????? T _function_name) And you find entries like this: ds00560.o: 00000000 b .bss 00000000 d .data 00000000 i .idata$4 00000000 i .idata$5 00000000 i .idata$6 00000000 i .idata$7 00000000 t .text U __head_libpython20_a 00000000 I __imp___Py_NoneStruct These are data structures (without this T line.) I hope these hints help you. Kind regards Rene Liebscher From R.Liebscher@gmx.de Thu Jan 4 04:15:01 2001 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Thu Jan 4 04:15:01 2001 Subject: [Distutils] installer does not see current Pythons References: <3A49C4D4.270F8A2B@gmx.de> Message-ID: <3A543CF9.CC7276EA@gmx.de> Rene Liebscher wrote: > > Any ideas how to solve this, or needs this for > some users a special distribution as zip-file. > > > Support Request #110549, was updated on 2000-Dec-22 17:22 > > You can respond by visiting: > > http://sourceforge.net/support/?func=detailsupport&support_id=110549&group_id=5988 > > > > Category: None > > Status: Open > > Priority: 5 > > Summary: installer does not see current Pythons > > > > By: fredy > > Date: 2000-Dec-22 17:22 > > > > Message: > > Logged In: YES > > user_id=20580 > > Browser: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0) > > > > I downloaded PyOpenGL-1.5.6b1.win32-py1.5.2.exe and > > executed it on my Windows NT 4.0 machine. When the > > installer displays the "select python installation to > > use" screen it fails to list anything and I am > > blocked, even though I have both Python 1.5.2 and 1.6 > > installed, along with whatever Python comes with Zope > > 2.2. What can I do now to install PyOpenGL? > > > Meanwhile I found out what is wrong. The Windows installers relies on two registry entries, but if Python is not correctly installed in the registry it is not found. To add these registry entries write the following code in a file (reg.py): ########################################################## # these entries are necessary for the distutils-Windows-installer reg_data = """REGEDIT4 [HKEY_LOCAL_MACHINE\Software\Python] [HKEY_LOCAL_MACHINE\Software\Python\PythonCore] [HKEY_LOCAL_MACHINE\Software\Python\PythonCore\$VERSION] [HKEY_LOCAL_MACHINE\Software\Python\PythonCore\$VERSION\InstallPath] @="$PYTHON" """ import sys,string reg_data = string.replace(reg_data,"$VERSION",sys.version[0:3]) reg_data = string.replace(reg_data,"$PYTHON",string.replace(sys.prefix,"\\","\\\\")) print reg_data ########################################################## Then call it with 'python reg.py >python.reg' and double click on python.reg. This will install the registry entries necessary for the Windows installer. (You can also import this file with regedit or type 'start python.reg' at the command line.) !!! It doesn't install all registry entries which are usually made by Python, but it should be enough to get distutils windows installer to work. Kind regards Rene Liebscher From michel.vandenbergh@luc.ac.be Thu Jan 4 05:33:01 2001 From: michel.vandenbergh@luc.ac.be (Michel Van den Bergh) Date: Thu Jan 4 05:33:01 2001 Subject: [Distutils] SWIG+distutils+Windows??? References: <3A513786.2E9FE780@luc.ac.be> <3A543A0C.7A11438B@gmx.de> Message-ID: <3A545142.3C9464B8@luc.ac.be> Ok, Thanks for everybody's help and especially for the tips contained in the post below. I managed to make my extension! In the end it was easy! I did the following. (1) I downloaded the .def file mentioned in the post below. (2) I made the cygwin/mingw compatible import library using the procedure mentioned in the post below (I don't understand why this import library isn't part of the standard Python distribution! I guess many people who only use windows occasionally will use cygwing/mingw since it is free.) (3) I used python setup.py build_ext -cmingw32 Before I had used -ccygwin. This compiled but produced an unloadable library. Of course you need to download the mingw compiler. I used the crtdll version. Afterwards I read that it had been better to use the msvcrt version. (4) The command in (3) gave some errors since mingw32 does not seem to support all posix functions. I fixed this and then everything compiled and linked smoothly. (5) Now I had a library which loaded fine. However when I accessed global c variables in python (SWIG makes these visible) then I got a horrible crash. The solution was simply to write accessor functions for these global variables (shouldn't have used global variables anyway:-). Maybe this problem would not have occurred with the msvcrt version of the compiler. I don't know. It would be nice to put this procedure in a FAQ somewhere. Best regards, Michel ===================================== Linux: the choice of a GNU generation Rene Liebscher wrote: > > Michel Van den Bergh wrote: > > > > Hi I am trying to generate an extension module using distutils on > > windows. > > I am using the plain vanilla command > > > > python setup.py build_ext -ccygwin > > > > (the corresponding command without the -ccygwin works fine on Linux). > > > > The source for the extension module was generated by SWIG on Linux (as I > > don't have > > SWIG on windows). > > > > Compiling seems to go fine but then I get a bunch of undefined symbols: > > > > Cannot export init_hintmodule: symbol not defined > > build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0x165):hint_wrap.c: > > undefined reference to `_imp__PyExc_NameError' > > build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0x1f1):hint_wrap.c: > > undefined reference to `_imp__PyExc_NameError' > > build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0x230):hint_wrap.c: > > undefined reference to `_imp__PyType_Type' > > build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0x9e2):hint_wrap.c: > > undefined reference to `_imp___Py_NoneStruct' > > build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0x9e9):hint_wrap.c: > > undefined reference to `_imp___Py_NoneStruct' > > build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0xa22):hint_wrap.c: > > undefined reference to `_imp___Py_NoneStruct' > > build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0xa29):hint_wrap.c: > > undefined reference to `_imp___Py_NoneStruct' > > build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0xa99):hint_wrap.c: > > undefined reference to `_imp__PyExc_TypeError' > > build\temp.win32-2.0\Release\gtlevel\src\hint_wrap.o(.text+0xb3d):hint_wrap.c: > > undefined reference to `_imp__PyExc_TypeError' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > I have no idea what the problem is here. Is there anybody than can help? > > I suspect this must be trivial for a knowledgeable person. > > > > The version numbers are as follows: > > gcc 2.95.2 > > ld 2.10.90 > > dllwrap 2.10.90 > > > I think the main problem is you are not using a special import library > for cygwin. > All missing symbols are data stuctures. > Cygwin can obviously read only text (=code) information from foreign > library formats. > > So you have to build a special import library for cygwin. > > 1. create a def-file for python20.dll with all symbols (also the data > symbols) > You can find this def-file also at > http://www.informatik.htw-dresden.de/~liebschr/distutils-cygwin/python20.def > is was created with Pexports see also > http://starship.python.net/crew/kernr/mingw32/Notes.html > > 2. create a import library > dlltool --dllname python20.dll --def python20.def --output-lib > libpython20.a > > 3. place this file libpython20.a in your libs directory to the other > import library (Cygwinccompiler from distutils will choose the right > one.) > > If you call 'nm libpython20.a' you should get a list of all symbols in > it. > There you find entries like this: > ds00510.o: > 00000000 b .bss > 00000000 d .data > 00000000 i .idata$4 > 00000000 i .idata$5 > 00000000 i .idata$6 > 00000000 i .idata$7 > 00000000 t .text > 00000000 T _Py_SetPythonHome <============ > U __head_libpython20_a > 00000000 I __imp__Py_SetPythonHome > > These are normal function calls (it has a line ?????? T _function_name) > > And you find entries like this: > ds00560.o: > 00000000 b .bss > 00000000 d .data > 00000000 i .idata$4 > 00000000 i .idata$5 > 00000000 i .idata$6 > 00000000 i .idata$7 > 00000000 t .text > U __head_libpython20_a > 00000000 I __imp___Py_NoneStruct > > These are data structures (without this T line.) > > I hope these hints help you. > > Kind regards > > Rene Liebscher From vdbergh@luc.ac.be Thu Jan 4 07:14:01 2001 From: vdbergh@luc.ac.be (Michel Van den Bergh) Date: Thu Jan 4 07:14:01 2001 Subject: [Distutils] Platform specific defaults for config options. Message-ID: <3A5468E1.DAE06F55@luc.ac.be> Hello, After the extremely useful replies I got to my last question here is another one! Is is possible to set defaults for command line options in setup.py? I would like to put in some PLATFORM-SPECIFIC defaults. E.g, choice of compiler, installation directory. The limited format of config.cfg does not seem to allow this. Thanks, Michel From vdbergh@luc.ac.be Thu Jan 4 08:26:19 2001 From: vdbergh@luc.ac.be (Michel Van den Bergh) Date: Thu Jan 4 08:26:19 2001 Subject: [Distutils] SWIG+distutils+Windows??? References: <3A513786.2E9FE780@luc.ac.be> <3A543A0C.7A11438B@gmx.de> Message-ID: <3A5479B3.522F351C@luc.ac.be> Hello, I came across a buglet in bdist_rpm. There seems to be no way to specify "data-directories" in setup.py. As a result the directories that are created when installing the generated rpm are not deleted on uninstall. Hmmm..... Regards, MIchel From vdbergh@luc.ac.be Thu Jan 4 10:19:01 2001 From: vdbergh@luc.ac.be (Michel Van den Bergh) Date: Thu Jan 4 10:19:01 2001 Subject: [Distutils] Platform specific defaults for config options. References: <3A5468E1.DAE06F55@luc.ac.be> <3A547142.FFF878C0@gmx.de> Message-ID: <3A549452.D1B34DB9@luc.ac.be> Rene Liebscher wrote: > Michel Van den Bergh wrote: > > > > Hello, > > > > After the extremely useful replies I got to my last question here is > > another one! > > > > Is is possible to set defaults for command line options in setup.py? > > > > I would like to put in some PLATFORM-SPECIFIC defaults. E.g, choice > > of compiler, installation directory. > > > > The limited format of config.cfg does not seem to allow this. > > > You probably have to overwrite the Distribution class. > (you can find it in distutils/dist.py) > > You could set your options right in self.__init__() or so, > see also self.command_options > and self.parse_config_files(). > > See also > http://mail.python.org/pipermail/distutils-sig/1999-January/000143.html > You have write then your setup like this: > ------------------------------------------------------------------------ > from distutils.core import Distribution, setup > > class MyDistribution (Distribution): > def __init__(self): > Distribution.__init__(self) > # put your initialization here > > setup (distclass = MyDistribution) > ------------------------------------------------------------------------ > > BTW, I have never extended the Distribution class, so I can't > guarantee it is correct. > > Kind regards > Rene Liebscher Thanks, Using your idea I could inspect the mechanics of distutils a little better. Then I found out that setup has an option 'options' (undocumented as far as I can tell) which allows you to give default values for options. So it is actually pretty easy. It think it would be better to have config files of the form : setup_osname. This would be more transparent. Regards, Michel From phrxy@csv.warwick.ac.uk Thu Jan 4 13:53:01 2001 From: phrxy@csv.warwick.ac.uk (John J. Lee) Date: Thu Jan 4 13:53:01 2001 Subject: [Distutils] SWIG+distutils+Windows??? In-Reply-To: <3A545142.3C9464B8@luc.ac.be> Message-ID: First: Michel, can you please NOT post private emails such as the one I sent you to public newsgroups / lists. In this case I merely wanted to avoid filling up this list with my answer which I pretty sure wasn't quite correct in some way or other (I should have said libpython20.a rather than .so in fact). But generally, posting private emails to newsgroups or mailing lists is bad manners because there is usually a reason why the person did not publicly post it. I'm still a bit vague about all this machinery, but anyway: On Thu, 4 Jan 2001, Michel Van den Bergh wrote: > Ok, Thanks for everybody's help and especially for the tips contained in > the post below. I managed to make my extension! In the end it was easy! > > I did the following. [...] > (3) I used > python setup.py build_ext -cmingw32 > > Before I had used -ccygwin. This compiled but produced an unloadable > library. Of course you need to download the mingw compiler. I used the > crtdll version. Afterwards I read that it had been better to use the > msvcrt version. You don't need to download mingw, cygwin will compile it without linking to cygwin1.dll -- Distutils tells cygwin to do this (presumably) by passing the -mno-cygwin option. > (4) The command in (3) gave some errors since mingw32 does not seem to > support all posix functions. I fixed this and then everything compiled > and linked smoothly. If you want posix things, use -c cygwin and make sure cygwin1.dll is available (freely available, of course). John From phrxy@csv.warwick.ac.uk Thu Jan 4 13:55:01 2001 From: phrxy@csv.warwick.ac.uk (John J. Lee) Date: Thu Jan 4 13:55:01 2001 Subject: [Distutils] SWIG+distutils+Windows??? In-Reply-To: <3A5479B3.522F351C@luc.ac.be> Message-ID: On Thu, 4 Jan 2001, Michel Van den Bergh wrote: > Hello, > > I came across a buglet in bdist_rpm. There seems to be no way > to specify "data-directories" in setup.py. As a result the directories that > are created when installing the generated rpm are not deleted on uninstall. > > Hmmm..... I think this is answered in the distutils manual, such as it is. At least it mentions something about where to put information for rpm. John From Jason.Tishler@dothill.com Thu Jan 4 15:48:01 2001 From: Jason.Tishler@dothill.com (Jason Tishler) Date: Thu Jan 4 15:48:01 2001 Subject: [Distutils] SWIG+distutils+Windows??? In-Reply-To: ; from phrxy@csv.warwick.ac.uk on Thu, Jan 04, 2001 at 06:52:18PM +0000 References: <3A545142.3C9464B8@luc.ac.be> Message-ID: <20010104154659.C655@dothill.com> On Thu, Jan 04, 2001 at 06:52:18PM +0000, John J. Lee wrote: > You don't need to download mingw, cygwin will compile it without linking > to cygwin1.dll -- Distutils tells cygwin to do this (presumably) by > passing the -mno-cygwin option. Unfortunately, the current Cygwin gcc with -mno-cygwin produces executables that are bound to crtdll.dll and *not* msvcrt.dll. This behavior will be changed in a new Cygwin gcc version. But, until then, I think that the mingw msvcrt version is the way to go for straight Win32 Python. Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corp. Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com From paulp@ActiveState.com Thu Jan 4 20:23:01 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Thu Jan 4 20:23:01 2001 Subject: [Distutils] Multi-distribution distributions Message-ID: <3A5521BE.1E8DF72@ActiveState.com> I'm somewhat surprised by the fact that some distributions (e.g. Numpy, Zodb) have multiple setup.py programs. As far as I know, these setup.py's do not share information so there is no way to do a bdist_wininst or bdist_rpm that builds a single distribution for these multiple sub-packages. I see this as a fairly large problem! The bdist_ functions are an important part of Distutils functionality. Paul Prescod From Jason.Tishler@dothill.com Thu Jan 4 22:17:00 2001 From: Jason.Tishler@dothill.com (Jason Tishler) Date: Thu Jan 4 22:17:00 2001 Subject: [Distutils] Creating Shared Extensions with Cygwin DLL Python and Distutils Message-ID: <20010104222111.A102@dothill.com> --s1GkIU9aaogUa0PY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cygwin DLL Python and Distutils work very well together to create shared extensions. Note that these extensions will only work with Cygwin DLL Python. They will not work with Win32 Python or Cygwin Python. However, this combination should facilitate UNIX shared extension providers with the porting of their modules to Windows. Cygwin DLL Python is a version of Cygwin Python with its core built as a DLL similar to Win32 Python. One can easy build Cygwin DLL Python by using the patches and instructions found at: http://cygwin.com/ml/cygwin/2000-11/msg00471.html and http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 for Python 2.0 and Python CVS, respectively. For a simple example see the first attachment. This is the setup.py that corresponds to the Demo/extend example found in the standard Python distribution. For a more realistic example see the second attachment. This is the setup.py that builds the python-ldap module: http://sourceforge.net/projects/python-ldap For the above to build, configure must have already been run and the attached patch (i.e., third attachment) applied. Note that this patch is just the same one necessary for the traditional Makefile.pre.in style build under Cygwin. Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corporation Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com --s1GkIU9aaogUa0PY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="setup.py" from distutils.core import setup, Extension setup( name = "xx", version = "1.0", ext_modules = [ Extension("xx", ["xxmodule.c"], define_macros=[('USE_DL_IMPORT', None)], library_dirs=["/usr/local/lib/python2.0/config"], libraries=["python2.0"])]) --s1GkIU9aaogUa0PY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="setup.py" from distutils.core import setup, Extension setup( name = "ldap", version = "1.10alpha3", ext_modules = [ Extension( "_ldap", ["CIDict.c", "LDAPObject.c", "common.c", "constants.c", "errors.c", "functions.c", "ldapmodule.c", "linkedlist.c", "message.c", "template.c", "version.c"], define_macros=[('USE_DL_IMPORT', None), ('HAVE_CONFIG_H', None), ('LDAP_REFERRALS', None)], library_dirs=["/usr/local/lib", "/usr/local/lib/python2.0/config"], libraries=["ldap", "lber", "python2.0"])]) --s1GkIU9aaogUa0PY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="Cygwin-python-ldap-1.10alpha3.patch" diff -upr python-ldap-1.10alpha3.orig/Modules/LDAPObject.c python-ldap-1.10alpha3/Modules/LDAPObject.c --- python-ldap-1.10alpha3.orig/Modules/LDAPObject.c Mon Aug 14 18:37:37 2000 +++ python-ldap-1.10alpha3/Modules/LDAPObject.c Mon Oct 30 09:22:44 2000 @@ -1789,7 +1789,7 @@ setattr( LDAPObject* self, char* name, P /* type entry */ PyTypeObject LDAP_Type = { -#ifdef WIN32 +#if defined(WIN32) || defined(__CYGWIN__) /* see http://www.python.org/doc/FAQ.html#3.24 */ PyObject_HEAD_INIT(NULL) #else /* ! WIN32 */ diff -upr python-ldap-1.10alpha3.orig/Modules/ldapmodule.c python-ldap-1.10alpha3/Modules/ldapmodule.c --- python-ldap-1.10alpha3.orig/Modules/ldapmodule.c Thu Jul 27 12:08:58 2000 +++ python-ldap-1.10alpha3/Modules/ldapmodule.c Mon Oct 30 09:35:15 2000 @@ -22,12 +22,12 @@ static PyMethodDef methods[] = { /* module initialisation */ -void +DL_EXPORT(void) init_ldap() { PyObject *m, *d; -#ifdef WIN32 +#if defined(WIN32) || defined(__CYGWIN__) /* See http://www.python.org/doc/FAQ.html#3.24 */ LDAP_Type.ob_type = &PyType_Type; #endif diff -upr python-ldap-1.10alpha3.orig/Modules/linkedlist.c python-ldap-1.10alpha3/Modules/linkedlist.c --- python-ldap-1.10alpha3.orig/Modules/linkedlist.c Sun Aug 13 11:03:25 2000 +++ python-ldap-1.10alpha3/Modules/linkedlist.c Mon Oct 30 09:23:23 2000 @@ -111,7 +111,7 @@ static PySequenceMethods default_methods }; static PyTypeObject default_type = { -#ifdef WIN32 +#if defined(WIN32) || defined(__CYGWIN__) /* see http://www.python.org/doc/FAQ.html#3.24 */ PyObject_HEAD_INIT(NULL) #else /* ! WIN32 */ diff -upr python-ldap-1.10alpha3.orig/Modules/template.c python-ldap-1.10alpha3/Modules/template.c --- python-ldap-1.10alpha3.orig/Modules/template.c Sun Aug 13 10:57:52 2000 +++ python-ldap-1.10alpha3/Modules/template.c Mon Oct 30 09:31:49 2000 @@ -548,7 +548,7 @@ TemplateItem_setattr(self, attr, value) } static PyTypeObject TemplateItem_Type = { -#ifdef WIN32 +#if defined(WIN32) || defined(__CYGWIN__) PyObject_HEAD_INIT(NULL) #else /* ! WIN32 */ PyObject_HEAD_INIT(&PyType_Type) @@ -725,7 +725,7 @@ fprintf(stderr, "TemplateDefault_repr RE } static PyTypeObject TemplateDefault_Type = { -#ifdef WIN32 +#if defined(WIN32) || defined(__CYGWIN__) PyObject_HEAD_INIT(NULL) #else /* ! WIN32 */ PyObject_HEAD_INIT(&PyType_Type) @@ -908,7 +908,7 @@ Template_setattr(self, attr, value) } static PyTypeObject Template_Type = { -#ifdef WIN32 +#if defined(WIN32) || defined(__CYGWIN__) PyObject_HEAD_INIT(NULL) #else /* ! WIN32 */ PyObject_HEAD_INIT(&PyType_Type) --s1GkIU9aaogUa0PY-- From dubois@users.sourceforge.net Fri Jan 5 00:32:01 2001 From: dubois@users.sourceforge.net (Paul F. Dubois) Date: Fri Jan 5 00:32:01 2001 Subject: [Distutils] RE: [Numpy-discussion] Multi-distribution distributions In-Reply-To: <3A5521BE.1E8DF72@ActiveState.com> Message-ID: Explanation: we made these packages optional partly because they ought to be optional but partly because one of them depends on LAPACK and many people wish to configure the packages to use a different LAPACK than the limited "lite" one supplied. It would be correct in the spirit of SourceForge and Python packages to make every single one of these optional packages a separate "project" or at least a separate download. That would raise the overhead. Technically the manual should be split up into pieces too. I don't think all that trouble is worth undergoing in order to "solve" this problem. So, you could just build separate rpms for each of the optional packages. They are NOT subpackages in the true sense of the word, except that a couple of them install into Numeric's directory for backward compatibility. Numeric is not a true package either. Again, people have argued (and I agree) that purity of thought is trumped by backward compatibility and that we should leave well enough alone. You are welcome to add a script which runs the bdist functions on all the optional packages, in much the same way setup_all.py works. You do need to face the issue if making a bdist for the public of which LAPACK you use on which platform. I believe I was one of the earliest and hardest pushers for Distutils, so I have no trouble agreeing with your goals. -----Original Message----- From: numpy-discussion-admin@lists.sourceforge.net [mailto:numpy-discussion-admin@lists.sourceforge.net]On Behalf Of Paul Prescod Sent: Thursday, January 04, 2001 5:22 PM To: distutils-sig@python.org Cc: akuchlin@mems-exchange.org; numpy-discussion@lists.sourceforge.net Subject: [Numpy-discussion] Multi-distribution distributions I'm somewhat surprised by the fact that some distributions (e.g. Numpy, Zodb) have multiple setup.py programs. As far as I know, these setup.py's do not share information so there is no way to do a bdist_wininst or bdist_rpm that builds a single distribution for these multiple sub-packages. I see this as a fairly large problem! The bdist_ functions are an important part of Distutils functionality. Paul Prescod _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/numpy-discussion From mal@lemburg.com Fri Jan 5 02:16:06 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Jan 5 02:16:06 2001 Subject: [Distutils] Multi-distribution distributions References: <3A5521BE.1E8DF72@ActiveState.com> Message-ID: <3A557443.64975A7E@lemburg.com> Paul Prescod wrote: > > I'm somewhat surprised by the fact that some distributions (e.g. Numpy, > Zodb) have multiple setup.py programs. As far as I know, these > setup.py's do not share information so there is no way to do a > bdist_wininst or bdist_rpm that builds a single distribution for these > multiple sub-packages. > > I see this as a fairly large problem! The bdist_ functions are an > important part of Distutils functionality. I don't think I understand your question: do you want a single setup.py to call all the other setup.py files similar to a recursive Makefile ? I'd be interested to hear how the other packagers deal with multiple subpackages, since I am planning to start in the same direction with my mx utils. There will be a base installation and multiple optional subpackages, but I'm currently unsure how to split up the task -- it could either be done using a setup.py which takes extra options (for choosing the subpackages in question) or by having multiple setup.py files (one for the base set and then one for each optional add-on). Thoughts ? Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paulp@ActiveState.com Fri Jan 5 02:49:02 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Fri Jan 5 02:49:02 2001 Subject: [Distutils] Multi-distribution distributions References: <3A5521BE.1E8DF72@ActiveState.com> <3A557443.64975A7E@lemburg.com> Message-ID: <3A557C72.5BDCF12C@ActiveState.com> "M.-A. Lemburg" wrote: > > ... > > I don't think I understand your question: do you want a single > setup.py to call all the other setup.py files similar to a > recursive Makefile ? That's exactly what I do *not want*. Recursive makefiles are easy and I'm not thrilled with recursive setup.py's either. As soon as you do that you have the usual "make" problem that the dependency checking is not unified PLUS the distutils-specific problem that any distributions you build will not be unified. You'll get six RPMs, six windows executables, etc. One of ActiveState's goals is to make extension installation as easy for people without compilers as Python installation is. Binary builds are an important part of that. If I have to tell a NumPy user to install five RPMs/Windows executables/MSIs/PPMs for one "logical" modules (NumPy), they will complain. I would like each logical "Python extension" to have one setup.py. If it is to have optional parts then there should be distutils options that turn those parts on and off. Context: I could have a special case for NumPy and a special case for ZODB and a special case for ... But there are around 600 extensions on the Vaults of Parnassus and about 1800 Perl extensions on CPAN. If I'm going to provide compiled versions of these to my customers, I need to be able to automate that process. I need to set up a script that downloads a random module, runs "python setup.py bdist_winexe" and posts it on a web page with little or no human intervention. I've found less than 10 distutils extensions in the world and most of them are idiosyncratic in one way or another. I think that's just growing pains but I'm going to try to iron out the idiosyncracies one by one so that the first extensions can serve as models for the hundreds that are yet to come. Paul Prescod From jack@oratrix.nl Fri Jan 5 04:28:00 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri Jan 5 04:28:00 2001 Subject: [Distutils] How are patches processed? Message-ID: <20010105092723.6A5843BD8B0@snelboot.oratrix.nl> How are patches to the distutils code processed, and who can do this? I sent in a batch of fixes to make distutils work on the mac about 2 months ago, first to Greg personally and when he didn't react to the whole mailing list, but absolutely nothing seems to happen. I assume Greg is away or something, as he also doesn't post to the list, but I would think there are more people who have write-access to the repository, no? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From mal@lemburg.com Fri Jan 5 05:54:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Jan 5 05:54:01 2001 Subject: [Distutils] How are patches processed? References: <20010105092723.6A5843BD8B0@snelboot.oratrix.nl> Message-ID: <3A55A780.A9AA52B5@lemburg.com> Jack Jansen wrote: > > How are patches to the distutils code processed, and who can do this? I sent > in a batch of fixes to make distutils work on the mac about 2 months ago, > first to Greg personally and when he didn't react to the whole mailing list, > but absolutely nothing seems to happen. > > I assume Greg is away or something, as he also doesn't post to the list, but I > would think there are more people who have write-access to the repository, no? I have asked that question before on python-dev... Greg seems to be offline or way to busy (like many of us) to respond to questions. As for the repository: distutils is part of Python 2.0 CVS tree, so Python developers should be able to commit changes to the distutils tree too. I'd rather have Greg's OK for this first, though, since he owns the code. BTW, to check out the module as developer, run this command: cvs -z3 -d@cvs.python.sourceforge.net:/cvsroot/python co distutils Changes to distutils will also have to be applied to the Python 2.0 CVS tree (Lib/distutils). -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jack@oratrix.nl Fri Jan 5 06:45:01 2001 From: jack@oratrix.nl (Jack Jansen) Date: Fri Jan 5 06:45:01 2001 Subject: [Distutils] How are patches processed? In-Reply-To: Message by "M.-A. Lemburg" , Fri, 05 Jan 2001 11:52:48 +0100 , <3A55A780.A9AA52B5@lemburg.com> Message-ID: <20010105114413.D9C843BD8B0@snelboot.oratrix.nl> > I have asked that question before on python-dev... Greg seems to > be offline or way to busy (like many of us) to respond to questions. > > As for the repository: distutils is part of Python 2.0 CVS tree, so > Python developers should be able to commit changes to the distutils > tree too. I'd rather have Greg's OK for this first, though, since > he owns the code. This is indeed the problem I'm running against: Greg requested that changes go via him, but he's been away for ages now, which essentially stops distutils development dead. I was hoping that Greg had appointed at least one other person to decide on patches in his absence. Maybe we should ask him to do this when he surfaces again... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From paulp@ActiveState.com Fri Jan 5 12:11:12 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Fri Jan 5 12:11:12 2001 Subject: [Distutils] RE: [Numpy-discussion] Multi-distribution distributions References: Message-ID: <3A55FFFC.3DB3872D@ActiveState.com> "Paul F. Dubois" wrote: > > Explanation: we made these packages optional partly because they ought to be > optional but partly because one of them depends on LAPACK and many people > wish to configure the packages to use a different LAPACK than the limited > "lite" one supplied. Wow, your "lite" module is half a meg. I'd hate to see the heavy version. :) I may not understand the extension so please tell me if I'm off-base: Would it be simpler to have a single setup.py and a set of flags to turn on and off each of the "secondary" extensions? > You are welcome to add a script which runs the bdist functions on all the > optional packages, in much the same way setup_all.py works. If I did this, I would consider a different strategy. I would suggest that each of the setup.py's could move their "setup" function into an if __name__=="__main__" block. Then setup_all.py could import each one (a little trickery needed there) and then combine the symbols like sourcelist, headers, ext_modules and so forth. > You do need to > face the issue if making a bdist for the public of which LAPACK you use on > which platform. I would expect to use lapack_lite.pyd. It's easy enough to override it by copying a custom lapack on top. Paul Prescod From akuchlin@mems-exchange.org Sat Jan 6 16:37:01 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sat Jan 6 16:37:01 2001 Subject: [Distutils] How are patches processed? In-Reply-To: <3A55A780.A9AA52B5@lemburg.com>; from mal@lemburg.com on Fri, Jan 05, 2001 at 11:52:48AM +0100 References: <20010105092723.6A5843BD8B0@snelboot.oratrix.nl> <3A55A780.A9AA52B5@lemburg.com> Message-ID: <20010106163608.A425@kronos.cnri.reston.va.us> On Fri, Jan 05, 2001 at 11:52:48AM +0100, M.-A. Lemburg wrote: >I have asked that question before on python-dev... Greg seems to >be offline or way to busy (like many of us) to respond to questions. Greg is in the process of moving back to Montreal, so he's unreachable at the moment until he gets an apartment and a new ISP. I can look at the simpler patches on SourceForge and check them in, but would feel uncomfortable approving anything more architectural (I don't think I'm familiar enough with the guts of Distutils to figure out when a change would be the Wrong Thing). What are the current critical issues that need to be fixed in Distutils? >Changes to distutils will also have to be applied to the Python 2.0 >CVS tree (Lib/distutils). That shouldn't be necessary. Unless something has changed and I'm unaware of it, Lib/distutils is a symlink to a subdirectory of the distutils module in CVS, so changes to one also appear in the other as if by magic. --amk From akuchlin@mems-exchange.org Sat Jan 6 17:12:01 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sat Jan 6 17:12:01 2001 Subject: [Distutils] Multi-distribution distributions In-Reply-To: <3A557C72.5BDCF12C@ActiveState.com>; from paulp@ActiveState.com on Thu, Jan 04, 2001 at 11:49:06PM -0800 References: <3A5521BE.1E8DF72@ActiveState.com> <3A557443.64975A7E@lemburg.com> <3A557C72.5BDCF12C@ActiveState.com> Message-ID: <20010106171120.B425@kronos.cnri.reston.va.us> On Thu, Jan 04, 2001 at 11:49:06PM -0800, Paul Prescod wrote: >I could have a special case for NumPy and a special case for ZODB and a >special case for ... But there are around 600 extensions on the Vaults >of Parnassus and about 1800 Perl extensions on CPAN. If I'm going to The unified ZODB distribution is really several extensions in one: ExtensionClasses, for example, are potentially useful in their own right without the rest of ZODB. But I don't want to make people download seven different packages, so they're wrapped up in a single distribution. The true solution would be a tool like Debian's apt-get to automatically download the dependencies for a package, but that's a long way away. If you're working on a Python package manager for ActiveState and want to package the ZODB, then all the components can just be packaged separately. I'm not sure if a similar approach would help for the mx* packages, though, and agree that some convention should be selected. Anyone got any ideas? --amk From jack@oratrix.nl Sat Jan 6 18:46:10 2001 From: jack@oratrix.nl (Jack Jansen) Date: Sat Jan 6 18:46:10 2001 Subject: [Distutils] How are patches processed? In-Reply-To: Message by Andrew Kuchling , Sat, 6 Jan 2001 16:36:08 -0500 , <20010106163608.A425@kronos.cnri.reston.va.us> Message-ID: <20010106234535.869FD14ADD7@oratrix.oratrix.nl> Recently, Andrew Kuchling said: > What are the current critical issues that need to be fixed in > Distutils? Well, I'd really like the Mac fixes for distutils to be in the repository before the 2.1a release... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From paulp@ActiveState.com Sun Jan 7 11:12:01 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Sun Jan 7 11:12:01 2001 Subject: [Distutils] Proposal: Meta extensions (components) References: <3A5521BE.1E8DF72@ActiveState.com> <3A557443.64975A7E@lemburg.com> <3A557C72.5BDCF12C@ActiveState.com> <20010106171120.B425@kronos.cnri.reston.va.us> Message-ID: <3A58955B.9FCB85D0@ActiveState.com> Andrew Kuchling wrote: > > On Thu, Jan 04, 2001 at 11:49:06PM -0800, Paul Prescod wrote: > >I could have a special case for NumPy and a special case for ZODB and a > >special case for ... But there are around 600 extensions on the Vaults > >of Parnassus and about 1800 Perl extensions on CPAN. If I'm going to > > The unified ZODB distribution is really several extensions in one: > ExtensionClasses, for example, are potentially useful in their own > right without the rest of ZODB. I've been thinking about this today. I'd like feedback on a proposal. Let's start with terminology: there is a "missing term" in our vocabulary. People sometimes use the words "module", "extension" and "package" for a "distutils unit" but those words already have precise meanings in the Python world. I propose the term "distutils component". A distutils component consists of a directory which contains a setup.py and some other code. The component is also the unit of versioning. Some components "embed" other components. The parent component is dependent on the embedded component and for convenience, the embedded component is distributed with the parent. Embedding may go away when distutils has proper dependency tracking -- but it may not. It should be possible to create a "parent component" or "meta component" by specifying the paths to sub-components. Just as you specify "py_modules", "extensions" and so forth, you should be able to specify "sub_components". Then distutils itself would do all of the "for subcomponent in subcomponents: run_setup()" hackery that NumPy, ZODB, etc. do "by hand" today. This could map into installers too. There is probably a way to create RPMs that contain RPMs, windows EXEs that contain windows EXEs and so forth. Paul Prescod From michel.vandenbergh@luc.ac.be Mon Jan 8 03:29:01 2001 From: michel.vandenbergh@luc.ac.be (Michel Van den Bergh) Date: Mon Jan 8 03:29:01 2001 Subject: [Distutils] Windows installer. References: <20010107170103.2978CEA3D@mail.python.org> Message-ID: <3A597A1B.E828C405@luc.ac.be> Hello, I have been looking at the windows installer coming with distutils. It seems fine for installing python extensions but not for what I would call "python applications" e.g. a games. For the end user the fact that an application is written in python is basically irrelevant (except that python needs to be installed to run it). An application will typically be installed in "C:\Program Files". Furthermore the user will expect a desktop shortcut, a start menu entry and an uninstall program. The current windows installer does not seem to be capable of installing, let alone generating such things. I noticed that there exists a free (as in free speech) installer for Windows: http://www.nullsoft.com/free/nsis/ which seems to be very capable. So it would be sensible to have an option "bdist_nsis" and I am considering writing such a thing. What do you think? Or is there something flawed in what I say? Regards, Michel From Alexandre.Fayolle@logilab.fr Mon Jan 8 03:42:08 2001 From: Alexandre.Fayolle@logilab.fr (Alexandre Fayolle) Date: Mon Jan 8 03:42:08 2001 Subject: [Distutils] Windows installer. In-Reply-To: <3A597A1B.E828C405@luc.ac.be> Message-ID: On Mon, 8 Jan 2001, Michel Van den Bergh wrote: > An application will typically be installed in "C:\Program Files". > Furthermore the user will expect a desktop shortcut, a start menu > entry and an uninstall program. The current windows installer does not > seem to be capable of installing, let alone generating such things. I have come up with the same conclusion for Narval (http://www.logilab.org/narval -- I know, this is a shameless plug ;o) > I noticed that there exists a free (as in free speech) installer for > Windows: http://www.nullsoft.com/free/nsis/ which seems to be very > capable. So it would be sensible to have an option "bdist_nsis" and I am > considering writing such a thing. I have not looked at this installer. What we use at Logilab is Inno Setup, which comes with an open source license too (it sounds BSD-ish, but I'm not a license expert). It is very easy to use, and does a good work. The URL is http://www.jrsoftware.org/isinfo.htm Alexandre Fayolle -- http://www.logilab.com Narval is the first software agent available as free software (GPL). LOGILAB, Paris (France). From mal@lemburg.com Mon Jan 8 06:58:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Jan 8 06:58:01 2001 Subject: [Distutils] Multi-distribution distributions References: <3A5521BE.1E8DF72@ActiveState.com> <3A557443.64975A7E@lemburg.com> <3A557C72.5BDCF12C@ActiveState.com> <20010106171120.B425@kronos.cnri.reston.va.us> Message-ID: <3A59AA7F.924CE8B7@lemburg.com> Andrew Kuchling wrote: > > On Thu, Jan 04, 2001 at 11:49:06PM -0800, Paul Prescod wrote: > >I could have a special case for NumPy and a special case for ZODB and a > >special case for ... But there are around 600 extensions on the Vaults > >of Parnassus and about 1800 Perl extensions on CPAN. If I'm going to > > The unified ZODB distribution is really several extensions in one: > ExtensionClasses, for example, are potentially useful in their own > right without the rest of ZODB. But I don't want to make people > download seven different packages, so they're wrapped up in a single > distribution. The true solution would be a tool like Debian's apt-get > to automatically download the dependencies for a package, but that's a > long way away. If you're working on a Python package manager for > ActiveState and want to package the ZODB, then all the components can > just be packaged separately. > > I'm not sure if a similar approach would help for the mx* packages, > though, and agree that some convention should be selected. Anyone got > any ideas? I am currently planning to release the mx Extensions as three packages: BASE, CRYPTO and COMMERCIAL. Each of these packages will contain a set of mx subpackages with CRYPTO and COMMERCIAL depending on BASE. The reason for me to bundle the subpackages is that of simplified maintenance -- as the number of subpackages increases, I can no longer distribute them separately. Since diskspace is cheap and bandwidth is too, I don't see much of a problem with this step. Still, I agree that it would be nice to at tell distutils to create RPM, DEB, etc. dependencies automatically. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Mon Jan 8 07:05:59 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Jan 8 07:05:59 2001 Subject: [Distutils] Proposal: Meta extensions (components) References: <3A5521BE.1E8DF72@ActiveState.com> <3A557443.64975A7E@lemburg.com> <3A557C72.5BDCF12C@ActiveState.com> <20010106171120.B425@kronos.cnri.reston.va.us> <3A58955B.9FCB85D0@ActiveState.com> Message-ID: <3A59AD03.2D68C118@lemburg.com> Paul Prescod wrote: > > Andrew Kuchling wrote: > > > > On Thu, Jan 04, 2001 at 11:49:06PM -0800, Paul Prescod wrote: > > >I could have a special case for NumPy and a special case for ZODB and a > > >special case for ... But there are around 600 extensions on the Vaults > > >of Parnassus and about 1800 Perl extensions on CPAN. If I'm going to > > > > The unified ZODB distribution is really several extensions in one: > > ExtensionClasses, for example, are potentially useful in their own > > right without the rest of ZODB. > > I've been thinking about this today. I'd like feedback on a proposal. > > Let's start with terminology: there is a "missing term" in our > vocabulary. People sometimes use the words "module", "extension" and > "package" for a "distutils unit" but those words already have precise > meanings in the Python world. I propose the term "distutils component". > A distutils component consists of a directory which contains a setup.py > and some other code. The component is also the unit of versioning. > > Some components "embed" other components. The parent component is > dependent on the embedded component and for convenience, the embedded > component is distributed with the parent. Embedding may go away when > distutils has proper dependency tracking -- but it may not. > > It should be possible to create a "parent component" or "meta component" > by specifying the paths to sub-components. Just as you specify > "py_modules", "extensions" and so forth, you should be able to specify > "sub_components". Then distutils itself would do all of the "for > subcomponent in subcomponents: run_setup()" hackery that NumPy, ZODB, > etc. do "by hand" today. > > This could map into installers too. There is probably a way to create > RPMs that contain RPMs, windows EXEs that contain windows EXEs and so > forth. Nice idea. Could you put the definitions on the distutils web page somwhere ? -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mfletch@tpresence.com Mon Jan 8 13:52:01 2001 From: mfletch@tpresence.com (Mike Fletcher) Date: Mon Jan 8 13:52:01 2001 Subject: [Distutils] Proposal: Meta extensions (components) Message-ID: This sounds a great deal like the Distribution Unit in the Open Software Description (http://www.w3.org/TR/NOTE-OSD.html). Might we want to adapt rather than reinvent such a thing? Bonus for Paul: it's XML! ;o) Enjoy yourselves, Mike -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Monday, January 08, 2001 7:05 AM To: Paul Prescod Cc: distutils-sig@python.org Subject: Re: [Distutils] Proposal: Meta extensions (components) Paul Prescod wrote: > > Andrew Kuchling wrote: ... > Let's start with terminology: there is a "missing term" in our > vocabulary. People sometimes use the words "module", "extension" and > "package" for a "distutils unit" but those words already have precise > meanings in the Python world. I propose the term "distutils component". > A distutils component consists of a directory which contains a setup.py > and some other code. The component is also the unit of versioning. > > Some components "embed" other components. The parent component is > dependent on the embedded component and for convenience, the embedded > component is distributed with the parent. Embedding may go away when > distutils has proper dependency tracking -- but it may not. > > It should be possible to create a "parent component" or "meta component" > by specifying the paths to sub-components. Just as you specify > "py_modules", "extensions" and so forth, you should be able to specify > "sub_components". Then distutils itself would do all of the "for > subcomponent in subcomponents: run_setup()" hackery that NumPy, ZODB, > etc. do "by hand" today. > > This could map into installers too. There is probably a way to create > RPMs that contain RPMs, windows EXEs that contain windows EXEs and so > forth. ... From akuchlin@mems-exchange.org Mon Jan 8 14:04:02 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon Jan 8 14:04:02 2001 Subject: [Distutils] Multi-distribution distributions In-Reply-To: <3A59AA7F.924CE8B7@lemburg.com>; from mal@lemburg.com on Mon, Jan 08, 2001 at 12:54:39PM +0100 References: <3A5521BE.1E8DF72@ActiveState.com> <3A557443.64975A7E@lemburg.com> <3A557C72.5BDCF12C@ActiveState.com> <20010106171120.B425@kronos.cnri.reston.va.us> <3A59AA7F.924CE8B7@lemburg.com> Message-ID: <20010108140332.A30360@kronos.cnri.reston.va.us> On Mon, Jan 08, 2001 at 12:54:39PM +0100, M.-A. Lemburg wrote: >I am currently planning to release the mx Extensions as three >packages: BASE, CRYPTO and COMMERCIAL. Each of these packages >will contain a set of mx subpackages with CRYPTO and COMMERCIAL >depending on BASE. But if BASE includes, say, mxDateTime, mxODBC, and mxTextTools, how would a user specify that only mxDateTime and mxODBC should be compiled? I think that's what Paul is wondering about, and I think this should be standardized to keep the process of building packages consistent. --amk From mal@lemburg.com Mon Jan 8 15:27:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Jan 8 15:27:01 2001 Subject: [Distutils] Multi-distribution distributions References: <3A5521BE.1E8DF72@ActiveState.com> <3A557443.64975A7E@lemburg.com> <3A557C72.5BDCF12C@ActiveState.com> <20010106171120.B425@kronos.cnri.reston.va.us> <3A59AA7F.924CE8B7@lemburg.com> <20010108140332.A30360@kronos.cnri.reston.va.us> Message-ID: <3A5A2249.BE75338A@lemburg.com> Andrew Kuchling wrote: > > On Mon, Jan 08, 2001 at 12:54:39PM +0100, M.-A. Lemburg wrote: > >I am currently planning to release the mx Extensions as three > >packages: BASE, CRYPTO and COMMERCIAL. Each of these packages > >will contain a set of mx subpackages with CRYPTO and COMMERCIAL > >depending on BASE. > > But if BASE includes, say, mxDateTime, mxODBC, and mxTextTools, how > would a user specify that only mxDateTime and mxODBC should be > compiled? He wouldn't... it's either all packages or none. I really don't think that standard Joe User cares about too many packages being installed (at least at the size of a few 100kB each). > I think that's what Paul is wondering about, and I think > this should be standardized to keep the process of building packages > consistent. True, but I also fear that many packages will have specialized setup.py files to accomodate for their resp. needs, e.g. the autoconf machinery in distutils is still in its infancy and a more powerful library detection would also be needed to satisfy extensions built around third-party libs. Still distutils is a big step forward, since there's a single interface for the installation process: setup.py in the packages base distribution directory. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin@mems-exchange.org Mon Jan 8 22:30:01 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon Jan 8 22:30:01 2001 Subject: [Distutils] How are patches processed? In-Reply-To: <20010106234535.869FD14ADD7@oratrix.oratrix.nl>; from jack@oratrix.nl on Sun, Jan 07, 2001 at 12:45:30AM +0100 References: <20010106234535.869FD14ADD7@oratrix.oratrix.nl> Message-ID: <20010108222917.A5402@kronos.cnri.reston.va.us> On Sun, Jan 07, 2001 at 12:45:30AM +0100, Jack Jansen wrote: >Well, I'd really like the Mac fixes for distutils to be in the >repository before the 2.1a release... OK, I'll take a look at them. Are these fixes on SourceForge, or in the distutils-sig back archive? --amk From michel.vandenbergh@luc.ac.be Tue Jan 9 03:35:01 2001 From: michel.vandenbergh@luc.ac.be (Michel Van den Bergh) Date: Tue Jan 9 03:35:01 2001 Subject: [Distutils] Windows installer. References: <20010108170105.4CC17EC86@mail.python.org> Message-ID: <3A5ACD1F.FA343CE0@luc.ac.be> > > > An application will typically be installed in "C:\Program Files". > > Furthermore the user will expect a desktop shortcut, a start menu > > entry and an uninstall program. The current windows installer does not > > seem to be capable of installing, let alone generating such things. > > I have come up with the same conclusion for Narval > (http://www.logilab.org/narval -- I know, this is a shameless plug ;o) > > > I noticed that there exists a free (as in free speech) installer for > > Windows: http://www.nullsoft.com/free/nsis/ which seems to be very > > capable. So it would be sensible to have an option "bdist_nsis" and I am > > considering writing such a thing. > > I have not looked at this installer. What we use at Logilab is Inno Setup, > which comes with an open source license too (it sounds BSD-ish, but > I'm not a license expert). It is very easy to use, and does a good work. > The URL is http://www.jrsoftware.org/isinfo.htm > > Alexandre Fayolle > -- > http://www.logilab.com > Narval is the first software agent available as free software (GPL). > LOGILAB, Paris (France). > I looked at Inno Setup. It is indeed very good and it comes with a BSD style licence. I was able to create a professional looking installer in 10 minutes. It seems very easy to create the installation script automatically by modifying bdist_dump a little bit. bdist_dump basically does a mock install to the build directory and then packs the result. Instead of packing the result one should make an installation script listing the files which were created by the mock install. Then Inno setup should be invoked. Bdist_inno could have a few options such as the name of the licence file, the name of the readme file, the name of the main script (to create shortcuts on the Desktop and in the Start Menu), the default install location and the path of the executable for the Inno setup application. When I find some time I will look into this. Thanks for the tip. Michel From mal@lemburg.com Tue Jan 9 06:35:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue Jan 9 06:35:01 2001 Subject: [Distutils] Windows installer. References: <20010108170105.4CC17EC86@mail.python.org> <3A5ACD1F.FA343CE0@luc.ac.be> Message-ID: <3A5AF728.BF3A7F2B@lemburg.com> Michel Van den Bergh wrote: > > > > > > An application will typically be installed in "C:\Program Files". > > > Furthermore the user will expect a desktop shortcut, a start menu > > > entry and an uninstall program. The current windows installer does not > > > seem to be capable of installing, let alone generating such things. > > > > I have come up with the same conclusion for Narval > > (http://www.logilab.org/narval -- I know, this is a shameless plug ;o) > > > > > I noticed that there exists a free (as in free speech) installer for > > > Windows: http://www.nullsoft.com/free/nsis/ which seems to be very > > > capable. So it would be sensible to have an option "bdist_nsis" and I am > > > considering writing such a thing. > > > > I have not looked at this installer. What we use at Logilab is Inno Setup, > > which comes with an open source license too (it sounds BSD-ish, but > > I'm not a license expert). It is very easy to use, and does a good work. > > The URL is http://www.jrsoftware.org/isinfo.htm > > > > Alexandre Fayolle > > -- > > http://www.logilab.com > > Narval is the first software agent available as free software (GPL). > > LOGILAB, Paris (France). > > > I looked at Inno Setup. It is indeed very good and it comes with a BSD style > licence. > > I was able to create a professional looking installer in 10 minutes. It seems > very easy to create the installation script > automatically by modifying bdist_dump a little bit. bdist_dump basically does a > mock install to the build directory and then packs > the result. Instead of packing the result one should make an installation > script listing the files which were created by the mock > install. Then Inno setup should be invoked. > > Bdist_inno could have a few options such as the name of the licence file, the > name of the readme file, the name of the > main script (to create shortcuts on the Desktop and in the Start Menu), the > default install location and the path of the executable for the Inno setup > application. > > When I find some time I will look into this. The installer looks very promising -- does anyone know how it compares to the WISE installer which is free for Python extensions ? Also, are there projects out there for Windows like installers on other platforms such as Mac, Linux and other Unices ? (RPMs are nice for experts, but they simply don't match up to the user friendlyness of Windows installers.) Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas.heller@ion-tof.com Tue Jan 9 07:31:01 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue Jan 9 07:31:01 2001 Subject: [Distutils] Windows installer. References: <20010107170103.2978CEA3D@mail.python.org> <3A597A1B.E828C405@luc.ac.be> Message-ID: <01ac01c07a37$dccf3190$e000a8c0@thomasnotebook> > Hello, > > I have been looking at the windows installer coming with distutils. It > seems > fine for installing python extensions but not for what I would call > "python applications" e.g. a games. For the end user the fact that an > application is written in python is basically irrelevant (except that > python > needs to be installed to run it). The issue is that distutils (currently) only cares about installing python _extensions_, not python _applications_. > > An application will typically be installed in "C:\Program Files". > Furthermore the user will expect a desktop shortcut, a start menu > entry and an uninstall program. The current windows installer does not > seem to be capable of installing, let alone generating such things. > The windows installer could easily be modified to create shortcuts, say, for the scripts arguments to setup(), and provide uninstall facilities. The hooks are there. Typically, for a professional looking 'application', you would first run the 'main script' through something like Gordon's windows installer, and pack the output into a windows installation program like wise or inno. BTW, I have a similar package like Gordon's installer which is integrated into distutils. Regards, Thomas From michel.vandenbergh@luc.ac.be Tue Jan 9 07:43:59 2001 From: michel.vandenbergh@luc.ac.be (Michel Van den Bergh) Date: Tue Jan 9 07:43:59 2001 Subject: [Distutils] Windows installer. References: <20010107170103.2978CEA3D@mail.python.org> <3A597A1B.E828C405@luc.ac.be> <01ac01c07a37$dccf3190$e000a8c0@thomasnotebook> Message-ID: <3A5B075C.41CE192@luc.ac.be> Hello Thomas, I see that you are the author of bdist_wininst. I didn't want to say anything negative about bdist_wininst. It looks very cool. It is just that it doesn't want install anything outside the Python distribution unlike for example bdist_rpm, which I am using for Linux . What is "Gordon's windows installer"? I am sorry but I am new to this list. Thomas Heller wrote: > > Hello, > > > > I have been looking at the windows installer coming with distutils. It > > seems > > fine for installing python extensions but not for what I would call > > "python applications" e.g. a games. For the end user the fact that an > > application is written in python is basically irrelevant (except that > > python > > needs to be installed to run it). > The issue is that distutils (currently) only cares about installing > python _extensions_, not python _applications_. > > > > > An application will typically be installed in "C:\Program Files". > > Furthermore the user will expect a desktop shortcut, a start menu > > entry and an uninstall program. The current windows installer does not > > seem to be capable of installing, let alone generating such things. > > > > The windows installer could easily be modified to create shortcuts, > say, for the scripts arguments to setup(), and provide > uninstall facilities. The hooks are there. > > Typically, for a professional looking 'application', you would > first run the 'main script' through something like Gordon's windows > installer, and pack the output into a windows installation program > like wise or inno. BTW, I have a similar package like Gordon's installer > which is integrated into distutils. > > Regards, > > Thomas From thomas.heller@ion-tof.com Tue Jan 9 08:04:01 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue Jan 9 08:04:01 2001 Subject: [Distutils] Windows installer. References: <20010107170103.2978CEA3D@mail.python.org> <3A597A1B.E828C405@luc.ac.be> <01ac01c07a37$dccf3190$e000a8c0@thomasnotebook> <3A5B075C.41CE192@luc.ac.be> Message-ID: <01e201c07a3c$8d125830$e000a8c0@thomasnotebook> > Hello Thomas, > > I see that you are the author of bdist_wininst. I didn't want to say > anything negative about bdist_wininst. No need to worry: You didn't > It looks very cool. > It is just that it doesn't want > install anything outside the Python distribution unlike for example > bdist_rpm, which I am using for Linux . > > What is "Gordon's windows installer"? I am sorry but I am new > to this list. Gordon's windows installer creates standalone windows applications from python scripts, no need for the user to have python installed at all. The URL is: http://www.mcmillan-inc.com/install1.html Regards, Thomas From thomas.heller@ion-tof.com Tue Jan 9 08:13:01 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue Jan 9 08:13:01 2001 Subject: [Distutils] How are patches processed? References: <20010106234535.869FD14ADD7@oratrix.oratrix.nl> <20010108222917.A5402@kronos.cnri.reston.va.us> Message-ID: <021001c07a3d$c9173930$e000a8c0@thomasnotebook> > On Sun, Jan 07, 2001 at 12:45:30AM +0100, Jack Jansen wrote: > >Well, I'd really like the Mac fixes for distutils to be in the > >repository before the 2.1a release... > > OK, I'll take a look at them. Are these fixes on SourceForge, or in > the distutils-sig back archive? They are in the archive (Jack, correct me if there is a newer version): http://mail.python.org/pipermail/distutils-sig/2000-November/001755.html I have looked at them, and they look good for me. They include 3 chunks of mac-specific diffs to ccompiler.py and dist.py, as well as mwerkscompiler.py. I cannot comment on the mac-specific parts in any way. Regards, Thomas From michel.vandenbergh@luc.ac.be Tue Jan 9 09:43:01 2001 From: michel.vandenbergh@luc.ac.be (Michel Van den Bergh) Date: Tue Jan 9 09:43:01 2001 Subject: [Distutils] Windows installer. References: <20010107170103.2978CEA3D@mail.python.org> <3A597A1B.E828C405@luc.ac.be> <01ac01c07a37$dccf3190$e000a8c0@thomasnotebook> <3A5B075C.41CE192@luc.ac.be> <01e201c07a3c$8d125830$e000a8c0@thomasnotebook> Message-ID: <3A5B234E.288E904F@luc.ac.be> Thomas Heller wrote: > > Hello Thomas, > > > > I see that you are the author of bdist_wininst. I didn't want to say > > anything negative about bdist_wininst. > No need to worry: You didn't > > It looks very cool. > > It is just that it doesn't want > > install anything outside the Python distribution unlike for example > > bdist_rpm, which I am using for Linux . > > > > What is "Gordon's windows installer"? I am sorry but I am new > > to this list. > Gordon's windows installer creates standalone windows applications > from python scripts, no need for the user to have python installed at all. > > The URL is: > > http://www.mcmillan-inc.com/install1.html > > Regards, > > Thomas Thanks, that's a useful link. Still I don't really want to bother too much with windows specific things (I never use windows). This is the reason why I would prefer to be able to generate all archives (source, as well as Windows and Linux binary installers) from a single setup script. Given the fact that Python itself is cross-platform I thought the intention of distutils was to create a cross platform installer in Python. I now realize that distutils is really geared to towards the installation of extensions and that it requires some tweaking to install applications. Regards, Michel From thomas.heller@ion-tof.com Tue Jan 9 10:59:01 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue Jan 9 10:59:01 2001 Subject: [Distutils] Multi-distribution distributions References: <3A5521BE.1E8DF72@ActiveState.com> <3A557443.64975A7E@lemburg.com> <3A557C72.5BDCF12C@ActiveState.com> <20010106171120.B425@kronos.cnri.reston.va.us> Message-ID: <031501c07a54$fcc00ca0$e000a8c0@thomasnotebook> Andrew Kuchling wrote: > On Thu, Jan 04, 2001 at 11:49:06PM -0800, Paul Prescod wrote: > >I could have a special case for NumPy and a special case for ZODB and a > >special case for ... But there are around 600 extensions on the Vaults > >of Parnassus and about 1800 Perl extensions on CPAN. If I'm going to > > The unified ZODB distribution is really several extensions in one: > ExtensionClasses, for example, are potentially useful in their own > right without the rest of ZODB. But I don't want to make people > download seven different packages, so they're wrapped up in a single > distribution. The true solution would be a tool like Debian's apt-get > to automatically download the dependencies for a package, but that's a > long way away. If you're working on a Python package manager for > ActiveState and want to package the ZODB, then all the components can > just be packaged separately. I have looked at the ZODB toplevel setup script, and it seems wrong to me. The behaviour you get is very confusing: Try running 'python setup.py --help', the --help option will be 'sent' to every single (sub)setup script, and you will get several screens of help. 'python setup.py bdist_dumb' however, does at least something sensible: it builds xxx.zip archives for every subpackage included in ZODB. Wouldn't it be better to take an approach like this: # create a magic dsitribution instance toplevel_dist = MagicDistribution() # collect all subpackages for package_dir in packages: os.chdir(package_dir) dist = run_setup('setup.py', stop_after='init') toplevel_dist.extend( <3A557443.64975A7E@lemburg.com> <3A557C72.5BDCF12C@ActiveState.com> <20010106171120.B425@kronos.cnri.reston.va.us> <3A58955B.9FCB85D0@ActiveState.com> <3A59AD03.2D68C118@lemburg.com> Message-ID: <3A5B385B.915DE1F8@ActiveState.com> "M.-A. Lemburg" wrote: > > ... > > Nice idea. > > Could you put the definitions on the distutils web page somwhere ? I don't think I have write access. I could write it up as an HTML document if someone else wants to post it. Paul From paulp@ActiveState.com Tue Jan 9 11:22:04 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Tue Jan 9 11:22:04 2001 Subject: [Distutils] Multi-distribution distributions References: Message-ID: <3A5B3AFE.5C6D687@ActiveState.com> "Mark W. Alexander" wrote: > > ... So to > implement sub-package support, each individual bdist_* module > has to be visited. Where you say "sub-package" I think you mean what I call "distribution unit" or "component". > The relevance here is that the bdist_generic class would > have built-in sub-package support which would then be > inherited to all (capable) package managers. I agree that some stuff could be abstracted into a base class but I still think that every bdist has to be touched to implement embedded distribution units. For instance Windows EXE would probably have to uncompress the embedded executables to a temporary directory, recursively execute them and then delete them. RPM would have to do something similar in a Unix-y way. Paul Prescod From martin@loewis.home.cs.tu-berlin.de Thu Jan 11 08:21:13 2001 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Thu Jan 11 08:21:13 2001 Subject: [Distutils] Distutils and iconv codec Message-ID: <200101111317.f0BDHBl09327@mira.informatik.hu-berlin.de> It appears that there was a patch for processing -L options in distutils lately, see http://sourceforge.net/patch/?func=detailpatch&patch_id=102971&group_id=5470 so python setup.py build_ext -L/tmp -lbla works now for me. Unfortunately, passing -R is still broken; python setup.py build_ext -L/tmp -R/tmp -lbla gives ... File "/usr/local/lib/python2.0/distutils/unixccompiler.py", line 208, in link (libraries, library_dirs, runtime_library_dirs) = \ File "/usr/local/lib/python2.0/distutils/ccompiler.py", line 438, in _fix_lib_args runtime_library_dirs = (list (runtime_library_dirs) + TypeError: can only concatenate list (not "string") to list Also, I wonder what the rationale is for supporting -L/tmp:/var/tmp, while not supporting the Unixish -L/tmp -L/var/tmp. Regards, Martin From phrxy@csv.warwick.ac.uk Sun Jan 14 15:31:01 2001 From: phrxy@csv.warwick.ac.uk (John J. Lee) Date: Sun Jan 14 15:31:01 2001 Subject: [Distutils] FORTRAN extension modules Message-ID: Has anyone added any FORTRAN support since the version of Distutils that came with python 2.0? I tried compiling Multipack with Distutils (after setting up the source with modified versions of the Makefile and setmodules.py from the Multipack distribution) by subclassing from UnixCCompiler, but of course that only works if you do it in two steps: ./setup.py build_clib -c unixf ./setup.py build_ext where unixf is my added FORTRAN compiler. I suppose the right thing would be to put it in CCompiler itself, so that all its subclasses would be capable of compiling FORTRAN too (with appropriate modifications)? I suppose the same would be true of, eg Pascal too. Maybe the class needs renaming too... John From mal@lemburg.com Mon Jan 15 04:53:06 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Jan 15 04:53:06 2001 Subject: [Distutils] Re: [Python-Dev] Where's Greg Ward ? References: Message-ID: <3A62C82C.EA25AAF5@lemburg.com> [CCed to distutils, since it matters there] Tim Peters wrote: > > [MAL] > > He seems to be offline and the people on the distutils list have > > some patches and other things which would be nice to have in > > distutils for 2.1. > > Greg's somewhere near the end of the process of moving from Virginia to > Canada; I expect he'll become visible again Real Soon. Great :) > > I suppose we could simply check in the patches, but we still want > > to get his OK on things before applying patches to the distutils > > tree. > > The distutils SIG could elect a Shadow Dictator in his place; if everyone > agrees to vote for Andrew, you save the effort of counting votes . Ok, let's agree to vote for Andrew :) Andrew, is that OK with you ? -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From hoel@germanlloyd.org Mon Jan 15 04:58:01 2001 From: hoel@germanlloyd.org (Berthold =?iso-8859-1?q?H=F6llmann?=) Date: Mon Jan 15 04:58:01 2001 Subject: [Distutils] Problems with distutils and multiple developers under sol2 (unix) Message-ID: Hello, We are developing a set of inhouse applications using Python. To put our Python code to the appropriate places under different Operating systems, we use distutils. But we have a problem with the unix permissons. User A develops package a.py and installs it using distutils. Later user B finds an enhancement/bug, corrects package a.py. But when he tries to install this using distutils he always gets an error message when distutils try to set the file permissions this fails because user A is still owner of the copied file after the copiing process. I think, distutils should first delete an old file, before trying to install/copy a new one. Can anyone see any problem with this aproach? Or should the "chmod" command simly included in a "try:" block to ignore errors that might occur? Cheers Berthold -- email: hoel@GermanLloyd.org ) tel. : +49 (40) 3 61 49 - 73 74 ( C[_] These opinions might be mine, but never those of my employer. From hoel@germanlloyd.org Mon Jan 15 05:49:01 2001 From: hoel@germanlloyd.org (Berthold =?iso-8859-1?q?H=F6llmann?=) Date: Mon Jan 15 05:49:01 2001 Subject: [Distutils] Problems with distutils and multiple developers under sol2 (unix) In-Reply-To: hoel@germanlloyd.org's message of "15 Jan 2001 10:52:04 +0100" References: Message-ID: hoel@germanlloyd.org (Berthold H=F6llmann) writes: > Hello, >=20 > We are developing a set of inhouse applications using Python. To put > our Python code to the appropriate places under different Operating > systems, we use distutils. But we have a problem with the unix > permissons. User A develops package a.py and installs it using > distutils. Later user B finds an enhancement/bug, corrects package > a.py. But when he tries to install this using distutils he always gets > an error message when distutils try to set the file permissions this > fails because user A is still owner of the copied file after the > copiing process. I think, distutils should first delete an old file, > before trying to install/copy a new one. Can anyone see any problem > with this aproach? Or should the "chmod" command simly included in a > "try:" block to ignore errors that might occur? As a followup, here my solution of the problem for distutils 1.0.1: in the file "file_util.py" I inserted the=20 if os.path.isfile(dst): os.remove(dst) as new line 40 in the function "_copy_file_contents". This seems to work at least for us. I hope, that something like that can make its way into the next distutils versions. Thanks Berthold --=20 email: hoel@GermanLloyd.org ) tel. : +49 (40) 3 61 49 - 73 74 ( C[_] These opinions might be mine, but never those of my employer. From barry@digicool.com Mon Jan 15 08:16:02 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon Jan 15 08:16:02 2001 Subject: [Distutils] Re: [Python-Dev] Where's Greg Ward ? References: <3A62C82C.EA25AAF5@lemburg.com> Message-ID: <14946.63472.282750.828218@anthem.wooz.org> >>>>> "M" == M writes: >> The distutils SIG could elect a Shadow Dictator in his place; >> if everyone agrees to vote for Andrew, you save the effort of >> counting votes . M> Ok, let's agree to vote for Andrew :) M> Andrew, is that OK with you ? He's got my vote. I've been experiencing some weird problems with the distutils installation of pybsddb3 out of the current Python cvs tree. It'd be nice if the outstanding distutils patches are integrated before I dive in. I don't see anything relevant in patches or bugs, but I don't know if there are other repositories of distutils fixes (like the archives?). -Barry From akuchlin@mems-exchange.org Mon Jan 15 10:42:00 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon Jan 15 10:42:00 2001 Subject: [Distutils] Where's Greg Ward ? In-Reply-To: <3A62C82C.EA25AAF5@lemburg.com>; from mal@lemburg.com on Mon, Jan 15, 2001 at 10:51:40AM +0100 References: <3A62C82C.EA25AAF5@lemburg.com> Message-ID: <20010115115115.A919@kronos.cnri.reston.va.us> [Redirecting this discussion to the Distutils-SIG] On Mon, Jan 15, 2001 at 10:51:40AM +0100, M.-A. Lemburg wrote: >Tim Peters wrote: >> Greg's somewhere near the end of the process of moving from Virginia to >> Canada; I expect he'll become visible again Real Soon. To add to this, he apparently has a (very slow) ISP connection again, since he sent an e-mail to the internal MEMS Exchange developer list, but he sent only a single message, so I assume he's not attempting to claw through his e-mail backlog just yet. >Andrew, is that OK with you ? I suppose so. I've tagged the current Lib/distutils tree with the tag "pre_amk", so Greg can readily determine what's been changed, and will begin looking at the various patches. --amk From akuchlin@mems-exchange.org Mon Jan 15 10:48:01 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon Jan 15 10:48:01 2001 Subject: [Distutils] Re: [Python-Dev] Where's Greg Ward ? In-Reply-To: <14946.63472.282750.828218@anthem.wooz.org>; from barry@digicool.com on Mon, Jan 15, 2001 at 08:15:28AM -0500 References: <3A62C82C.EA25AAF5@lemburg.com> <14946.63472.282750.828218@anthem.wooz.org> Message-ID: <20010115115719.B919@kronos.cnri.reston.va.us> On Mon, Jan 15, 2001 at 08:15:28AM -0500, Barry A. Warsaw wrote: >tree. It'd be nice if the outstanding distutils patches are >integrated before I dive in. I don't see anything relevant in patches >or bugs, but I don't know if there are other repositories of distutils >fixes (like the archives?). There are a few patches buried in the back archives, but I don't know of any outstanding bugfixes, so please report whatever problem you're seeing. Oh, and Barry, did the issue holding up your patch for adding shar support (#102313) ever get resolved? --amk From barry@digicool.com Mon Jan 15 11:47:01 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon Jan 15 11:47:01 2001 Subject: [Distutils] Re: [Python-Dev] Where's Greg Ward ? References: <3A62C82C.EA25AAF5@lemburg.com> <14946.63472.282750.828218@anthem.wooz.org> <20010115115719.B919@kronos.cnri.reston.va.us> Message-ID: <14947.10596.733726.995351@anthem.wooz.org> >>>>> "AK" == Andrew Kuchling writes: AK> There are a few patches buried in the back archives, but I AK> don't know of any outstanding bugfixes, so please report AK> whatever problem you're seeing. Okay, will do. AK> Oh, and Barry, did the issue holding up your patch for adding AK> shar support (#102313) ever get resolved? No, but I'll try to take another poke at it. -Barry From jeremy.kloth@fourthought.com Tue Jan 16 08:48:01 2001 From: jeremy.kloth@fourthought.com (Jeremy J Kloth) Date: Tue Jan 16 08:48:01 2001 Subject: [Distutils] Patch to build RPM with Python 2.0 References: <3A62C82C.EA25AAF5@lemburg.com> <20010115115115.A919@kronos.cnri.reston.va.us> Message-ID: <001a01c07fc2$dda5fdc0$1b01a8c0@fourthought.com> While attempting to build an RPM using distutils on Python 2.0, rpm complained about duplicate files. The following patch fixed that problem: --- /usr/local/src/Python2.0/Lib/distutils/command/install.py Wed Dec 20 04:02:59 2000 +++ /usr/local/lib/python2.0/distutils/command/install.py Tue Jan 16 06:31:31 2001 @@ -529,7 +529,8 @@ outputs = [] for cmd_name in self.get_sub_commands(): cmd = self.get_finalized_command(cmd_name) - outputs.extend(cmd.get_outputs()) + for out in cmd.get_outputs(): + out not in outputs and outputs.append(out) return outputs -- Jeremy Kloth Consultant jeremy.kloth@fourthought.com (303)583-9900 x 105 Fourthought, Inc. http://www.fourthought.com Software-engineering, knowledge-management, XML, CORBA, Linux, Python From akuchlin@mems-exchange.org Tue Jan 16 11:17:07 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue Jan 16 11:17:07 2001 Subject: [Distutils] Patch to build RPM with Python 2.0 In-Reply-To: <001a01c07fc2$dda5fdc0$1b01a8c0@fourthought.com>; from jeremy.kloth@fourthought.com on Tue, Jan 16, 2001 at 06:47:28AM -0700 References: <3A62C82C.EA25AAF5@lemburg.com> <20010115115115.A919@kronos.cnri.reston.va.us> <001a01c07fc2$dda5fdc0$1b01a8c0@fourthought.com> Message-ID: <20010116111653.C2541@kronos.cnri.reston.va.us> On Tue, Jan 16, 2001 at 06:47:28AM -0700, Jeremy J Kloth wrote: >While attempting to build an RPM using distutils on Python 2.0, >rpm complained about duplicate files. >The following patch fixed that problem: I've applied a modified version of this patch, using an 'if' statement instead of the short-circuit evaluation. Thanks! --amk From phrxy@csv.warwick.ac.uk Tue Jan 16 14:07:00 2001 From: phrxy@csv.warwick.ac.uk (John J. Lee) Date: Tue Jan 16 14:07:00 2001 Subject: [Distutils] FORTRAN extension modules In-Reply-To: Message-ID: On Sun, 14 Jan 2001, John J. Lee wrote: > Has anyone added any FORTRAN support since the version of Distutils that > came with python 2.0? I tried compiling Multipack with Distutils (after > setting up the source with modified versions of the Makefile and > setmodules.py from the Multipack distribution) by subclassing from > UnixCCompiler, but of course that only works if you do it in two steps: > > ./setup.py build_clib -c unixf > > ./setup.py build_ext Actually of course with g77 (FORTRAN front-end to gcc) it will work with just ./setup.py build -cunixf because g77 will happily do C too. Presumably this doesn't apply to many (any?) other compilers, though. Oddly though, after you've built your extensions and libraries, this *doesn't* work: ./setup.py install as it will default to the compiler named 'unix' (ie. unixccompiler.py), see that things aren't up to date from its point of view (not sure exactly why, but presumably because the compiler has changed), and try to compile the FORTRAN with a plain 'gcc -c' command which fails, of course. You can't do this: ./setup.py install -cunixf because there is no -c option for the install command. > where unixf is my added FORTRAN compiler. I suppose the right thing would > be to put it in CCompiler itself, so that all its subclasses would be > capable of compiling FORTRAN too (with appropriate modifications)? For the case of gcc, I should have been able to do this by just telling Dustutils to substitute g77 for gcc, add a new list of file prefixes for source (".f" etc), and not modify the source at all - shouldn't this be possible via the command line? I know it is the intention eventually to drive that sort of thing from an autoconf-style thing, but in the mean time, it would seem to be useful to be able to change at least the executable names via the command line / config file - or have I missed the option that does this? > I suppose the same would be true of, eg Pascal too. Maybe the class needs > renaming too... [...] John From akuchlin@mems-exchange.org Tue Jan 16 16:54:00 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue Jan 16 16:54:00 2001 Subject: [Distutils] Re: Detecting install time In-Reply-To: <200101160347.WAA01132@cj20424-a.reston1.va.home.com>; from guido@python.org on Mon, Jan 15, 2001 at 10:47:32PM -0500 References: <200101160303.WAA11632@207-172-111-91.s91.tnt1.ann.va.dialup.rcn.com> <200101160347.WAA01132@cj20424-a.reston1.va.home.com> Message-ID: <20010116165322.B29674@kronos.cnri.reston.va.us> [CC'ing to the distutils-sig] On Mon, Jan 15, 2001 at 10:47:32PM -0500, Guido van Rossum wrote: >> For PEP 229, the setup.py script needs to figure out if it's running >> from the build directory, because then distutils.sysconfig needs to > >You could check for the presence of config.status -- that file is not >installed. This isn't a check suitable for inclusion in distutils.sysconfig, though, because it's so liable to being fooled (consider a Distutils-packaged module that comes with a configure script to build some library). Right now I'm using a hacked version of sysconfig with several patches like this: @@ -120,12 +121,16 @@ def get_config_h_filename(): """Return full pathname of installed config.h file.""" inc_dir = get_python_inc(plat_specific=1) + # XXX + if 1: inc_dir = '.' return os.path.join(inc_dir, "config.h") One hackish approach would be to add a assume_build_directories() to distutils.sysconfig, a little back door to be used by the setup.py script that comes with Python, so the above would become 'if build_time_flag: ...'. Anyone have a cleaner idea? --amk From mal@lemburg.com Wed Jan 17 17:25:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Jan 17 17:25:01 2001 Subject: [Distutils] bdist_wininst Message-ID: <3A661A67.980B1F8A@lemburg.com> I've just tried to create a wininst based version of my packages. The installer works great except for a few nits: * the text box showing the description could be wider * no documentation files are installed -- is there a way to get those installed somewhere * the installer install directly into \Python20 -- shouldn't it install to \Python20\Lib ? What's the standard here on Windows ? * the installer doesn't register itself in the Windows Software registry -- an uninstall is not possible (this would be *very* nice to have) Any hints ? -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From pete@visionart.com Wed Jan 17 18:03:11 2001 From: pete@visionart.com (Pete Shinners) Date: Wed Jan 17 18:03:11 2001 Subject: [Distutils] bdist_wininst References: <3A661A67.980B1F8A@lemburg.com> Message-ID: <003c01c080d8$665ebd30$f43f93cd@visionart.com> these aren't bdist related, but general features i'd like to see included with distutils (at some point) :] > * no documentation files are installed -- is there a way to get > those installed somewhere mmm, a python standard location for documentation would be a big help. all my docs are currently in HTML, but i'm sure many people are using a variety of formats. nonetheless, if python had a standard format/location for documentation i think the all users would benefit. perhaps distutils laying out some sort of resonable standard on its own would be enough to get the whole community to adopt it? (of course, some documentation browsing tools in python would be a nice followup) > * the installer doesn't register itself in the Windows Software > registry -- an uninstall is not possible (this would be *very* > nice to have) i was recently noticing some sort of "uninstall" would be a handy feature from the commandline. technically, i would assume distutils could take the list of files to install and simple erase the files instead. then if the containing folder was empty, remove the folder. anyways, back to the bdist specific issues > * the installer install directly into \Python20 -- shouldn't > it install to \Python20\Lib ? What's the standard here on Windows ? distutils on windows always installs to this directory. bdist or otherwise. i don't see any need for change? From thomas.heller@ion-tof.com Thu Jan 18 08:50:59 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Jan 18 08:50:59 2001 Subject: [Distutils] bdist_wininst References: <3A661A67.980B1F8A@lemburg.com> Message-ID: <006601c08122$ae6500e0$e000a8c0@thomasnotebook> > I've just tried to create a wininst based version of my packages. > The installer works great except for a few nits: > > * the text box showing the description could be wider Probably the text shown in this box should be reformatted by bdist_wininst to better fit in the box... Currently the 'packager' has to do it manually. > * no documentation files are installed -- is there a way to get > those installed somewhere wininst follows distutils very closely and does not care about this. > * the installer install directly into \Python20 -- shouldn't > it install to \Python20\Lib ? What's the standard here on Windows ? This is the standard on windows. \Python20\Lib is treated as location for modules belonging to core python. Note that this behaviour has one serious consequence: Since the distutils distributed with python are in \python20\lib\distutils, and installing a new version of distutils will install in \python20\distutils, and c:\python20\lib appears in sys.path *before* c:\python20, it requires special actions to actually *use* this newly installed distutils: The user has to delete or renamed or otherwise disable the directory \python20\lib\distutils. > * the installer doesn't register itself in the Windows Software > registry -- an uninstall is not possible (this would be *very* > nice to have) This is something I have in my mind for a long time, but since distutils itself does not care about uninstalling I've never done it. The hooks are all there in wininst: A callback is called for every action taken on the filesystem during installation. It would be easy to write a log file which could be used for uninstallation. > > Any hints ? > > -- > Marc-Andre Lemburg Regards, Thomas From mal@lemburg.com Thu Jan 18 09:01:45 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu Jan 18 09:01:45 2001 Subject: [Distutils] bdist_wininst References: <3A661A67.980B1F8A@lemburg.com> <006601c08122$ae6500e0$e000a8c0@thomasnotebook> Message-ID: <3A66CBB5.120316FB@lemburg.com> Thomas Heller wrote: > > > I've just tried to create a wininst based version of my packages. > > The installer works great except for a few nits: > > > > * the text box showing the description could be wider > Probably the text shown in this box should be reformatted > by bdist_wininst to better fit in the box... > Currently the 'packager' has to do it manually. > > > * no documentation files are installed -- is there a way to get > > those installed somewhere > wininst follows distutils very closely and does not care about this. Some more testing with the generic distutils install command showed the same behaviour -- I think we have a problem in that area... after all, packages without documentation are not really all that useful. > > * the installer install directly into \Python20 -- shouldn't > > it install to \Python20\Lib ? What's the standard here on Windows ? > This is the standard on windows. \Python20\Lib is treated as location > for modules belonging to core python. > Note that this behaviour has one serious consequence: > Since the distutils distributed with python are in \python20\lib\distutils, > and installing a new version of distutils will install in \python20\distutils, > and c:\python20\lib appears in sys.path *before* c:\python20, > it requires special actions to actually *use* this newly > installed distutils: The user has to delete or renamed or otherwise > disable the directory \python20\lib\distutils. Hmm, I think we should at least install the packages or modules in a special subdir of \Python -- we wouldn't want to clutter up the base installation directory with single modules or other third packages, or would we ? > > * the installer doesn't register itself in the Windows Software > > registry -- an uninstall is not possible (this would be *very* > > nice to have) > This is something I have in my mind for a long time, but > since distutils itself does not care about uninstalling I've never > done it. The hooks are all there in wininst: A callback is called > for every action taken on the filesystem during installation. It > would be easy to write a log file which could be used for uninstallation. Would be "nice to have" for 2.1 ;-) A way to set the installer background bitmap and the one shown in the install dialog would also be nice :) -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Paul.Moore@uk.origin-it.com Thu Jan 18 09:16:53 2001 From: Paul.Moore@uk.origin-it.com (Moore, Paul) Date: Thu Jan 18 09:16:53 2001 Subject: [Distutils] bdist_wininst Message-ID: <714DFA46B9BBD0119CD000805FC1F53B012A84A7@UKRUX002.rundc.uk.origin-it.com> From: Pete Shinners [mailto:pete@visionart.com] > > > * no documentation files are installed -- is there a way to get > > those installed somewhere > > mmm, a python standard location for documentation would be a > big help. all my docs are currently in HTML, but i'm sure many > people are using a variety of formats. nonetheless, if python > had a standard format/location for documentation i think the > all users would benefit. perhaps distutils laying out some sort > of resonable standard on its own would be enough to get the > whole community to adopt it? > (of course, some documentation browsing tools in python would > be a nice followup) Agreed, this would be good. It's not a distutils issue as such, but if the distutils package offered a standard for *where* documentation went, it might help promote some discussion and/or action on defining what *form* documentation should take, etc. Perl currently has a big win here, with POD. Like it or loathe it, it's guaranteed to work for pretty much everything - a bit like man on Unix... > > * the installer install directly into \Python20 -- shouldn't > > it install to \Python20\Lib ? What's the standard here on > > Windows ? > > distutils on windows always installs to this directory. bdist or > otherwise. i don't see any need for change? I asked this once before. I gather that it's a Guido-mandated standard. I dislike it intensely, however. I think that user-installed modules should be segregated from standard ones. The obvious place is \Lib\site-packages. But that needs site.py to change to handle this directory on Windows, as well as on Unix (I see no logic to why it doesn't already). At the very least, \Local would be better, with distutils creating the directory, and probably adding a Local.pth, if it doesn't already exist. I hate this default so much that I *always* download sources, and do python setup.py build, and then install by hand. This is stupid. At the absolute minimum, the install target should allow specifying an alternative target. And the wininst installer needs to offer the user a choice of install directory. Paul. From thomas.heller@ion-tof.com Thu Jan 18 15:04:03 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Jan 18 15:04:03 2001 Subject: [Distutils] bdist_wininst References: <3A661A67.980B1F8A@lemburg.com> <006601c08122$ae6500e0$e000a8c0@thomasnotebook> <3A66CBB5.120316FB@lemburg.com> Message-ID: <01a401c0816c$2aec6380$e000a8c0@thomasnotebook> MAL wrote: > > > * the installer install directly into \Python20 -- shouldn't > > > it install to \Python20\Lib ? What's the standard here on Windows ? > > This is the standard on windows. \Python20\Lib is treated as location > > for modules belonging to core python. > > Note that this behaviour has one serious consequence: > > Since the distutils distributed with python are in \python20\lib\distutils, > > and installing a new version of distutils will install in \python20\distutils, > > and c:\python20\lib appears in sys.path *before* c:\python20, > > it requires special actions to actually *use* this newly > > installed distutils: The user has to delete or renamed or otherwise > > disable the directory \python20\lib\distutils. > > Hmm, I think we should at least install the packages or > modules in a special subdir of \Python -- we wouldn't want > to clutter up the base installation directory with single > modules or other third packages, or would we ? IIRC there has been some discussion about this in the archives, and the current scheme was what Guido wanted. > > > > * the installer doesn't register itself in the Windows Software > > > registry -- an uninstall is not possible (this would be *very* > > > nice to have) > > This is something I have in my mind for a long time, but > > since distutils itself does not care about uninstalling I've never > > done it. The hooks are all there in wininst: A callback is called > > for every action taken on the filesystem during installation. It > > would be easy to write a log file which could be used for uninstallation. > > Would be "nice to have" for 2.1 ;-) A way to set the installer > background bitmap and the one shown in the install dialog would > also be nice :) What's the exact schedule for 2.1? I have implemented a '--bitmap' option for bdist_wininst, which allows to replace the 'python powered' bitmap with a custom one. I'm not yet convinced that we need a way to change the background bitmap because there isn't any ;-) Would you like to test it? Shall I send you a windows installer for this patched distutils version? I fear the uninstaller would take a little longer... Thomas From thomas.heller@ion-tof.com Thu Jan 18 15:15:20 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Jan 18 15:15:20 2001 Subject: [Distutils] bdist_wininst References: <714DFA46B9BBD0119CD000805FC1F53B012A84A7@UKRUX002.rundc.uk.origin-it.com> Message-ID: <01f001c0816e$42c0a140$e000a8c0@thomasnotebook> From: "Moore, Paul" > > > > distutils on windows always installs to this directory. bdist or > > otherwise. i don't see any need for change? > > I asked this once before. I gather that it's a Guido-mandated standard. I > dislike it intensely, however. I think that user-installed modules should be > segregated from standard ones. The obvious place is > \Lib\site-packages. But that needs site.py to change to handle > this directory on Windows, as well as on Unix (I see no logic to why it > doesn't already). At the very least, \Local would be better, with > distutils creating the directory, and probably adding a Local.pth, if it > doesn't already exist. > > I hate this default so much that I *always* download sources, and do python > setup.py build, and then install by hand. This is stupid. > > At the absolute minimum, the install target should allow specifying an > alternative target. And the wininst installer needs to offer the user a > choice of install directory. > wininst once had such an option. I removed it because of Greg's suggestion: The developer can override it by using the 'extra_path' option to the setup function. Thomas From mal@lemburg.com Thu Jan 18 16:11:14 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu Jan 18 16:11:14 2001 Subject: [Distutils] bdist_wininst References: <3A661A67.980B1F8A@lemburg.com> <006601c08122$ae6500e0$e000a8c0@thomasnotebook> <3A66CBB5.120316FB@lemburg.com> <01a401c0816c$2aec6380$e000a8c0@thomasnotebook> Message-ID: <3A6724A0.87840481@lemburg.com> Thomas Heller wrote: > > MAL wrote: > > > > * the installer install directly into \Python20 -- shouldn't > > > > it install to \Python20\Lib ? What's the standard here on Windows ? > > > This is the standard on windows. \Python20\Lib is treated as location > > > for modules belonging to core python. > > > Note that this behaviour has one serious consequence: > > > Since the distutils distributed with python are in \python20\lib\distutils, > > > and installing a new version of distutils will install in \python20\distutils, > > > and c:\python20\lib appears in sys.path *before* c:\python20, > > > it requires special actions to actually *use* this newly > > > installed distutils: The user has to delete or renamed or otherwise > > > disable the directory \python20\lib\distutils. > > > > Hmm, I think we should at least install the packages or > > modules in a special subdir of \Python -- we wouldn't want > > to clutter up the base installation directory with single > > modules or other third packages, or would we ? > IIRC there has been some discussion about this in the archives, > and the current scheme was what Guido wanted. This doesn't seem right... simply dropping modules or packages into \Python will sooner or later cause trouble. > > > > > > * the installer doesn't register itself in the Windows Software > > > > registry -- an uninstall is not possible (this would be *very* > > > > nice to have) > > > This is something I have in my mind for a long time, but > > > since distutils itself does not care about uninstalling I've never > > > done it. The hooks are all there in wininst: A callback is called > > > for every action taken on the filesystem during installation. It > > > would be easy to write a log file which could be used for uninstallation. > > > > Would be "nice to have" for 2.1 ;-) A way to set the installer > > background bitmap and the one shown in the install dialog would > > also be nice :) > What's the exact schedule for 2.1? Last I heard, alpha 1 will ship tomorrow. > I have implemented a '--bitmap' option for bdist_wininst, > which allows to replace the 'python powered' bitmap with a custom one. Cool. > I'm not yet convinced that we need a way to change the background bitmap > because there isn't any ;-) Ok, but at least the text should be changeable :) Bitmaps would still be nice, though. > Would you like to test it? > Shall I send you a windows installer for this patched distutils version? Yes, please. > I fear the uninstaller would take a little longer... ... as long as it's there by the time people will want to deinstall a package, I don't think we have a problem ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Jan 18 16:11:16 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu Jan 18 16:11:16 2001 Subject: [Distutils] bdist_wininst References: <3A661A67.980B1F8A@lemburg.com> <003c01c080d8$665ebd30$f43f93cd@visionart.com> Message-ID: <3A67259D.E7455B3F@lemburg.com> Pete Shinners wrote: > > these aren't bdist related, but general features i'd like to > see included with distutils (at some point) :] > > > * no documentation files are installed -- is there a way to get > > those installed somewhere > > mmm, a python standard location for documentation would be a > big help. all my docs are currently in HTML, but i'm sure many > people are using a variety of formats. nonetheless, if python > had a standard format/location for documentation i think the > all users would benefit. perhaps distutils laying out some sort > of resonable standard on its own would be enough to get the > whole community to adopt it? > (of course, some documentation browsing tools in python would > be a nice followup) Right. I'd suggest to take Martin's approach on Unix and a distutils convention on Windows (e.g. \Python\Site-Docs). > > * the installer doesn't register itself in the Windows Software > > registry -- an uninstall is not possible (this would be *very* > > nice to have) > > i was recently noticing some sort of "uninstall" would be a > handy feature from the commandline. technically, i would > assume distutils could take the list of files to install > and simple erase the files instead. then if the containing > folder was empty, remove the folder. Right, this should work. The install process would have to keep a list of installed files in some standard location (and for each package) though. > anyways, back to the bdist specific issues > > > * the installer install directly into \Python20 -- shouldn't > > it install to \Python20\Lib ? What's the standard here on Windows ? > > distutils on windows always installs to this directory. bdist or > otherwise. i don't see any need for change? See my other post. I don't really think that extensions should go into \Python directly; a directory like the one on Unix would be better, e.g. \Python\Site-Packages, IMHO at least. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From michel.vandenbergh@luc.ac.be Fri Jan 19 06:00:15 2001 From: michel.vandenbergh@luc.ac.be (Michel Van den Bergh) Date: Fri Jan 19 06:00:15 2001 Subject: [Distutils] Re: Distutils-SIG digest, Vol 1 #427 - 5 msgs References: <20010118170129.186EAF660@mail.python.org> Message-ID: <3A67F973.7EA05A5@luc.ac.be> > * the installer install directly into \Python20 -- shouldn't > it install to \Python20\Lib ? What's the standard here on Windows ? Come to think of it. Why not allowing to install anywhere in the file system, like bdist_rpm does? With this trivial change you could use bdist_wininst as an installer for python applications, not just extensions. Michel From Paul.Moore@uk.origin-it.com Fri Jan 19 06:05:11 2001 From: Paul.Moore@uk.origin-it.com (Moore, Paul) Date: Fri Jan 19 06:05:11 2001 Subject: [Distutils] bdist_wininst Message-ID: <714DFA46B9BBD0119CD000805FC1F53B012A84AB@UKRUX002.rundc.uk.origin-it.com> From: Thomas Heller [mailto:thomas.heller@ion-tof.com] > > At the absolute minimum, the install target should allow > > specifying an alternative target. And the wininst installer > > needs to offer the user a choice of install directory. > > > wininst once had such an option. I removed it because of > Greg's suggestion: > > The developer can override it by using the 'extra_path' > option to the setup function. The developer can, but the end user who is installing the package can't. (Can he? I haven't actually looked, but this is how I read the messages...) Paul From thomas.heller@ion-tof.com Fri Jan 19 07:40:03 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Fri Jan 19 07:40:03 2001 Subject: [Distutils] py2exe - convert python scripts into exe files (windows) Message-ID: <018601c08214$8c138460$e000a8c0@thomasnotebook> I've created a distutils extension to convert python scripts into standalone windows executable files. You end up with an exe-file as well as pythonxx.dll plus some .pyd's. This is more or less a rewrite of Gordon's installer project. Homepage: http://starship.python.net/crew/theller/py2exe/ Compatibility: Python 1.5 or later. License: BSD Regards, Thomas Heller From thomas.heller@ion-tof.com Fri Jan 19 08:07:00 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Fri Jan 19 08:07:00 2001 Subject: [Distutils] pre-pre PEP: wininst improvements Message-ID: <022b01c08218$a6360d00$e000a8c0@thomasnotebook> It seems there are a lot of wishes for wininst, maybe it is time to write a bdist_wininst PEP? What I have collected in my mind: - The default installation directory should be \Python\Lib\site-packages instead of \Python. - The installer should be able to install in a directory supplied by the user, comparable to what 'python setup.py --root ' does. - bdist_wininst should have more options to change the appearane of the installer: Background bitmap instead of simply displaying the installation title, possibility to change the 'python powered' bitmap into one supplied by the packager. - bdist_wininst should collect uninstall information and register an uninstaller in the windows registry. - bdist_wininst could create shortcuts in the start menu and on the desktop for scripts ('applications') installed. (I've left out problems which should be more or less solved by distutils: Installation of documentation,...) Are there more? Thomas From mal@lemburg.com Fri Jan 19 08:13:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Jan 19 08:13:01 2001 Subject: [Distutils] bdist_wininst References: <714DFA46B9BBD0119CD000805FC1F53B012A84A7@UKRUX002.rundc.uk.origin-it.com> <01f001c0816e$42c0a140$e000a8c0@thomasnotebook> Message-ID: <3A683D18.76EF69CF@lemburg.com> Thomas Heller wrote: > > From: "Moore, Paul" > > > > > > distutils on windows always installs to this directory. bdist or > > > otherwise. i don't see any need for change? > > > > I asked this once before. I gather that it's a Guido-mandated standard. I > > dislike it intensely, however. I think that user-installed modules should be > > segregated from standard ones. The obvious place is > > \Lib\site-packages. But that needs site.py to change to handle > > this directory on Windows, as well as on Unix (I see no logic to why it > > doesn't already). At the very least, \Local would be better, with > > distutils creating the directory, and probably adding a Local.pth, if it > > doesn't already exist. > > > > I hate this default so much that I *always* download sources, and do python > > setup.py build, and then install by hand. This is stupid. > > > > At the absolute minimum, the install target should allow specifying an > > alternative target. And the wininst installer needs to offer the user a > > choice of install directory. > > > wininst once had such an option. I removed it because of Greg's suggestion: > > The developer can override it by using the 'extra_path' > option to the setup function. I guess it would be possible to put this option into setup.cfg, but we'll still need some standard... otherwise all packages will end up using their own little twist. There's one catch though: extra_path would only be necessary for Windows installations and not for Unix ones. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Fri Jan 19 08:52:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Jan 19 08:52:01 2001 Subject: [Distutils] pre-pre PEP: wininst improvements References: <022b01c08218$a6360d00$e000a8c0@thomasnotebook> Message-ID: <3A6845C4.5D580AC2@lemburg.com> Thomas Heller wrote: > > It seems there are a lot of wishes for wininst, maybe > it is time to write a bdist_wininst PEP? > > What I have collected in my mind: > > - The default installation directory should be \Python\Lib\site-packages > instead of \Python. > > - The installer should be able to install in a directory > supplied by the user, comparable to what > 'python setup.py --root ' does. > > - bdist_wininst should have more options to change > the appearane of the installer: Background bitmap > instead of simply displaying the installation title, > possibility to change the 'python powered' bitmap > into one supplied by the packager. Some more wishes: * there should be a way to add a license agreement page (which is then shown in case a license is passed to the installer via a new option --license-agreement) * the strings shown by the dialogs should come from some .ini file which the maintainer can then change; this would also allow limited i18n > - bdist_wininst should collect uninstall information > and register an uninstaller in the windows registry. > > - bdist_wininst could create shortcuts in the start menu > and on the desktop for scripts ('applications') installed. Would these be the ones you put into scripts or do we need a new option for application entry points ? > (I've left out problems which should be more or less > solved by distutils: Installation of documentation,...) +1 on all of these. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From robin@alldunn.com Fri Jan 19 13:14:04 2001 From: robin@alldunn.com (Robin Dunn) Date: Fri Jan 19 13:14:04 2001 Subject: [Distutils] py2exe - convert python scripts into exe files (windows) References: <018601c08214$8c138460$e000a8c0@thomasnotebook> Message-ID: <005201c08240$1c88d060$1c00000a@Rogue> > I've created a distutils extension to convert python scripts > into standalone windows executable files. > You end up with an exe-file as well as pythonxx.dll > plus some .pyd's. >=20 > This is more or less a rewrite of Gordon's installer project. >=20 > Homepage: http://starship.python.net/crew/theller/py2exe/ >=20 AWESOME! I ran into the inability of Installer to build a debug version = just a couple days ago. (I had a program that ran fine normally but = crashed when in an Installer .exe) Integration with distutils is a nice approach. Thanks! -- Robin Dunn Software Craftsman robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython! From mal@lemburg.com Sat Jan 20 11:00:32 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat Jan 20 11:00:32 2001 Subject: [Distutils] bdist_wininst References: <714DFA46B9BBD0119CD000805FC1F53B012A84AB@UKRUX002.rundc.uk.origin-it.com> Message-ID: <3A6997A8.A1407AEB@lemburg.com> "Moore, Paul" wrote: > > From: Thomas Heller [mailto:thomas.heller@ion-tof.com] > > > At the absolute minimum, the install target should allow > > > specifying an alternative target. And the wininst installer > > > needs to offer the user a choice of install directory. > > > > > wininst once had such an option. I removed it because of > > Greg's suggestion: > > > > The developer can override it by using the 'extra_path' > > option to the setup function. > > The developer can, but the end user who is installing the package can't. > (Can he? I haven't actually looked, but this is how I read the messages...) Since this is an option in the install command, the end user should be able to pass in this option as well. The developer can also put it into the setup.cfg file, so the end user doesn't get bothered. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas.heller@ion-tof.com Tue Jan 23 03:58:00 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue Jan 23 03:58:00 2001 Subject: [Distutils] pre-pre PEP: wininst improvements References: <022b01c08218$a6360d00$e000a8c0@thomasnotebook> <3A6845C4.5D580AC2@lemburg.com> Message-ID: <008f01c0851a$8a3d9730$e000a8c0@thomasnotebook> From: "M.-A. Lemburg" > Thomas Heller wrote: > > > > It seems there are a lot of wishes for wininst, maybe > > it is time to write a bdist_wininst PEP? > > > > What I have collected in my mind: > > > > - The default installation directory should be \Python\Lib\site-packages > > instead of \Python. > > > > - The installer should be able to install in a directory > > supplied by the user, comparable to what > > 'python setup.py --root ' does. > > > > - bdist_wininst should have more options to change > > the appearane of the installer: Background bitmap > > instead of simply displaying the installation title, > > possibility to change the 'python powered' bitmap > > into one supplied by the packager. > > Some more wishes: > > * there should be a way to add a license agreement page > (which is then shown in case a license is passed to the > installer via a new option --license-agreement) > OK. > * the strings shown by the dialogs should come from some > .ini file which the maintainer can then change; this would > also allow limited i18n > I understand it this way: The packager supplies this ini-file with german or spanish strings for example, to build a german resp. a spanish localized installer? > > - bdist_wininst should collect uninstall information > > and register an uninstaller in the windows registry. > > > > - bdist_wininst could create shortcuts in the start menu > > and on the desktop for scripts ('applications') installed. > > Would these be the ones you put into scripts or do we need > a new option for application entry points ? Currently I think the 'scripts' arguments to the setup function would be the entry points. The question is: Does distutils metainfo provide all the information we need or not? Sooner or later someone would want the 'installer' to run a supplied python script which would then create shortcuts and so on. The installer (which embeds python) could export some API do do this and run the installation script after installing the files. > > > (I've left out problems which should be more or less > > solved by distutils: Installation of documentation,...) > > +1 on all of these. > > -- > Marc-Andre Lemburg Thomas From robin@jessikat.fsnet.co.uk Thu Jan 25 09:16:01 2001 From: robin@jessikat.fsnet.co.uk (Robin Becker) Date: Thu Jan 25 09:16:01 2001 Subject: [Distutils] freebsd .a files Message-ID: How do I specify a static library. I have libraries=['gd'], but I don't seem to load symbols from libgd.a instead I have to use libraries=['libgd.a'] is that right? -- Robin Becker From mal@lemburg.com Thu Jan 25 09:32:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu Jan 25 09:32:01 2001 Subject: [Distutils] freebsd .a files References: Message-ID: <3A70387D.9E87B195@lemburg.com> Robin Becker wrote: > > How do I specify a static library. I have libraries=['gd'], but I don't > seem to load symbols from libgd.a instead I have to use > libraries=['libgd.a'] is that right? No, you should use the first variant. The compiler will then either take the correspopnding .so file or .a file with a preference for the shared object file (at least that's what gcc does). See distutils/ccompiler.py for details. In general it is a better idea to link to shared libs since these provide more flexibility on the user side. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From robin@jessikat.fsnet.co.uk Thu Jan 25 10:16:00 2001 From: robin@jessikat.fsnet.co.uk (Robin Becker) Date: Thu Jan 25 10:16:00 2001 Subject: [Distutils] freebsd .a files In-Reply-To: <3A70387D.9E87B195@lemburg.com> References: <3A70387D.9E87B195@lemburg.com> Message-ID: In article <3A70387D.9E87B195@lemburg.com>, M.-A. Lemburg writes >Robin Becker wrote: >> >> How do I specify a static library. I have libraries=['gd'], but I don't >> seem to load symbols from libgd.a instead I have to use >> libraries=['libgd.a'] is that right? > >No, you should use the first variant. The compiler will then either >take the correspopnding .so file or .a file with a preference for the >shared object file (at least that's what gcc does). > >See distutils/ccompiler.py for details. > >In general it is a better idea to link to shared libs since these >provide more flexibility on the user side. > Well when I'm using the first form I don't seem to get the relevant things included in my final shared object. I use nm -a and the thinsg that would come from libgd.a are marked U (ie undefined). Our ISP changed up to 4.1.1 FreeBSD and now I'm having lot's of problems. -- Robin Becker From mal@lemburg.com Thu Jan 25 12:21:00 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu Jan 25 12:21:00 2001 Subject: [Distutils] freebsd .a files References: <3A70387D.9E87B195@lemburg.com> Message-ID: <3A705090.BFA90C16@lemburg.com> Robin Becker wrote: > > In article <3A70387D.9E87B195@lemburg.com>, M.-A. Lemburg > writes > >Robin Becker wrote: > >> > >> How do I specify a static library. I have libraries=['gd'], but I don't > >> seem to load symbols from libgd.a instead I have to use > >> libraries=['libgd.a'] is that right? > > > >No, you should use the first variant. The compiler will then either > >take the correspopnding .so file or .a file with a preference for the > >shared object file (at least that's what gcc does). > > > >See distutils/ccompiler.py for details. > > > >In general it is a better idea to link to shared libs since these > >provide more flexibility on the user side. > > > Well when I'm using the first form I don't seem to get the relevant > things included in my final shared object. I use nm -a and the thinsg > that would come from libgd.a are marked U (ie undefined). That's because the linker put a reference to the shared lib libgd.so into the final shared object. ldd ./module.so will show where the dynamic linker looks for the libgd.so file. > Our ISP > changed up to 4.1.1 FreeBSD and now I'm having lot's of problems. Ah, so you do want to link using the static lib ? This should be possible by placing the 'libgd.a' into the objects option: objects = ['libgd.a'] -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From robin@jessikat.fsnet.co.uk Thu Jan 25 13:36:52 2001 From: robin@jessikat.fsnet.co.uk (Robin Becker) Date: Thu Jan 25 13:36:52 2001 Subject: [Distutils] freebsd .a files In-Reply-To: <3A705090.BFA90C16@lemburg.com> References: <3A70387D.9E87B195@lemburg.com> <3A705090.BFA90C16@lemburg.com> Message-ID: <6CAiZWAVkFc6Ewn2@jessikat.fsnet.co.uk> In article <3A705090.BFA90C16@lemburg.com>, M.-A. Lemburg writes .... > >Ah, so you do want to link using the static lib ? This should >be possible by placing the 'libgd.a' into the objects option: > > objects = ['libgd.a'] > OK that's nice, any idea how to create .a (win32 .lib) files using distutils. Even my .a files have to be rebuilt. -- Robin Becker From pete@visionart.com Thu Jan 25 13:39:21 2001 From: pete@visionart.com (Pete Shinners) Date: Thu Jan 25 13:39:21 2001 Subject: [Distutils] what's new in distutils? Message-ID: <005a01c086fa$7589b940$f43f93cd@visionart.com> i was trying to figure out what changes have been put into distutils since the python2.0 release (distutils 1.01) i looked into the cvs repository on sourceforge, but it doesn't look like anything has been checked in their for over 3 months (since the 1.01 release?) anyways, i've been seeing a lot of enhancements come in over this time, and am just wondering what the state of distutils is in now. also, what are the planned features to make it into the python 2.1 release? From mal@lemburg.com Thu Jan 25 16:17:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu Jan 25 16:17:01 2001 Subject: [Distutils] freebsd .a files References: <3A70387D.9E87B195@lemburg.com> <3A705090.BFA90C16@lemburg.com> <6CAiZWAVkFc6Ewn2@jessikat.fsnet.co.uk> Message-ID: <3A709774.95960C2A@lemburg.com> Robin Becker wrote: > > In article <3A705090.BFA90C16@lemburg.com>, M.-A. Lemburg > writes > .... > > > >Ah, so you do want to link using the static lib ? This should > >be possible by placing the 'libgd.a' into the objects option: > > > > objects = ['libgd.a'] > > > OK that's nice, any idea how to create .a (win32 .lib) files using > distutils. Even my .a files have to be rebuilt. I don't know how well it works, but the build_clib command is supposed to support this. The PIL example in the distutils distribution makes use of this command, AFAIR. BTW, I think the correct option name is "extra_objects" -- I read the code and didn't try this out. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin@mems-exchange.org Thu Jan 25 17:09:01 2001 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Thu Jan 25 17:09:01 2001 Subject: [Distutils] what's new in distutils? In-Reply-To: <005a01c086fa$7589b940$f43f93cd@visionart.com>; from pete@visionart.com on Thu, Jan 25, 2001 at 10:13:03AM -0800 References: <005a01c086fa$7589b940$f43f93cd@visionart.com> Message-ID: <20010125170810.B2187@amarok.cnri.reston.va.us> On Thu, Jan 25, 2001 at 10:13:03AM -0800, Pete Shinners wrote: >anyways, i've been seeing a lot of enhancements come in >over this time, and am just wondering what the state of >distutils is in now. also, what are the planned features >to make it into the python 2.1 release? Most of these are minor bugfixes, or support for a new compiler platform such as Metrowerks on the Mac. There are no new features as such, to my knowledge, and I'm not to go about adding any right now. (Greg, are you keeping up to date with Distutils-SIG traffic again?) --amk From phrxy@csv.warwick.ac.uk Fri Jan 26 16:38:34 2001 From: phrxy@csv.warwick.ac.uk (John J. Lee) Date: Fri Jan 26 16:38:34 2001 Subject: [Distutils] freebsd .a files In-Reply-To: <3A709774.95960C2A@lemburg.com> Message-ID: On Thu, 25 Jan 2001, M.-A. Lemburg wrote: > Robin Becker wrote: > > > > In article <3A705090.BFA90C16@lemburg.com>, M.-A. Lemburg > > writes > > .... > > > > > >Ah, so you do want to link using the static lib ? This should > > >be possible by placing the 'libgd.a' into the objects option: > > > > > > objects = ['libgd.a'] > > > > > OK that's nice, any idea how to create .a (win32 .lib) files using > > distutils. Even my .a files have to be rebuilt. > > I don't know how well it works, but the build_clib command > is supposed to support this. The PIL example in the distutils > distribution makes use of this command, AFAIR. [...] I think I used libraries = [blah blah] but that was for shared libraries, and I can't remember what you put in the list. Look in the subdirectory in the source (there's only one) in build_clib.py or something similar. The source is extremely readable. John From dgoodger@atsautomation.com Fri Jan 26 17:00:01 2001 From: dgoodger@atsautomation.com (Goodger, David) Date: Fri Jan 26 17:00:01 2001 Subject: [Distutils] problems building Python 2.1a1 on QNX 4.25 Message-ID: [Already sent to python-dev; forwarding it at Guido's suggestion.] [CC'ing to Armin Steinhoff, who maintains pyqnx on SourceForge.] I'm having trouble building Python 2.1a1 on QNX 4.25. Caveat: my C is very rusty (long live Python!), I don't know my way around configure, and am not familiar with Python's Makefile. Python 2.0 compiled fine (with a couple of tweaks), but I'm getting caught by the new way of building things. Please help if you can! Many thanks in advance. Here's an excerpt of my efforts: # cd /tmp/py # gunzip -c < python-2.1a1.tgz | tar -rf - # cd Python-2.1a1 # ./configure 2>&1 | tee ../configure.1 # make 2>&1 | tee ../make.1 ... ./python //5/tmp/py/Python-2.1a1/setup.py build 'import site' failed; use -v for traceback Traceback (most recent call last): File "//5/tmp/py/Python-2.1a1/setup.py", line 4, in ? import sys, os, string, getopt ImportError: No module named string Running ./python results in stack overflow. The old QNX instructions in README recommend editing Modules/Makefile: LDFLAGS= -N 64k # make 2>&1 | tee ../make.2 Same error as first make. But now the stack doesn't overflow. # python 'import site' failed; use -v for traceback Python 2.1a1 (#2, Jan 26 2001, 11:38:55) [C] on qnxJ Type "copyright", "credits" or "license" for more information. >>> import sys >>> sys.path ['', '/usr/local/lib/python', '/home/dgoodger/lib/python', '/5/tmp/py/Python-2.1a1/Lib', '/5/tmp/py/Python-2.1a1/Lib/plat-qnxJ', '/tmp/py/Python-2.1a1/Modules'] >>> ^D # fullpath . . is //5/tmp/py/Python-2.1a1 The QNX node number prefix '//5' (machine or host number, equivalent to a 'hostname:' prefix for network paths) is being reduced somehow (path normalization?) to '/5', so paths don't resolve. 2 slashes ('//') are required at the head of the path. Is this something that can be fixed? I added a prefix (QNX virtual-to-real path mapping on the filesystem tree) to correct this: # prefix -A /5=//5 Now /5 points to //5, similar to a link. # make 2>&1 | tee ../make.3 ... ./python //5/tmp/py/Python-2.1a1/setup.py build unable to execute ld: No such file or directory running build running build_ext building 'struct' extension creating build creating build/temp.qnx-J-PCI-2.1 cc -O -I. -I/5/tmp/py/Python-2.1a1/./Include -IInclude/ -I/usr/local/include -c /5/tmp/py/Python-2.1a1/Modules/structmodule.c -o build/temp.qnx-J-PCI-2.1/structmodule.o creating build/lib.qnx-J-PCI-2.1 ld build/temp.qnx-J-PCI-2.1/structmodule.o -L/usr/local/lib -o build/lib.qnx-J-PCI-2.1/struct.so error: command 'ld' failed with exit status 1 make: *** [sharedmods] Error 1 QNX doesn't have an 'ld' command. Is configure not getting its info to setup.py? (Is it supposed to?) What should I check? I have logs of each of the configure & make runs. Should I submit this as a bug on SourceForge? Hope to hear from somebody soon. David Goodger Systems Administrator & Programmer, Advanced Systems Automation Tooling Systems Inc., Automation Systems Division direct: (519) 653-4483 ext. 7121 fax: (519) 650-6695 e-mail: dgoodger@atsautomation.com From robin@jessikat.fsnet.co.uk Fri Jan 26 18:20:02 2001 From: robin@jessikat.fsnet.co.uk (Robin Becker) Date: Fri Jan 26 18:20:02 2001 Subject: [Distutils] freebsd .a files In-Reply-To: References: <3A709774.95960C2A@lemburg.com> Message-ID: In article , John J. Lee writes >On Thu, 25 Jan 2001, M.-A. Lemburg wrote: > >> Robin Becker wrote: >> > >> > In article <3A705090.BFA90C16@lemburg.com>, M.-A. Lemburg >> > writes >> > .... >> > > >> > >Ah, so you do want to link using the static lib ? This should >> > >be possible by placing the 'libgd.a' into the objects option: >> > > >> > > objects = ['libgd.a'] >> > > >> > OK that's nice, any idea how to create .a (win32 .lib) files using >> > distutils. Even my .a files have to be rebuilt. >> >> I don't know how well it works, but the build_clib command >> is supposed to support this. The PIL example in the distutils >> distribution makes use of this command, AFAIR. >[...] > >I think I used > >libraries = [blah blah] > >but that was for shared libraries, and I can't remember what you put in >the list. Look in the subdirectory in the source (there's only one) in >build_clib.py or something similar. The source is extremely readable. > > >John > > extra_objects=['libgd.a'] works for me, but I still don't know how to define a clib and get it built as part of an extension. -- Robin Becker From phrxy@csv.warwick.ac.uk Sun Jan 28 12:47:01 2001 From: phrxy@csv.warwick.ac.uk (John J. Lee) Date: Sun Jan 28 12:47:01 2001 Subject: [Distutils] freebsd .a files In-Reply-To: Message-ID: On Fri, 26 Jan 2001, Robin Becker wrote: > In article c.uk>, John J. Lee writes [...] > >I think I used > > > >libraries = [blah blah] > > > >but that was for shared libraries, and I can't remember what you put in [...] No it wasn't. Sorry, I'm new to all this library building stuff as you can tell, and I'm not entirely clear on the machinery. libraries=[stuff] does build .a's. I'll check later today what exactly 'stuff' is. > extra_objects=['libgd.a'] works for me, but I still don't know how to > define a clib and get it built as part of an extension. [...] John From thomas.heller@ion-tof.com Mon Jan 29 02:57:00 2001 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Mon Jan 29 02:57:00 2001 Subject: [Distutils] freebsd .a files References: <3A709774.95960C2A@lemburg.com> Message-ID: <002c01c089c8$ebab7200$e000a8c0@thomasnotebook> setup( ....., libraries = [ ("mylib", {"sources": ["source/1.c", "source/2.c"], "include_dirs": ["source/include"], "macros": [("_WINDOWS", None)], }, ), ], ......) builds a static library which you can pass to your extensions module. Thomas From robin@jessikat.fsnet.co.uk Mon Jan 29 04:53:01 2001 From: robin@jessikat.fsnet.co.uk (Robin Becker) Date: Mon Jan 29 04:53:01 2001 Subject: [Distutils] freebsd .a files In-Reply-To: <002c01c089c8$ebab7200$e000a8c0@thomasnotebook> References: <3A709774.95960C2A@lemburg.com> <002c01c089c8$ebab7200$e000a8c0@thomasnotebook> Message-ID: In article <002c01c089c8$ebab7200$e000a8c0@thomasnotebook>, Thomas Heller writes >setup( > ....., > libraries = [ > ("mylib", > {"sources": ["source/1.c", "source/2.c"], > "include_dirs": ["source/include"], > "macros": [("_WINDOWS", None)], > }, > ), > ], > ......) > >builds a static library which you can pass to your extensions >module. > >Thomas > > that's what I'm looking for. -- Robin Becker From Tony Seward Tue Jan 30 11:27:01 2001 From: Tony Seward (Tony Seward) Date: Tue Jan 30 11:27:01 2001 Subject: [Distutils] Proposal: passing options to SWIG Message-ID: I would like to propose adding a command line option to build_ext that would pass options to SWIG. The syntax would be something like --swig-opts='-shadow'. I have some code working and I would like to get comments, especially from the Distutils maintainers, before I submit something to SourceForge. Tony