From flo@via.ecp.fr Sun Mar 3 18:40:01 2002 From: flo@via.ecp.fr (Florent Rougon) Date: Sun Mar 3 18:40:01 2002 Subject: [Distutils] Compilation of extension modules Message-ID: <87sn7h5iiu.fsf@florent.hn.org> --=-=-= Hello, I am currently packaging an extension module that uses the glib library. The correct way to compile such a program is: gcc `glib-config --cflags` ... -c ... -o ... That is, the output of "glib-config --cflags" must be near the beginning of the compilation command (it usually contains -I options). I tried to use the extra_compile_args argument to Extension's __init__() method but it only adds arguments to the end of the compilation command. I looked into Distutils' sources and found that the extra_preargs argument to UnixCCompiler.compile() would do the trick, but it can't be set from Extension's __init__() method. When the compile() method is called in build_ext.py, no extra_preargs is passed, so it always gets its default value: None. Currently, I adopted the following "solution": strip the leading -I from each argument output by "glib-config --cflags" and give it as include_dirs to Extension.__init__(). This is somewhat ugly since the output of "glib-config --cflags" could contain arguments that are not include directory specifications. My hack would fail in such cases. Is there a better solution I couldn't see? I searched the mailing-list archive and didn't find anything really satisfactory. If not, could we consider adding the possibility of specifying some-arguments-of-any-kind (not only include dirs of macros or whatever) to be put near the beginning of the compilation command from the setup() call? [ BTW, there is a similar issue with linking, but as `glib-config --libs` is OK at the end of the link command line, extra_link_args does the trick. However, it would be nice to be able to customize the beginning if the link command. ] Thank you for your comments. Here is my current setup.py. --=-=-= Content-Disposition: attachment; filename=setup.py #! /usr/bin/env python # setup.py --- Setup script for Python-XMMS # Copyright (c) 2002 Florent Rougon # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2, or (at your option) # any later version. # # This program is distributed in the hope that it will be useful, but # WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; see the file COPYING. If not, write to the # Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, # MA 02111-1307, USA. import os, string, sys from distutils.core import setup, Extension # Notes: # 1) The Distutils included in Python 2.1 don't understand the "license" # keyword argument of setup correctly (they only understand licence); as I # don't want to mispell it, if you run the Distutils from Python 2.1, you # will get License: UNKNOWN. # 2) I would like to use the keyword argument "extra_compile_args" of setup to # pass the output of glib-config --cflags to Distutils but it goes to the # end of the gcc command, which is useless in this case. So, I use # "include_dirs" instead. GLIB_CONFIG = "glib-config" glib_opts = {} for op in ("cflags", "libs"): glib_config_pipe = os.popen("%s --%s" % (GLIB_CONFIG, op), 'r') glib_opts[op] = glib_config_pipe.read()[:-1] # strip the trailing newline if glib_config_pipe.close() != None: sys.exit("%s returned a non-zero exit status. Aborting." % GLIB_CONFIG) # Suppress the -I in each -Idir output by glib-config --cflags (ugly) glib_include_dirs = map(lambda s: s[2:], string.split(glib_opts["cflags"], ' ')) setup(name="Python-XMMS", version="1.0", description="A Python interface to XMMS", author="Florent Rougon", author_email="flo@via.ecp.fr", maintainer="Florent Rougon", maintainer_email="flo@via.ecp.fr", url="http://www.via.ecp.fr/~flo/", license="GPL", platforms="Unix", long_description = """\ A Python interface to XMMS consisting of all the xmms_remote_* functions from libxmms plus some higher-level functions. This should provide anything needed to control XMMS from an external program.""", py_modules=["xmms"], ext_modules=[Extension("_xmms", ["_xmmsmodule.c"], include_dirs=glib_include_dirs, libraries=["xmms"], extra_link_args=[glib_opts["libs"]])]) --=-=-= -- Florent --=-=-=-- From gregor@hoffleit.de Mon Mar 4 11:57:01 2002 From: gregor@hoffleit.de (Gregor Hoffleit) Date: Mon Mar 4 11:57:01 2002 Subject: [Distutils] Cygwin to build modules for the Win32 Python2.2 distribution ? Message-ID: <20020304165557.GA748@hal.mediasupervision.de> Hi, I'm trying to build an extension module for the Python22.exe distribution from www.python.org. I'm using a current Cygwin environment and a trivial Distutils setup.py script. The build fails, appearently during a sanity check for LONG_BIT. AFAICS, the failure is due to differences between the VC compiler used for Python22.exe, and the GCC 2.95.4 using in Cygwin: madonna:1> python setup.py build --compiler=cygwin running build running build_ext building 'leapi' extension C:\cygwin\bin\gcc.exe -mcygwin -mdll -O -Wall -I/usr/local/stow/leapi/include -IC:\PROGRAMME\PYTHON22\include -c leapi_wrap.c -o build\temp.win32-2.2\Release\leapi_wrap.o In file included from C:/PROGRAMME/PYTHON22/include/Python.h:59, from leapi_wrap.c:35: C:/PROGRAMME/PYTHON22/include/pyport.h:437: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." error: command 'gcc' failed with exit status 1 Is Distutils supposed to support this situation ? (From what I understand from other mailing lists, it is possible to setup the Cygwin GCC in order to build extensions modules compatible with Python22.exe.) Are there any additional switches to tune Distutils for this situation ? Thanks, Gregor From fdrake@acm.org Tue Mar 5 02:08:02 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue Mar 5 02:08:02 2002 Subject: [Distutils] specifying headers for an extension Message-ID: <15492.28149.282471.141772@grendel.zope.com> When building an extension, how do I specify that some C header files should be considered part of the sources for the purpose of dependency checking? I can't include them with the list of C files: running build_ext building '_datetime' extension error: unknown file type '.h' (from 'datetime.h') make: *** [_datetime.so] Error 1 and just specifying their location isn't the right thing either. I want the .o file to be re-built if the header changes. I didn't see anything about this in the docs. If someone can point me in the right direction, I can update the docs so others can find this information. Thanks! -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From thomas.heller@ion-tof.com Tue Mar 5 02:32:01 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue Mar 5 02:32:01 2002 Subject: [Distutils] specifying headers for an extension References: <15492.28149.282471.141772@grendel.zope.com> Message-ID: <02bf01c1c417$b06cb250$e000a8c0@thomasnotebook> From: "Fred L. Drake, Jr." > > When building an extension, how do I specify that some C header files > should be considered part of the sources for the purpose of dependency > checking? I can't include them with the list of C files: > > running build_ext > building '_datetime' extension > error: unknown file type '.h' (from 'datetime.h') > make: *** [_datetime.so] Error 1 > > and just specifying their location isn't the right thing either. I > want the .o file to be re-built if the header changes. AFAIK, you cannot. Thomas From Achim.Gaedke@uni-koeln.de Tue Mar 5 04:19:00 2002 From: Achim.Gaedke@uni-koeln.de (Achim Gaedke) Date: Tue Mar 5 04:19:00 2002 Subject: [Distutils] specifying headers for an extension References: <15492.28149.282471.141772@grendel.zope.com> <02bf01c1c417$b06cb250$e000a8c0@thomasnotebook> Message-ID: <3C848C3C.262BCD6F@uni-koeln.de> I need such things too. In my case there is the module initialisation in the *module.c file and some 100 of method definitions in another that is included into the first. It would be nice if setup.py can handle this. Thomas Heller schrieb: > > From: "Fred L. Drake, Jr." > > > > When building an extension, how do I specify that some C header files > > should be considered part of the sources for the purpose of dependency > > checking? I can't include them with the list of C files: > > > > running build_ext > > building '_datetime' extension > > error: unknown file type '.h' (from 'datetime.h') > > make: *** [_datetime.so] Error 1 > > > > and just specifying their location isn't the right thing either. I > > want the .o file to be re-built if the header changes. > > AFAIK, you cannot. > > Thomas > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig From mwh@python.net Tue Mar 5 04:42:02 2002 From: mwh@python.net (Michael Hudson) Date: Tue Mar 5 04:42:02 2002 Subject: [Distutils] Cygwin to build modules for the Win32 Python2.2 distribution ? In-Reply-To: Gregor Hoffleit's message of "Mon, 4 Mar 2002 17:55:58 +0100" References: <20020304165557.GA748@hal.mediasupervision.de> Message-ID: <2mk7srnyga.fsf@starship.python.net> Gregor Hoffleit writes: > Hi, > > I'm trying to build an extension module for the Python22.exe > distribution from www.python.org. I'm using a current Cygwin environment > and a trivial Distutils setup.py script. > > The build fails, appearently during a sanity check for LONG_BIT. AFAICS, > the failure is due to differences between the VC compiler used for > Python22.exe, and the GCC 2.95.4 using in Cygwin: > > madonna:1> python setup.py build --compiler=cygwin Try --compiler=mingw32. What you have there certainly isn't going to work. Cheers, M. -- I have a feeling that any simple problem can be made arbitrarily difficult by imposing a suitably heavy administrative process around the development. -- Joe Armstrong, comp.lang.functional From mwh@python.net Tue Mar 5 04:43:05 2002 From: mwh@python.net (Michael Hudson) Date: Tue Mar 5 04:43:05 2002 Subject: [Distutils] specifying headers for an extension In-Reply-To: Achim Gaedke's message of "Tue, 05 Mar 2002 10:13:33 +0100" References: <15492.28149.282471.141772@grendel.zope.com> <02bf01c1c417$b06cb250$e000a8c0@thomasnotebook> <3C848C3C.262BCD6F@uni-koeln.de> Message-ID: <2mhenvnyeh.fsf@starship.python.net> Achim Gaedke writes: > I need such things too. > In my case there is the module initialisation in the *module.c file > and some 100 of method definitions in another that is included into > the first. > > It would be nice if setup.py can handle this. There's a bug on sf on this, assigned to me. I'm not likely to get to it soon, I'm afraid. Patches welcome :) Cheers, M. -- ... but I guess there are some things that are so gross you just have to forget, or it'll destroy something within you. perl is the first such thing I have known. -- Erik Naggum, comp.lang.lisp From R.Liebscher@gmx.de Tue Mar 5 05:25:01 2002 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Tue Mar 5 05:25:01 2002 Subject: [Distutils] specifying headers for an extension References: <15492.28149.282471.141772@grendel.zope.com> <02bf01c1c417$b06cb250$e000a8c0@thomasnotebook> <3C848C3C.262BCD6F@uni-koeln.de> <2mhenvnyeh.fsf@starship.python.net> Message-ID: <3C849D73.61B92438@gmx.de> Michael Hudson wrote: > > Achim Gaedke writes: > > > I need such things too. > > > In my case there is the module initialisation in the *module.c file > > and some 100 of method definitions in another that is included into > > the first. > > > > It would be nice if setup.py can handle this. > > There's a bug on sf on this, assigned to me. I'm not likely to get to > it soon, I'm afraid. Patches welcome :) > > Cheers, > M. > Not a finished patch but some ideas for it. See at http://mail.python.org/pipermail/distutils-sig/2000-December/001785.html http://mail.python.org/pipermail/distutils-sig/2000-December/001786.html Rene From thomas.heller@ion-tof.com Tue Mar 5 05:33:02 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue Mar 5 05:33:02 2002 Subject: [Distutils] specifying headers for an extension References: <15492.28149.282471.141772@grendel.zope.com> <02bf01c1c417$b06cb250$e000a8c0@thomasnotebook> <3C848C3C.262BCD6F@uni-koeln.de> <2mhenvnyeh.fsf@starship.python.net> Message-ID: <04f501c1c430$e052ed90$e000a8c0@thomasnotebook> From: "Michael Hudson" > Achim Gaedke writes: > > > I need such things too. > > > In my case there is the module initialisation in the *module.c file > > and some 100 of method definitions in another that is included into > > the first. > > > > It would be nice if setup.py can handle this. > > There's a bug on sf on this, assigned to me. I'm not likely to get to > it soon, I'm afraid. Patches welcome :) > IMO we should allow sources to be instances of a SourceFile class in addition to strings. Extension(..., sources = SourceFile("spam.c", depends=["spam.h", "spam2.h"])) I can supply a patch if needed. Thomas From mwh@python.net Tue Mar 5 08:51:02 2002 From: mwh@python.net (Michael Hudson) Date: Tue Mar 5 08:51:02 2002 Subject: [Distutils] specifying headers for an extension In-Reply-To: "Thomas Heller"'s message of "Tue, 5 Mar 2002 11:31:14 +0100" References: <15492.28149.282471.141772@grendel.zope.com> <02bf01c1c417$b06cb250$e000a8c0@thomasnotebook> <3C848C3C.262BCD6F@uni-koeln.de> <2mhenvnyeh.fsf@starship.python.net> <04f501c1c430$e052ed90$e000a8c0@thomasnotebook> Message-ID: <2msn7frumv.fsf@starship.python.net> "Thomas Heller" writes: > From: "Michael Hudson" > > Achim Gaedke writes: > > > > > I need such things too. > > > > > In my case there is the module initialisation in the *module.c file > > > and some 100 of method definitions in another that is included into > > > the first. > > > > > > It would be nice if setup.py can handle this. > > > > There's a bug on sf on this, assigned to me. I'm not likely to get to > > it soon, I'm afraid. Patches welcome :) > > > IMO we should allow sources to be instances of a SourceFile class > in addition to strings. > > Extension(..., > sources = SourceFile("spam.c", depends=["spam.h", "spam2.h"])) You mean sources = [SourceFile("spam.c", depends=["spam.h", "spam2.h"])]) here, right? > I can supply a patch if needed. That's the only way this is going to get done... I had some crazy ideas to use "gcc -MMD" to create a database of dependencies, so this sort of thing could be done automagically, but this is work. Somebody print "keep it simple, stupid" on a ream of paper and drop it on my head, please? Cheers, M. -- I've even been known to get Marmite *near* my mouth -- but never actually in it yet. Vegamite is right out. UnicodeError: ASCII unpalatable error: vegamite found, ham expected -- Tim Peters, comp.lang.python From fdrake@acm.org Tue Mar 5 09:14:00 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue Mar 5 09:14:00 2002 Subject: [Distutils] specifying headers for an extension In-Reply-To: <04f501c1c430$e052ed90$e000a8c0@thomasnotebook> References: <15492.28149.282471.141772@grendel.zope.com> <02bf01c1c417$b06cb250$e000a8c0@thomasnotebook> <3C848C3C.262BCD6F@uni-koeln.de> <2mhenvnyeh.fsf@starship.python.net> <04f501c1c430$e052ed90$e000a8c0@thomasnotebook> Message-ID: <15492.53723.934920.209362@grendel.zope.com> Thomas Heller writes: > IMO we should allow sources to be instances of a SourceFile class > in addition to strings. ... > I can supply a patch if needed. I'd be happy with this solution, and can help test the patch. ;-) Feel free to assign it to me on SF, and bump the priority to 7. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From thomas.heller@ion-tof.com Tue Mar 5 09:15:11 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue Mar 5 09:15:11 2002 Subject: [Distutils] specifying headers for an extension References: <15492.28149.282471.141772@grendel.zope.com> <02bf01c1c417$b06cb250$e000a8c0@thomasnotebook> <3C848C3C.262BCD6F@uni-koeln.de> <2mhenvnyeh.fsf@starship.python.net> <04f501c1c430$e052ed90$e000a8c0@thomasnotebook> <2msn7frumv.fsf@starship.python.net> Message-ID: <068401c1c44f$e7efd6c0$e000a8c0@thomasnotebook> > > Extension(..., > > sources = SourceFile("spam.c", depends=["spam.h", "spam2.h"])) > > > You mean > > sources = [SourceFile("spam.c", depends=["spam.h", "spam2.h"])]) > > here, right? Sure. > > > I can supply a patch if needed. > > That's the only way this is going to get done... Ok, will do. > I had some crazy ideas to use "gcc -MMD" to create a database of > dependencies, so this sort of thing could be done automagically, but > this is work. Even more work than it may seem first, because it has to be done for other compilers as well... Thomas From thomas.heller@ion-tof.com Tue Mar 5 09:17:01 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue Mar 5 09:17:01 2002 Subject: [Distutils] specifying headers for an extension References: <15492.28149.282471.141772@grendel.zope.com><02bf01c1c417$b06cb250$e000a8c0@thomasnotebook><3C848C3C.262BCD6F@uni-koeln.de><2mhenvnyeh.fsf@starship.python.net><04f501c1c430$e052ed90$e000a8c0@thomasnotebook> <15492.53723.934920.209362@grendel.zope.com> Message-ID: <069801c1c450$3c152110$e000a8c0@thomasnotebook> From: "Fred L. Drake, Jr." > > Thomas Heller writes: > > IMO we should allow sources to be instances of a SourceFile class > > in addition to strings. > ... > > I can supply a patch if needed. > > I'd be happy with this solution, and can help test the patch. ;-) > Feel free to assign it to me on SF, and bump the priority to 7. > Great. You could also write the docs ;-) Thomas From mwh@python.net Tue Mar 5 09:20:02 2002 From: mwh@python.net (Michael Hudson) Date: Tue Mar 5 09:20:02 2002 Subject: [Distutils] specifying headers for an extension In-Reply-To: "Thomas Heller"'s message of "Tue, 5 Mar 2002 15:13:21 +0100" References: <15492.28149.282471.141772@grendel.zope.com> <02bf01c1c417$b06cb250$e000a8c0@thomasnotebook> <3C848C3C.262BCD6F@uni-koeln.de> <2mhenvnyeh.fsf@starship.python.net> <04f501c1c430$e052ed90$e000a8c0@thomasnotebook> <2msn7frumv.fsf@starship.python.net> <068401c1c44f$e7efd6c0$e000a8c0@thomasnotebook> Message-ID: <2mr8mzm70c.fsf@starship.python.net> "Thomas Heller" writes: > > > I can supply a patch if needed. > > > > That's the only way this is going to get done... > Ok, will do. Cool. > > I had some crazy ideas to use "gcc -MMD" to create a database of > > dependencies, so this sort of thing could be done automagically, but > > this is work. > > Even more work than it may seem first, because it has to be done for > other compilers as well... Well, perhaps, but I was thinking that you could just send your package to someone who uses gcc who can then email you the pickled dependency info back... Cheers, M. -- Worryingly, DEFUN appears to be a function that removes all the fun from something: after using it all your code is converted to C++. -- Tim Bradshaw, comp.lang.lisp From fdrake@acm.org Tue Mar 5 09:40:01 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue Mar 5 09:40:01 2002 Subject: [Distutils] specifying headers for an extension In-Reply-To: <069801c1c450$3c152110$e000a8c0@thomasnotebook> References: <15492.28149.282471.141772@grendel.zope.com> <02bf01c1c417$b06cb250$e000a8c0@thomasnotebook> <3C848C3C.262BCD6F@uni-koeln.de> <2mhenvnyeh.fsf@starship.python.net> <04f501c1c430$e052ed90$e000a8c0@thomasnotebook> <15492.53723.934920.209362@grendel.zope.com> <069801c1c450$3c152110$e000a8c0@thomasnotebook> Message-ID: <15492.55248.598633.84938@grendel.zope.com> Thomas Heller writes: > Great. You could also write the docs ;-) I'd be glad to! -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From mal@lemburg.com Tue Mar 5 11:55:02 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue Mar 5 11:55:02 2002 Subject: [Distutils] New packagers Message-ID: <3C84F88D.913878EF@lemburg.com> Marc Alexandar has submitted two new packagers for distutils a while ago. I would like to add these to distutils, however, I can't test them. Solaris: https://sourceforge.net/tracker/?func=detail&aid=415227&group_id=5470&atid=305470 HP-UX: https://sourceforge.net/tracker/?func=detail&aid=415228&group_id=5470&atid=305470 Could someone give them a go ? Also, docs are still missing for the packagers -- if someone has a few spare cycles, please add these to the patches. Thanks, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From slash@dotnetslash.net Tue Mar 5 12:49:01 2002 From: slash@dotnetslash.net (Mark W. Alexander) Date: Tue Mar 5 12:49:01 2002 Subject: [Distutils] New packagers In-Reply-To: <3C84F88D.913878EF@lemburg.com> Message-ID: On Tue, 5 Mar 2002, M.-A. Lemburg wrote: > Marc Alexandar has submitted two new packagers for distutils > a while ago. I would like to add these to distutils, however, > I can't test them. > > Solaris: > https://sourceforge.net/tracker/?func=detail&aid=415227&group_id=5470&atid=305470 > > HP-UX: > https://sourceforge.net/tracker/?func=detail&aid=415228&group_id=5470&atid=305470 They both require the generic bdist_packager class as well: https://sourceforge.net/tracker/?func=detail&aid=415226&group_id=5470&atid=305470 All 3 are independent files have have no impact on any other modules. Assuming they work as advertised for someone besides me, I'll add a patch to include them in format_command. > Could someone give them a go ? I'm actually behind (just got python 2.2 on my Solaris boxes, we're moving away from HP so I've been completely ignoring them), so I need to get the latest distutils and make sure they still fit right. But if anyone finds problems I'll work through them as fast as I can. > Also, docs are still missing for the packagers -- if someone > has a few spare cycles, please add these to the patches. Are there any guidelines for packager docs anywhere? I'll make the cycles if I can get a kickstart. Mark (with a K, btw) p.s. Thanks for prodding these through. They Work For Me (TM), but I'd like to have "official" support for more platforms in distutils... From mal@lemburg.com Tue Mar 5 12:59:01 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue Mar 5 12:59:01 2002 Subject: [Distutils] New packagers References: Message-ID: <3C850773.13631C17@lemburg.com> "Mark W. Alexander" wrote: > > On Tue, 5 Mar 2002, M.-A. Lemburg wrote: > > > Marc Alexandar has submitted two new packagers for distutils > > a while ago. I would like to add these to distutils, however, > > I can't test them. > > > > Solaris: > > https://sourceforge.net/tracker/?func=detail&aid=415227&group_id=5470&atid=305470 > > > > HP-UX: > > https://sourceforge.net/tracker/?func=detail&aid=415228&group_id=5470&atid=305470 > > They both require the generic bdist_packager class as well: > https://sourceforge.net/tracker/?func=detail&aid=415226&group_id=5470&atid=305470 > > All 3 are independent files have have no impact on any other modules. > Assuming they work as advertised for someone besides me, I'll add a > patch to include them in format_command. I just assigned that patch to myself as well. Perhaps you could just send me your latest versions as ZIP-file ?! > > Could someone give them a go ? > > I'm actually behind (just got python 2.2 on my Solaris boxes, we're > moving away from HP so I've been completely ignoring them), so I > need to get the latest distutils and make sure they still fit right. > But if anyone finds problems I'll work through them as fast as I can. > > > Also, docs are still missing for the packagers -- if someone > > has a few spare cycles, please add these to the patches. > > Are there any guidelines for packager docs anywhere? I'll make the > cycles if I can get a kickstart. The docs are in Latex and can be found in CVS under Docs/dist. I'd suggest adding new sections "Creating Solaris Packages" and "Creating HP-UX Packages" which basically "work" like the "Creating RPM Packges" section. > Mark (with a K, btw) Oops, sorry about that. > p.s. Thanks for prodding these through. They Work For Me (TM), but I'd > like to have "official" support for more platforms in distutils... Same here. I think distutils should have "native" support for packagers on as many platforms as possible. We still need FreeBSD, OpenBSD, Debian and AIX... any takers ? It would also be nice if we had a distutils compile farm somewhere; oh well, this will probably stay a dream. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From thomas.heller@ion-tof.com Tue Mar 5 16:14:04 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue Mar 5 16:14:04 2002 Subject: [Distutils] New packagers References: <3C850773.13631C17@lemburg.com> Message-ID: <03a001c1c48a$6ce54420$e000a8c0@thomasnotebook> > It would also be nice if we had a distutils compile farm > somewhere; oh well, this will probably stay a dream. > I've also thought about this: submit packages (per email, maybe) to a server somewhere, and the server runs 'setup.py bdist --formats=whatever', and mails the result back. My question is: Can this really be made safe? Thomas From mwh@python.net Wed Mar 6 05:16:01 2002 From: mwh@python.net (Michael Hudson) Date: Wed Mar 6 05:16:01 2002 Subject: [Distutils] New packagers In-Reply-To: "Thomas Heller"'s message of "Tue, 5 Mar 2002 22:12:15 +0100" References: <3C850773.13631C17@lemburg.com> <03a001c1c48a$6ce54420$e000a8c0@thomasnotebook> Message-ID: <2mofi2gfyv.fsf@starship.python.net> "Thomas Heller" writes: > > It would also be nice if we had a distutils compile farm > > somewhere; oh well, this will probably stay a dream. > > > > I've also thought about this: submit packages (per email, maybe) to > a server somewhere, and the server runs 'setup.py bdist > --formats=whatever', and mails the result back. My question is: Can > this really be made safe? Seems very unlikely. Cheers, M. -- This is not to say C++ = bad, Lisp = good. It's to say C++ = bad irrespective of everything else. -- Alain Picard, comp.lang.lisp From mal@lemburg.com Wed Mar 6 06:18:10 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Mar 6 06:18:10 2002 Subject: [Distutils] New packagers References: <3C850773.13631C17@lemburg.com> <03a001c1c48a$6ce54420$e000a8c0@thomasnotebook> <2mofi2gfyv.fsf@starship.python.net> Message-ID: <3C85FAFB.3F7F15CB@lemburg.com> Michael Hudson wrote: > > "Thomas Heller" writes: > > > > It would also be nice if we had a distutils compile farm > > > somewhere; oh well, this will probably stay a dream. > > > > > > > I've also thought about this: submit packages (per email, maybe) to > > a server somewhere, and the server runs 'setup.py bdist > > --formats=whatever', and mails the result back. My question is: Can > > this really be made safe? > > Seems very unlikely. It would at least require a lot of thinking about the security model used in the process. Setting up a chroot sandbox like environment is well possible on Unix, but may not be on many other platforms (such as Windows, MacOS, ...). However, it would still be possible to do lots of harmful stuff along the way, e.g. send out spam from the box, implement DDoS attacks, use known exploits on the machine to work around the chroot, etc. Also, debugging would be a pain using an asynchronous approach like email compilation. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From thomas.heller@ion-tof.com Tue Mar 19 11:18:02 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue Mar 19 11:18:02 2002 Subject: [Distutils] Installing source distributions on windows Message-ID: <0c4001c1cf61$8759c830$e000a8c0@thomasnotebook> I've posted a script helping install source distributions (.zip or .tar.gz) on windows. http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/117248 Any comments appreciated. Thomas From thomas.heller@ion-tof.com Thu Mar 21 06:17:01 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Mar 21 06:17:01 2002 Subject: [Distutils] specifying headers for an extension References: <15492.28149.282471.141772@grendel.zope.com> Message-ID: <048901c1d0c9$c85bd530$e000a8c0@thomasnotebook> > > When building an extension, how do I specify that some C header files > should be considered part of the sources for the purpose of dependency > checking? I can't include them with the list of C files: > > running build_ext > building '_datetime' extension > error: unknown file type '.h' (from 'datetime.h') > make: *** [_datetime.so] Error 1 > > and just specifying their location isn't the right thing either. I > want the .o file to be re-built if the header changes. > > I didn't see anything about this in the docs. If someone can point me > in the right direction, I can update the docs so others can find this > information. > > Thanks! > > > -Fred I've uplaoded a patch: http://python.org/sf/533008 Thomas From akuchlin@mems-exchange.org Thu Mar 21 18:37:01 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu Mar 21 18:37:01 2002 Subject: [Distutils] Commands: init'ing booleans to None Message-ID: There are a bunch of places in distutils.command where Boolean options are initialized to None; there are other places where they're initialized to zero. Is it worth making this consistent, and always setting them to 0? (I'm currently going through all the commands checking the boolean_opts class variables, so I can change the initializations at the same time.) --amk (www.amk.ca) "But as the papers say, he's caught the public's imagination." "Didn't know they had any." -- Cops, in ENIGMA #2: "The Truth" From pearu@cens.ioc.ee Fri Mar 22 03:00:01 2002 From: pearu@cens.ioc.ee (Pearu Peterson) Date: Fri Mar 22 03:00:01 2002 Subject: [Distutils] Commands: init'ing booleans to None In-Reply-To: Message-ID: On Thu, 21 Mar 2002, Andrew Kuchling wrote: > There are a bunch of places in distutils.command where Boolean options > are initialized to None; there are other places where they're > initialized to zero. Is it worth making this consistent, and always > setting them to 0? (I'm currently going through all the commands > checking the boolean_opts class variables, so I can change the > initializations at the same time.) I think you should be extra careful here as some Boolean options seem to be initialized to None and not to 0 in purpose. See for example the `compile' option in install_lib command. If `compile is None', then it is interpreted as "user has not explicitly disabled or enabled compile flag" and then it is set to default value `compile = 1'. So, `None' is not always `0', `None' means "use default" and default may be either 0 or 1. How can you test that your changes will not introduce curious and hard to find bugs? Because there are non-trivial derivatives of distutils (like scipy_distutils) that may also depend on the current behavior of distutils where `None' does not necessarily mean `0'. Regards, Pearu From pete@shinners.org Fri Mar 22 11:22:02 2002 From: pete@shinners.org (Pete Shinners) Date: Fri Mar 22 11:22:02 2002 Subject: [Distutils] bug in read_setup_file ? Message-ID: <3C9AEB12.5060509@shinners.org> i've found a little difficulty trying to add extra compile flags into the arguments used in a "Setup" file with distutils. in extension.py line 179: elif switch == "-C": # only here 'cause makesetup has it! ext.extra_compile_args.append(word) this should either be "ext.extra_compile_args.append(value)" or "append_next_word=ext.extra_compile_args". (depending on however makesetup is supposed to work). in its current form, distutils is adding the actual "-C" flag into the extra_compile_args, ugh. From akuchlin@mems-exchange.org Fri Mar 22 20:57:01 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri Mar 22 20:57:01 2002 Subject: [Distutils] Commands: init'ing booleans to None In-Reply-To: References: Message-ID: <20020323015627.GA2774@ute.mems-exchange.org> On Fri, Mar 22, 2002 at 09:57:51AM +0200, Pearu Peterson wrote: >So, `None' is not always `0', `None' means "use default" and default may >be either 0 or 1. Ah, right; grepping through install_*.py finds such case. Never mind, then; I've reverted the one such change I already made. Thanks for catching this, Pearu! --amk (www.amk.ca) It will be good to be dead - to be a god. -- The emperor Augustus in SANDMAN #30: "August" From akuchlin@mems-exchange.org Fri Mar 22 21:00:01 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri Mar 22 21:00:01 2002 Subject: [Distutils] bug in read_setup_file ? In-Reply-To: <3C9AEB12.5060509@shinners.org> References: <3C9AEB12.5060509@shinners.org> Message-ID: <20020323015903.GB2774@ute.mems-exchange.org> On Fri, Mar 22, 2002 at 08:28:02AM +0000, Pete Shinners wrote: > elif switch == "-C": # only here 'cause makesetup has it! > ext.extra_compile_args.append(word) > >this should either be "ext.extra_compile_args.append(value)" or >"append_next_word=ext.extra_compile_args". (depending on however >makesetup is supposed to work). in its current form, distutils is adding makesetup actually does the same thing, and I think this makes -C completely useless. (Distutils was therefore preserving compatibility.) I've sent a note off to python-dev about this, suggesting that the second fix should be made; we'll see what the reaction is. In any case, good catch, Pete! --amk (www.amk.ca) "It seems we must always meet again." "They do say opposites attract." -- The Master and the Doctor, in "Survival" From andy47@halfcooked.com Mon Mar 25 22:32:02 2002 From: andy47@halfcooked.com (Andy Todd) Date: Mon Mar 25 22:32:02 2002 Subject: [Fwd: [Distutils] Automatic creation of .pyc files] Message-ID: <3C9FEB18.5030204@halfcooked.com> I posted the following message to the list last year but had no replies. I've still got the same problem and wondered if anyone could shed any light on my issue this year ;-) -------- Original Message -------- Subject: [Distutils] Automatic creation of .pyc files Date: Thu, 11 Oct 2001 12:00:01 +1000 From: Andy Todd Organization: Dexter Pinion Appreciation Society To: Distutils All, When packaging a Python module is it possible to stop the automatic creation of .pyc on installation? I ask because in PythonCard we currently store our configuration data in files that are imported but never executed (i.e. they just contain a list). When I package up the prototype and make it available I would like to be able to stop .pyc versions of these files being created. In the future we will probably change the way this data is stored to avoid this, but in the mean time I was wondering what I can do. Any and all suggestions are welcome. Regards, Andy -- ----------------------------------------------------------------------- From the desk of Andrew J Todd esq. "Hit me with your fax machine, baby" - Francis Dunnery, "Because I Can" _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig Regards, Andy -- ---------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com From thomas.heller@ion-tof.com Tue Mar 26 04:46:01 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue Mar 26 04:46:01 2002 Subject: [Distutils] Automatic creation of .pyc files] References: <3C9FEB18.5030204@halfcooked.com> Message-ID: <006901c1d4aa$f9041e10$e000a8c0@thomasnotebook> > > All, > > When packaging a Python module is it possible to stop the automatic > creation of .pyc on installation? > 'setup.py install --no-compile' or 'setup.py bdist_wininst --no-target-compile --no-target-optimize'. This will, however, affect *all* .py files. There is no way to disable compilation on a file-by-file basis. Thomas From akuchlin@mems-exchange.org Fri Mar 29 10:46:01 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri Mar 29 10:46:01 2002 Subject: [Distutils] bug in read_setup_file ? In-Reply-To: <20020323015903.GB2774@ute.mems-exchange.org> References: <3C9AEB12.5060509@shinners.org> <20020323015903.GB2774@ute.mems-exchange.org> Message-ID: <20020329154515.GA16381@ute.mems-exchange.org> On Fri, Mar 22, 2002 at 08:59:03PM -0500, Andrew Kuchling wrote: >makesetup actually does the same thing, and I think this makes -C >completely useless. (Distutils was therefore preserving I've submitted patch #536769 on SourceForge (http://www.python.org/sf/536769) to add a -Xcompiler flag to both Distutils and makesetup. Pete, please try it out and confirm that it works; if it does, I'll check it in. --amk (www.amk.ca) What a sentimental old thing this TARDIS is! -- The Doctor, in "The Enemy Within" From slrlfl2000@yahoo.co.kr Fri Mar 29 23:36:16 2002 From: slrlfl2000@yahoo.co.kr (slrlfl2000) Date: Fri Mar 29 23:36:16 2002 Subject: [Distutils] [광고] 종량제 봉투 절약형 압축쓰레기통 소개 Message-ID:



 

▷ 원치않은 정보였다면 정중히 사과 드리며, 수신 거부를 해주시면 다음부터는 메일이 발송되지 않을 것입니다.
▷ 메일클라이언트의 필터 기능을 이용하여 [광고] 문구를 필터링하면 모든 광고 메일을 자동으로 차단하실 수 있습니다.
수신거부(Unsubscribe)