From Paul.Moore at atosorigin.com Fri Aug 1 10:39:21 2003 From: Paul.Moore at atosorigin.com (Moore, Paul) Date: Fri Aug 1 04:40:35 2003 Subject: [Distutils] Re: Python 2.3/mingw32 Message-ID: <16E1010E4581B049ABC51D4975CEDB88619AE1@UKDCX001.uk.int.atosorigin.com> From: Paul Moore [mailto:pf_moore@yahoo.co.uk] >> We added an extra sanity check that was intended to guard against someone >> using a Python built with MSVC 6, say, and a DLL built with MSVC 7. The >> sanity check is that distutils finds out what compiler was used to build >> Python, and won't compile extensions with anything else. (I think I added >> this code.) > Er... I can build extensions quite happily with the mingw32 compiler, > against a stock Python 2.3 for Windows. [...] > Don't "fix" this, please! It would be a real problem if users couldn't > build C extensions with free tools, without having to build the whole > Python interpreter as well. Looks like (from other postings) that the check is in MSVCCompiler, and so doesn't apply to mingw builds (the original problem seems to have been an issue with the particular setup.py). So it looks like everything's OK for now, otherwise. As I said, once a MSVC7 compiled Python is available for me to test with, I'll look at getting mingw builds working appropriately. I guess I'll be able to steal the version test from msvccompiler.py to help me set the appropriate compiler flags... Cheers, Paul. From blong at fiction.net Mon Aug 4 00:47:33 2003 From: blong at fiction.net (Brandon Long) Date: Mon Aug 4 02:47:37 2003 Subject: [Distutils] Fwd: distutil command lines Message-ID: <20030803234733.A12337@pulp> I mailed this to Greg, and he said to try here: I've got a project with a python wrapper/extension module (amoung others), called ClearSilver http://www.clearsilver.net/ The package uses autoconf/configure to determine which programs are available, and how to build things, etc. This includes external libaries and locations for them, like -lz, -ldb, etc. Until recently, I've been just providing a Makefile for compiling the python extension, instead of using distutils. I don't really want to deal with compiling the shared library on all of the platforms, though, so I figured I'd go and create the setup.py script. The trouble is, how to pass the information from configure to the setup.py. I was just going to pass them on the command line, ie from Makefile: $(PYTHON) setup.py ext_build $(INCLUDES) $(LIBDIRS) $(LIBS) where $(INCLUDES) is a list of -Ipaths and $(LIBDIRS) is a list of -Lpaths and $(LIBS) is a list of -llibraries. Unfortunately, the command-line processing code, and the code for the setup.cfg file, seems to take the command line arguments and put them into a dictionary. Later, that dictionary is used to set the attributes of the ext_build class, which then translates the string into a single item list. So, this means I can't specify more than one option on the command line and get a list of libraries or paths. In fact, there seems to be no way to set a list on an option via the command line. That seems bad. Most people seem to deal with this problem by having as much smarts in the setup.py file as there are in their configure script... which seems annoying, especially since if there are similar macros for finding libraries and the like in distutils, they are at least not documented. Its also not clear to me how I can parse the command line arguments in setup.py... though I guess I could probably just import sys, run through sys.argv removing my arguments, or some such. I didn't try that, though. Instead, my "solution" is to parse the Makefile from the setup.py file, and setup the options from what I get. Obviously I can't write all of make, but it works well enough for my task (its not up there yet, it'll be in the next version). Any thoughts on fixing the command line arguments to support list options? Brandon -- program, n.: A magic spell cast over a computer allowing it to turn one's input into error messages. tr.v. To engage in a pastime similar to banging one's head against a wall, but with fewer opportunities for reward. http://www.fiction.net/blong/ From fog at initd.org Mon Aug 4 07:58:42 2003 From: fog at initd.org (Federico Di Gregorio) Date: Mon Aug 4 02:58:43 2003 Subject: [Distutils] Fwd: distutil command lines In-Reply-To: <20030803234733.A12337@pulp> References: <20030803234733.A12337@pulp> Message-ID: <1059980201.7464.2.camel@localhost> Il lun, 2003-08-04 alle 08:47, Brandon Long ha scritto: > I mailed this to Greg, and he said to try here: > > I've got a project with a python wrapper/extension module (amoung > others), called ClearSilver http://www.clearsilver.net/ > > The package uses autoconf/configure to determine which programs are > available, and how to build things, etc. This includes external > libaries and locations for them, like -lz, -ldb, etc. > > Until recently, I've been just providing a Makefile for compiling the > python extension, instead of using distutils. I don't really want to > deal with compiling the shared library on all of the platforms, though, > so I figured I'd go and create the setup.py script. same problem here. i solved it by using configure to generate setup.py from setup.py.in (in setup.py you can specify multiple include paths, etc.) but i consider this to be an hack and a sub-optimal solution. the best would be to generate setup.cfg and let the user do last-minute adjustements directly to it. -- Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org Datemi uno spigolo. Che lo arrotondo tutto. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata Url : http://mail.python.org/pipermail/distutils-sig/attachments/20030804/e7701ae7/attachment.bin From mdehoon at ims.u-tokyo.ac.jp Mon Aug 4 18:11:35 2003 From: mdehoon at ims.u-tokyo.ac.jp (Michiel Jan Laurens de Hoon) Date: Mon Aug 4 04:10:31 2003 Subject: [Distutils] Fwd: distutil command lines In-Reply-To: <20030803234733.A12337@pulp> References: <20030803234733.A12337@pulp> Message-ID: <3F2E1537.4090708@ims.u-tokyo.ac.jp> Most of the configuration machinery is already available in distutils (via "python setup.py config"), so you may not need to run autoconf/configure at all. In one of my software projects, I was able to get rid of the autoconf/configure stuff altogether by using the corresponding distutils routines. These are much easier to use than autoconf/configure, and also guarantees that you are using the same compiler and compiler options for the config stage and the build stage. For some examples of "python setup.py config" (including finding external libraries and such), see http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/software/python/pygist.html or http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/software/python/statistics.html One caveat: there were some bugs in distutils' config machinery in Python 2.2. These have been fixed in Python 2.3. --Michiel. Brandon Long wrote: > I mailed this to Greg, and he said to try here: > > I've got a project with a python wrapper/extension module (amoung > others), called ClearSilver http://www.clearsilver.net/ > > The package uses autoconf/configure to determine which programs are > available, and how to build things, etc. This includes external > libaries and locations for them, like -lz, -ldb, etc. > > Until recently, I've been just providing a Makefile for compiling the > python extension, instead of using distutils. I don't really want to > deal with compiling the shared library on all of the platforms, though, > so I figured I'd go and create the setup.py script. > > The trouble is, how to pass the information from configure to the > setup.py. I was just going to pass them on the command line, ie from > Makefile: > > $(PYTHON) setup.py ext_build $(INCLUDES) $(LIBDIRS) $(LIBS) > > where $(INCLUDES) is a list of -Ipaths and $(LIBDIRS) is a list of > -Lpaths and $(LIBS) is a list of -llibraries. > > Unfortunately, the command-line processing code, and the code for the > setup.cfg file, seems to take the command line arguments and put them > into a dictionary. Later, that dictionary is used to set the attributes > of the ext_build class, which then translates the string into a single > item list. > > So, this means I can't specify more than one option on the command line > and get a list of libraries or paths. In fact, there seems to be no way > to set a list on an option via the command line. That seems bad. Most > people seem to deal with this problem by having as much smarts in the > setup.py file as there are in their configure script... which seems > annoying, especially since if there are similar macros for finding > libraries and the like in distutils, they are at least not documented. > > Its also not clear to me how I can parse the command line arguments in > setup.py... though I guess I could probably just import sys, run through > sys.argv removing my arguments, or some such. I didn't try that, > though. Instead, my "solution" is to parse the Makefile from the > setup.py file, and setup the options from what I get. Obviously I can't > write all of make, but it works well enough for my task (its not up > there yet, it'll be in the next version). > > Any thoughts on fixing the command line arguments to support list > options? > > Brandon -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon From Jack.Jansen at cwi.nl Mon Aug 4 11:23:44 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Mon Aug 4 04:21:22 2003 Subject: [Distutils] Fwd: distutil command lines In-Reply-To: <20030803234733.A12337@pulp> Message-ID: On Monday, Aug 4, 2003, at 08:47 Europe/Amsterdam, Brandon Long wrote: > I mailed this to Greg, and he said to try here: > > I've got a project with a python wrapper/extension module (amoung > others), called ClearSilver http://www.clearsilver.net/ > > The package uses autoconf/configure to determine which programs are > available, and how to build things, etc. This includes external > libaries and locations for them, like -lz, -ldb, etc. > > Until recently, I've been just providing a Makefile for compiling the > python extension, instead of using distutils. I don't really want to > deal with compiling the shared library on all of the platforms, though, > so I figured I'd go and create the setup.py script. > > The trouble is, how to pass the information from configure to the > setup.py. I was just going to pass them on the command line, ie from > Makefile: > > $(PYTHON) setup.py ext_build $(INCLUDES) $(LIBDIRS) $(LIBS) > > where $(INCLUDES) is a list of -Ipaths and $(LIBDIRS) is a list of > -Lpaths and $(LIBS) is a list of -llibraries. I would also like the ability to change definitions from the command line. My use case is a bit different, though: Package Manager installs distutils-based packages automatically, and sometimes it "knows" that some of the variables that distutils grasps from lib/python2.3/config need to be modified. I think a solution that would fit both my needs and Brandon's would be something like $(PYTHON) setup.py build INCLUDES="$(INCLUDES)" LIBDIR="$(LIBDIRS)" LIBS="$(LIBS)" It is open to discussion whether the name=value assignments go before or after the "build" command name. The structure of distutils commands would suggest before, but we could also pick them all up in a first pass over argv (similarly to what make does, where you can put them anywhere). -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From fog at initd.org Mon Aug 4 10:23:22 2003 From: fog at initd.org (Federico Di Gregorio) Date: Mon Aug 4 05:23:23 2003 Subject: [Distutils] Fwd: distutil command lines In-Reply-To: <3F2E1537.4090708@ims.u-tokyo.ac.jp> References: <20030803234733.A12337@pulp> <3F2E1537.4090708@ims.u-tokyo.ac.jp> Message-ID: <1059988978.1237.6.camel@localhost> Il lun, 2003-08-04 alle 10:11, Michiel Jan Laurens de Hoon ha scritto: > Most of the configuration machinery is already available in distutils > (via "python setup.py config"), so you may not need to run > autoconf/configure at all. In one of my software projects, I was able to > get rid of the autoconf/configure stuff altogether by using the > corresponding distutils routines. These are much easier to use than > autoconf/configure, and also guarantees that you are using the same > compiler and compiler options for the config stage and the build stage. this is another big problem of distutils. how can I tell distutils to *not* use compiler flags from python build but my own? for example, i use assert in devel builds and i don't want NDEBUG to be defined but i get it from a default python 2.3 build (on debian). i know i can rebuild a whole python and then use that for my devel builds but is not handy at all. > For some examples of "python setup.py config" (including finding > external libraries and such), see i'll check the examples. thank you very much. federico -- Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org Don't dream it. Be it. -- Dr. Frank'n'further -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata Url : http://mail.python.org/pipermail/distutils-sig/attachments/20030804/b64fc93c/attachment.bin From mal at lemburg.com Mon Aug 4 12:37:42 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Aug 4 05:38:17 2003 Subject: [Distutils] Fwd: distutil command lines In-Reply-To: <1059988978.1237.6.camel@localhost> References: <20030803234733.A12337@pulp> <3F2E1537.4090708@ims.u-tokyo.ac.jp> <1059988978.1237.6.camel@localhost> Message-ID: <3F2E2966.5020107@lemburg.com> Federico Di Gregorio wrote: > Il lun, 2003-08-04 alle 10:11, Michiel Jan Laurens de Hoon ha scritto: > >>Most of the configuration machinery is already available in distutils >>(via "python setup.py config"), so you may not need to run >>autoconf/configure at all. In one of my software projects, I was able to >>get rid of the autoconf/configure stuff altogether by using the >>corresponding distutils routines. These are much easier to use than >>autoconf/configure, and also guarantees that you are using the same >>compiler and compiler options for the config stage and the build stage. > > > this is another big problem of distutils. how can I tell distutils to > *not* use compiler flags from python build but my own? for example, i > use assert in devel builds and i don't want NDEBUG to be defined but i > get it from a default python 2.3 build (on debian). i know i can rebuild > a whole python and then use that for my devel builds but is not handy at > all. It should be possible to undefine NDEBUG using the CFLAGS environment variable. Have a look at distutils/sysconfig.py: customize_compiler(). -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Aug 04 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ From eumir_camara at yahoo.com Fri Aug 15 02:17:40 2003 From: eumir_camara at yahoo.com (eumir camara) Date: Fri Aug 15 04:18:16 2003 Subject: [Distutils] segmentation fault using kinterbasdb extension on cygwin.dll Message-ID: <20030815081740.8937.qmail@web40805.mail.yahoo.com> I was able to build and install kinterbasdb_3.1_pre4 on cygwin successfully. But I kept getting a segmentation fault (core dumped) when connecting to firebird 1.03. ENVIRONMENT: ====================================================== win2k service pack 3 kinterbasdb 3.1_pre4 cygwin cygwin python 2.2.3 egenix-mx-base-2.0.4 firebird 1.03 windows STEPS: ====================================================== 1) downloaded kinterbasdb 3.1_pre4 and untar to a directory 2) modified setup.cfg database_home_dir=c:/progra~1/firebird database_include_dir=c:/progra~1/firebird/include database_lib_dir=c:/progra~1/firebird/lib 3) modified setup.py file included below 4) built kinterbasdb extension $ python setup.py build 5) installed kinterbasdb extension $ python setup.py install 6) tested installation setup.py 7) resulted in segmentation fault (core dumped) QUESTIONS: ====================================================== Did i build the extension properly? Is it possible that it couldn't find a required gds32.dll? Is it possible that it could find it gds32.dll, but is not because it uses MSVCRT.dll while the _kinterbasdb.dll uses cygwin1.dll? thank you, eumir_camara@yahoo.com setup.py begin ======================================= import ConfigParser, os, os.path, shutil, string, sys, types import distutils.core import distutils.ccompiler import distutils.sysconfig class BuildError(Exception): pass def doCommand(cmd, header='COMMAND EXECUTION ERROR'): print '\t' + cmd taskOutStream = os.popen(cmd) taskOutput = taskOutStream.read() taskRetCode = taskOutStream.close() if taskRetCode is not None: raise BuildError('\n%s\n Command [%s] died with error:\n[%s]\n' % (header, cmd, taskOutput) ) return taskOutput def doLibConvCmd(cmd): return doCommand(cmd, LIBCONVERSION_ERROR_HEADER) def determineWindowsSystemDir(): if sys.platform == 'cygwin': return doCommand('cygpath --sysdir')[:-1] # Trailing newline. else: # (normal win32) # If I were willing to introduce a win32all dependency into this build # script, this function would be replaced by win32api.GetSystemDirectory. winDir = os.environ.get('SYSTEMROOT', os.environ.get('WINDIR', 'C:\\Windows')) winSysDir = os.path.join(winDir, 'system32') if not os.path.isdir(winSysDir): winSysDir = os.path.join(winDir, 'system') return winSysDir # Be careful about changing these messages; the docs refer to them. PYTHON_SYSTEM_ERROR_HEADER = 'PYTHON SYSTEM ERROR:' COMPILER_CONFIGURATION_ERROR_HEADER = 'COMPILER CONFIGURATION ERROR:' KIDB_DISTRIBUTION_ERROR_HEADER = 'KINTERBASDB DISTRIBUTION ERROR:' LIBCONVERSION_ERROR_HEADER = 'LIBRARY CONVERSION ERROR:' AUTODETECTION_ERROR_HEADER = 'LIBRARY AUTODETECTION ERROR:' MANUAL_SPECIFICATION_ERROR_HEADER = 'LIBRARY MANUAL SPECIFICATION ERROR:' DISTUTILS_URL = 'http://www.python.org/sigs/distutils-sig/distutils.html' # mx.DateTime is not really required now that date I/O is handled by # dynamic type translation. See the typeconv_preferred.py in this directory # for a date I/O implementation that uses Python 2.3 stdlib datetime module # rather than mx.DateTime. # In any case, mx.DateTime is no longer linked to kinterbasdb at the C level-- # it's just a standard Python import now. # DATETIME_URL = 'http://www.lemburg.com/files/python/eGenix-mx-Extensions.html' VERSION_FILE = 'version.txt' CONFIG_FILE = 'setup.cfg' PYTHON_VERSION_THRESHOLD = '2.1' if sys.version < PYTHON_VERSION_THRESHOLD: sys.stderr.write( '%s\n' ' Beginning with kinterbasdb 3.1, kinterbasdb' ' no longer officially supports\n versions of Python prior to %s.\n\n' % (PYTHON_SYSTEM_ERROR_HEADER, PYTHON_VERSION_THRESHOLD) ) sys.exit(-1) DEBUG = int(os.environ.get('KINTERBASDB_DEBUG', 0)) try: import distutils except ImportError: sys.stderr.write( "%s\n" " Cannot import the standard package 'distutils'.\n" " distutils did not join the standard library until Python 1.6,\n" " and some some nonstandard Python distributions do not\n" " include the package.\n" " You must either upgrade to a Python version with distutils\n" " integrated, or download the package from:\n" " %s" % (PYTHON_SYSTEM_ERROR_HEADER, DISTUTILS_URL,) ) sys.exit(1) import distutils.core import distutils.ccompiler import distutils.sysconfig # Module name and version number: kinterbasdb_name = 'kinterbasdb' # Retrive the kinterbasdb version number from a standard text file for the sake # of maintainability: try: kinterbasdb_version = string.strip(open(VERSION_FILE).read()) except IOError: sys.stderr.write( "%s\n" " Missing file 'version.txt'; cannot determine kinterbasdb" " version." % KIDB_DISTRIBUTION_ERROR_HEADER ) sys.exit(1) # These config parameters are user-specifiable via setup.cfg: DATETIME_INCLUDE_DIR = None DATABASE_IS_FIREBIRD = None DATABASE_HOME_DIR = None DATABASE_INCLUDE_DIR = None DATABASE_LIB_DIR = None DATABASE_LIB_NAME = None # These config parameters are not drawn from setup.cfg: CUSTOM_PREPROCESSOR_DEFS = [] PLATFORM_SPECIFIC_INCLUDE_DIRS = [] PLATFORM_SPECIFIC_LIB_DIRS = [] PLATFORM_SPECIFIC_LIB_NAMES = [] PLATFORM_SPECIFIC_EXTRA_COMPILER_ARGS = [] PLATFORM_SPECIFIC_EXTRA_LINKER_ARGS = [] # See if the user manually specified various build options in the setup config # file. If so, skip autodetection for the options that the user has specified. config = ConfigParser.ConfigParser() config.read(CONFIG_FILE) if config.has_section('manual_config'): # It would be better to test against sys.version_info rather than the # string sys.version, but it's not available on older Python versions. if sys.version < '1.6': # Compensate for 1.5.2's lack of ConfigParser.ConfigParser.has_option: def config_has_option(section, option, config=config): try: return config.get(section, option) except ConfigParser.NoOptionError: return None config.has_option = config_has_option if config.has_option('manual_config', 'datetime_include_dir'): DATETIME_INCLUDE_DIR = config.get('manual_config', 'datetime_include_dir') if config.has_option('manual_config', 'database_is_firebird'): DATABASE_IS_FIREBIRD = config.get('manual_config', 'database_is_firebird') if config.has_option('manual_config', 'database_home_dir'): DATABASE_HOME_DIR = config.get('manual_config', 'database_home_dir') if config.has_option('manual_config', 'database_include_dir'): DATABASE_INCLUDE_DIR = config.get('manual_config', 'database_include_dir') if config.has_option('manual_config', 'database_lib_dir'): DATABASE_LIB_DIR = config.get('manual_config', 'database_lib_dir') if config.has_option('manual_config', 'database_lib_name'): DATABASE_LIB_NAME = config.get('manual_config', 'database_lib_name') if DEBUG: print "*** CONFIG OPTIONS SPECIFIED IN %s SECTION 'manual_config' ***" % CONFIG_FILE for key in config.options('manual_config'): print '%s:' % (key) print ' %s' % (config.get('manual_config', key)) ALL_AUTODETECT_OPTIONS_MANUALLY_SPECIFIED = ( DATETIME_INCLUDE_DIR and DATABASE_IS_FIREBIRD is not None and DATABASE_HOME_DIR and DATABASE_INCLUDE_DIR and DATABASE_LIB_DIR and DATABASE_LIB_NAME ) # Utility functions: def verifyAutodetectedDatabaseIncludeDir(): if not os.path.exists(DATABASE_INCLUDE_DIR): sys.stderr.write( "%s\n" " Cannot autodetect the database header file directory.\n" " (Tried %s)\n" " Try specifying the 'database_include_dir' option in\n" " the 'manual_config' section of the setup config file (%s).\n" % (AUTODETECTION_ERROR_HEADER, DATABASE_INCLUDE_DIR, CONFIG_FILE) ) sys.exit(1) def verifyUserSpecifiedDatabaseIncludeDir(): if not os.path.exists(DATABASE_INCLUDE_DIR): sys.stderr.write( "%s\n" " The user-specified database header file directory\n" " %s\n" " does not exist.\n" " Try modifying the 'database_include_dir' option in\n" " the 'manual_config' section of the setup config file (%s),\n" " or comment out that option to force this script to\n" " to autodetect it.\n" % (MANUAL_SPECIFICATION_ERROR_HEADER, DATABASE_INCLUDE_DIR, CONFIG_FILE) ) sys.exit(1) def verifyAutodetectedDatabaseLibraryDir(): if not os.path.exists(DATABASE_LIB_DIR): sys.stderr.write( "%s\n" " Cannot autodetect the database lib directory.\n" " (Tried %s)\n" " Try specifying the 'database_include_dir' option in\n" " the 'manual_config' section of the setup config file (%s).\n" % (AUTODETECTION_ERROR_HEADER, DATABASE_LIB_DIR, CONFIG_FILE) ) sys.exit(1) def verifyUserSpecifiedDatabaseLibraryDir(): if not os.path.exists(DATABASE_LIB_DIR): sys.stderr.write( "%s\n" " The user-specified database lib directory\n" " %s\n" " does not exist.\n" " Try modifying the 'database_lib_dir' option in\n" " the 'manual_config' section of the setup config file (%s),\n" " or comment out that option to force this script to\n" " to autodetect it.\n" % (MANUAL_SPECIFICATION_ERROR_HEADER, DATABASE_LIB_DIR, CONFIG_FILE) ) sys.exit(1) def findSpacelessDirName(d): # On Windows, try to find the spaceless version of the provided directory # name. # This function was added on 2002.03.14 as part of an ugly hack to # surmount a bug in the distutils package. # Sometime distutils causes None to be fed to this function. if not d: return d d = os.path.normpath(os.path.abspath(d)) if ' ' not in d: return d # If d doesn't exist, its short equivalent can't be determined. # However, for the purposes of this program (which is solely for # convenience anyway) it's better just to risk feeding the # compiler/linker a path with a space in it than it is to raise # an exception when there's still a *chance* of success. if not os.path.isdir(d): return d try: import win32api return os.path.normcase(win32api.GetShortPathName(d)) except ImportError: # Since win32api is not available, we'll revert to a lame, # manual approximation of GetShortPathName. pass ds = d.split(os.sep) # Split into components. if DEBUG: print 'ds is', ds ds[0] = ds[0] + '\\' # Add slash back onto drive designation so that # it's like c:\ rather than just c: dsNoSpaces = [] # Will contain a version of the directory components # with all spaces removed. for x in range(len(ds)): dir = ds[x] if DEBUG: print 'dir is', dir if dir.find(' ') == -1: shortDir = dir else: fullDir = apply(os.path.join, ds[:x + 1]) if DEBUG: print 'fullDir is', fullDir # Must deal with names like 'abc de' that have their space # before the sixth character. dirNoSpaces = dir.replace(' ', '') if len(dirNoSpaces) < 6: shortDirBase = dirNoSpaces else: shortDirBase = dirNoSpaces[:6] # Search for shortDirBase~i until we find it. shortDir = None i = 1 while i < 9: # This code doesn't handle situations where there are # more than nine directories with the same prefix. maybeShortDir = '%s~%d' % (shortDirBase, i) fullMaybeShortDir = os.path.join( os.path.dirname(fullDir), maybeShortDir) if not os.path.isdir(fullMaybeShortDir): continue # There follows a *really* lame approximation of # os.path.samefile, which is not available on Windows. if os.listdir(fullMaybeShortDir) == os.listdir(fullDir): shortDir = maybeShortDir break i = i + 1 if shortDir is None: raise Exception('Unable to find shortened version of' ' directory named %s' % d) dsNoSpaces.append(shortDir) if DEBUG: print 'dsNoSpaces is', dsNoSpaces return os.path.normcase(apply(os.path.join, dsNoSpaces)) # Perform generic compilation parameter setup, then switch to platform- # specific. curdirAbs = os.path.abspath(os.curdir) # Autodetect Python directory info. if DEBUG: print '*** PYTHON SETTINGS ***' pythonHomeDir = sys.exec_prefix pythonPkgDir = distutils.sysconfig.get_python_lib() if DEBUG: print '\tPython home dir:', pythonHomeDir print '\tPython package dir:', pythonPkgDir print '\tPlatform', sys.platform # Begin platform-specific compilation parameter setup: if sys.platform == 'win32': ALL_AUTODETECT_WINDOWS_REGISTRY_OPTIONS_MANUALLY_SPECIFIED = ( DATABASE_HOME_DIR and DATABASE_INCLUDE_DIR and DATABASE_LIB_DIR and DATABASE_LIB_NAME ) CUSTOM_PREPROCESSOR_DEFS.append( ('WIN32', None) ) # If this is a source distribution, add a couple of necessary include and # lib directories. pcbuildDir = os.path.join( os.path.split(distutils.sysconfig.get_python_inc())[0], 'PCBuild') if os.path.exists(pcbuildDir): PLATFORM_SPECIFIC_LIB_DIRS.append(pcbuildDir) pySrcDistExtraIncludeDir = os.path.join( os.path.split(distutils.sysconfig.get_python_inc())[0], 'PC') PLATFORM_SPECIFIC_INCLUDE_DIRS.append(pySrcDistExtraIncludeDir) # Verify the various directories (such as include and library dirs) that # will be used during compilation. # Open the registry in preparation for reading various installation # directories from it. try: import _winreg except ImportError: # If the user has manually specified all of the options that would # require registry access to autodetect, we can proceed despite the # lack of _winreg. if not ALL_AUTODETECT_WINDOWS_REGISTRY_OPTIONS_MANUALLY_SPECIFIED: sys.stderr.write( "%s\n" " Cannot import the standard package '_winreg'.\n" " _winreg did not join the standard library until\n" " Python 2.0. If you are using a source distribution\n" " of Python 2.0 or later, you may have simply forgotten\n" " to compile the _winreg C extension.\n" " You can get around the lack of _winreg by manually\n" " specifying all of the configuration options in the\n" " 'manual_config' section of the setup config file (%s)." % (AUTODETECTION_ERROR_HEADER, CONFIG_FILE) ) sys.exit(1) if not ALL_AUTODETECT_WINDOWS_REGISTRY_OPTIONS_MANUALLY_SPECIFIED: try: r = _winreg.ConnectRegistry(None, _winreg.HKEY_LOCAL_MACHINE) except WindowsError, e: sys.stderr.write( "%s\n" " Unable to connect to the HKEY_LOCAL_MACHINE section of\n" " the Windows registry.\n" " The specific error encountered is:\n" " %s" % (AUTODETECTION_ERROR_HEADER, str(e)) ) sys.exit(1) if DEBUG: print '*** DATABASE SETTINGS ***' # Autodetect database directory info if the user did not specify it. if not DATABASE_HOME_DIR: def findDatabaseHomeDir(databaseInfoKey, databaseHomeValueName): databaseCurrentVersionKey = _winreg.OpenKey(r, databaseInfoKey) try: return _winreg.QueryValueEx( databaseCurrentVersionKey, databaseHomeValueName )[0] finally: _winreg.CloseKey(databaseCurrentVersionKey) # Try to find Firebird first; revert to Interbase only if necessary. try: try: DATABASE_HOME_DIR = findDatabaseHomeDir( r'SOFTWARE\FirebirdSQL\Firebird\CurrentVersion', 'RootDirectory' ) DATABASE_IS_FIREBIRD = 1 if DEBUG: print ' Autodetected database is Firebird.' except WindowsError: # Revert to Interbase. DATABASE_IS_FIREBIRD = 0 DATABASE_HOME_DIR = findDatabaseHomeDir( r'SOFTWARE\Borland\InterBase\CurrentVersion', 'RootDirectory' ) if DEBUG: print ' Autodetected database is Interbase.' except WindowsError, e: sys.stderr.write( "%s\n" " Unable to retrieve database directory from the\n" " Windows registry.\n" " Try specifying the 'database_home_dir' option in the\n" " 'manual_config' section of the setup config file (%s).\n" " The specific error encountered is:\n" " %s" % (AUTODETECTION_ERROR_HEADER, CONFIG_FILE, str(e)) ) sys.exit(1) if DATABASE_INCLUDE_DIR: verifyUserSpecifiedDatabaseIncludeDir() databaseSDKDir = os.path.dirname(DATABASE_INCLUDE_DIR) else: # user-specified DATABASE_INCLUDE_DIR databaseSDKDir = os.path.join(DATABASE_HOME_DIR, 'SDK') if DATABASE_IS_FIREBIRD or not os.path.exists(databaseSDKDir): databaseSDKDir = DATABASE_HOME_DIR DATABASE_INCLUDE_DIR = os.path.join(databaseSDKDir, 'include') if DEBUG: print '\tDATABASE_INCLUDE_DIR exists at\n\t %s: %d' \ % (DATABASE_INCLUDE_DIR, os.path.exists(DATABASE_INCLUDE_DIR)) verifyAutodetectedDatabaseIncludeDir() if DATABASE_LIB_DIR: verifyUserSpecifiedDatabaseLibraryDir() else: # user-specified DATABASE_LIB_DIR DATABASE_LIB_DIR = os.path.join(databaseSDKDir, 'lib') verifyAutodetectedDatabaseLibraryDir() # Perform compiler-specific setup. if not DATABASE_LIB_NAME: DATABASE_LIB_NAME = 'gds32' # I should discover a way to ask distutils what compiler it's # configured to use--the current code would only detect a compiler # change via the command line. I've looked at the compiler subpackage # of distutils, and can't find any such facility (though it can be # queried for the system's default compiler). customCompilerName = 'msvc' import re argJam = string.lower(string.join(sys.argv[1:])) match = re.search(r'--compiler=(?P\S+)', argJam) if match: customCompilerName = match.group('cname') else: match = re.search(r'-c\s+(?P\S+)', argJam) if match: customCompilerName = match.group('cname') if customCompilerName == 'msvc': if not DATABASE_IS_FIREBIRD: DATABASE_LIB_DIR = os.path.join(databaseSDKDir, r'lib_ms') if not os.path.exists(DATABASE_LIB_DIR): DATABASE_LIB_DIR = os.path.join(databaseSDKDir, r'lib') if not DATABASE_LIB_NAME or DATABASE_LIB_NAME == 'gds32': DATABASE_LIB_NAME = 'gds32_ms' elif customCompilerName == 'bcpp': COMPILER_EXE_NAME = 'bcc32.exe' # Try to find the home directory of the Borland compiler by searching # each directory listed in the PATH. osPath = string.split(os.environ['PATH'], os.pathsep) bccHome = None for dir in osPath: if os.path.exists(os.path.join(dir, COMPILER_EXE_NAME)): bccHome = os.path.split(dir)[0] break else: # Couldn't find it. sys.stderr.write( "%s\n" " Unable to find the home directory of the Borland" " compiler.\n" " You must add the 'bin' subdirectory of the" " compiler's\n" " home directory to your PATH.\n" " One way to do this is to type a command of the" " format\n" " SET PATH=%%PATH%%;c:\\EXAMPLE_DIR\\bin\n" " in the same command prompt you use to run the" " kinterbasdb setup script." % (COMPILER_CONFIGURATION_ERROR_HEADER,) ) sys.exit(1) # Override the default behavior of distutils.bcppcompiler.BCPPCompiler # in order to force it to issue the correct command. from distutils.bcppcompiler import BCPPCompiler def _makeDirNameSpacless(kwargs, argName): x = kwargs.get(argName, None) if x is None: return elif isinstance(x, types.StringType): kwargs[argName] = findSpacelessDirName(x) else: # sequence of strings kwargs[argName] = [ findSpacelessDirName(d) for d in x ] class BCPP_UGLY_Hack(BCPPCompiler): def compile (self, *args, **kwargs): bccIncludePreargDir = findSpacelessDirName('%s\include' % bccHome) bccLibPreargDir = findSpacelessDirName('%s\lib' % bccHome) bccLibPSDKPreargDir = findSpacelessDirName('%s\lib\psdk' % bccHome) kwargs['extra_preargs'] = ( [ r'-I"%s"' % bccIncludePreargDir, r'-L"%s"' % bccLibPreargDir, r'-L"%s"' % bccLibPSDKPreargDir ] + kwargs.get('extra_preargs', []) ) for argName in ('output_dir', 'include_dirs'): _makeDirNameSpacless(kwargs, argName) return BCPPCompiler.compile(self, *args, **kwargs) def link (self, *args, **kwargs): ilinkLibPreargDir = findSpacelessDirName('%s\lib' % bccHome) ilinkLibPSDKPreargDir = findSpacelessDirName('%s\lib\psdk' % bccHome) myPreArgs = [ r'/L"%s"' % ilinkLibPreargDir, r'/L"%s"' % ilinkLibPSDKPreargDir ] if not kwargs.has_key('extra_preargs'): argsAsList = list(args) argsAsList[9] = myPreArgs # see distuils.ccompiler.py args = tuple(argsAsList) else: kwargs['extra_preargs'] = myPreArgs + kwargs.get['extra_preargs'] for argName in ( 'output_dir', 'library_dirs', 'runtime_library_dirs', 'build_temp' ): _makeDirNameSpacless(kwargs, argName) return BCPPCompiler.link(self, *args, **kwargs) compilerSetupTuple = distutils.ccompiler.compiler_class['bcpp'] import distutils.bcppcompiler distutils.bcppcompiler.BCPP_UGLY_Hack = BCPP_UGLY_Hack distutils.ccompiler.compiler_class['bcpp'] = ( compilerSetupTuple[0], 'BCPP_UGLY_Hack', compilerSetupTuple[2]) # Use coff2omf to create a Borland-compiler-compatible library file, # "pythonVV_bcpp.lib", from the standard "pythonVV.lib". # It would be better to use sys.version_info rather than the # string sys.version, but it's not available on older Python # versions. pyLibVersionSuffix = sys.version[0] + sys.version[2] # 2003.03.28: Accomodate source dists of Python on Windows (give the # PCBuild\pythonVV.lib file (if any) precedence over the # libs\pythonVV.lib file (if any)): pythonLibsDir = os.path.join(pythonHomeDir, 'PCbuild') if not os.path.exists(os.path.join(pythonLibsDir, 'python%s.lib' % pyLibVersionSuffix)): pythonLibsDir = os.path.join(pythonHomeDir, 'libs') newLibFilename = os.path.join(pythonLibsDir, 'python%s_bcpp.lib' % pyLibVersionSuffix) print 'setup.py is trying to create %s' % newLibFilename if not os.path.exists(os.path.join(newLibFilename)): # oldLibFilename = '%s\libs\python%s.lib' % ( oldLibFilename = os.path.join(pythonLibsDir, 'python%s.lib' % pyLibVersionSuffix) coff2omfCommand = ('coff2omf %s %s' % (oldLibFilename, newLibFilename)) os.system(coff2omfCommand) # Do this test instead of checking the return value of # os.system, which will not reliably indicate an error # condition on Win9x. if not os.path.exists(newLibFilename): sys.stderr.write( "%s\n" " Unable to create a Borland-compatible Python" " library file using the\n" " coff2omf utility.\n" " Tried command:\n" " %s" % ( COMPILER_CONFIGURATION_ERROR_HEADER, coff2omfCommand) ) sys.exit(1) assert os.path.exists(newLibFilename) if DEBUG: print '\tDATABASE_LIB_DIR exists at\n\t %s: %d' \ % (DATABASE_LIB_DIR, os.path.exists(DATABASE_LIB_DIR)) print '\tDATABASE_LIB_NAME is\n\t %s' % DATABASE_LIB_NAME elif sys.platform == 'cygwin': print ' *** CYGWIN LIBRARY GENERATION : begin ***' DATABASE_LIB_NAME = 'gds32' PLATFORM_SPECIFIC_LIB_DIRS.append('/usr/lib') PLATFORM_SPECIFIC_EXTRA_COMPILER_ARGS.append('-DUSE_DL_IMPORT') # PLATFORM_SPECIFIC_EXTRA_LINKER_ARGS = [] winSysDir = determineWindowsSystemDir() libUltimateDest = '/usr/lib/libgds32.a' libUltimateDir, libName = os.path.split(libUltimateDest) fbDir = 'c:/progra~1/firebird' if os.path.isfile(libUltimateDest): print ('\tCygwin-compatible Firebird library already exists at:\n\t %s' % libUltimateDest ) else: print ( '\n\tsetup.py is trying to create cygwin-compatible Firebird' ' library at:\n' '\t "%s"' % libUltimateDest ) fbClientLibFilename = os.path.join(fbDir, 'lib', 'gds32.lib') origCurDir = os.path.abspath(os.curdir) os.chdir(winSysDir) try: # Create def file containing symbols from gds32.lib. doLibConvCmd( '''(echo EXPORTS; nm %s | grep " T _"''' ''' | sed 's/.* T _//g' | sed 's/@.*$//g')''' ''' > gds32.def''' % fbClientLibFilename ) # End lame pexports substitute. # Create lib file from DLL and the just-generated def file. doLibConvCmd( 'dlltool --dllname gds32.dll --def gds32.def --output-lib %s' % libName ) os.remove('gds32.def') # Move the lib file to a location where cygwin-GCC's linker will # find it. shutil.copyfile(libName, libUltimateDest) os.remove(libName) finally: os.chdir(origCurDir) assert os.path.isfile(libUltimateDest) print ' *** CYGWIN LIBRARY GENERATION : end ***\n' else: # not Windows # If the platform isn't Linux, issue a warning. if len(sys.platform) < 5 or not string.lower(sys.platform)[:5] == 'linux': sys.stderr.write("Warning: The kinterbasdb setup code was not" " specifically written to support your platform (%s), and" " may not work properly.\n" % sys.platform ) else: # The platform is Linux. pass # Is libcrypt necessary on all POSIX OSes, or just Linux? # Until someone informs me otherwise, I'll assume all. if os.name == 'posix': PLATFORM_SPECIFIC_LIB_NAMES.append('crypt') # Verify the various directories (such as include and library dirs) that # will be used during compilation. # Assumption: # This is a Unix-like OS, where a proper installation routine would have # placed the database [header, library] files in a system-wide dirs. # We have no way of knowing beyond the shadow of a doubt whether that # has happened (as opposed to the situation on Windows, where we can # consult the registry to determine where a binary installer placed its # files), so we'll just let the compiler complain if it can't find the # [header, library] files. # If, on the other hand, the user manually specified the directories, we # may verify that they exist. if DATABASE_INCLUDE_DIR: # the user manually specified it verifyUserSpecifiedDatabaseIncludeDir() if DATABASE_LIB_DIR: # the user manually specified it verifyUserSpecifiedDatabaseLibraryDir() # 2003.04.12: begin block # On FreeBSD 4, the header and library files apparently are not made # visible by default (perhaps because the installation that prompted this # change was from a source distribution rather than an RPM, as all of my # testing on Linux has been?). # This script attempts to "autodetect" an installation at the default # location, but only if: # - no DATABASE_HOME_DIR has been manually specified # - the default installation directory actually exists # # This "autodetection" will probably work for some other Unixes as well. if not DATABASE_HOME_DIR: DEFAULT_FREEBSD_HOME_DIR = '/usr/local/firebird' if os.path.isdir(DEFAULT_FREEBSD_HOME_DIR): DATABASE_HOME_DIR = DEFAULT_FREEBSD_HOME_DIR if not DATABASE_INCLUDE_DIR: DATABASE_INCLUDE_DIR = os.path.join(DATABASE_HOME_DIR, 'include') if not DATABASE_LIB_DIR: DATABASE_LIB_DIR = os.path.join(DATABASE_HOME_DIR, 'lib') # 2003.04.12: end block if not DATABASE_LIB_NAME: DATABASE_LIB_NAME = 'gds' # Now finished with platform-specific compilation parameter setup. # Create a list of all INCLUDE dirs to be passed to setup(): allIncludeDirs = [] # Add Python include directory: allIncludeDirs.append(distutils.sysconfig.get_python_inc()) if len(PLATFORM_SPECIFIC_INCLUDE_DIRS) > 0: allIncludeDirs.extend(PLATFORM_SPECIFIC_INCLUDE_DIRS) if DATETIME_INCLUDE_DIR: allIncludeDirs.append(DATETIME_INCLUDE_DIR) if DATABASE_INCLUDE_DIR: allIncludeDirs.append(DATABASE_INCLUDE_DIR) # Create a list of all LIB names to be passed to setup(): allLibNames = [] if DATABASE_LIB_NAME: allLibNames.append(DATABASE_LIB_NAME) allLibNames.extend(PLATFORM_SPECIFIC_LIB_NAMES) if DEBUG: print '\tLIBRARY NAMES ', allLibNames # Create a list of all LIB directories to be passed to setup(): allLibDirs = [] if len(PLATFORM_SPECIFIC_LIB_DIRS) > 0: allLibDirs.extend(PLATFORM_SPECIFIC_LIB_DIRS) if DATABASE_LIB_DIR: allLibDirs.append(DATABASE_LIB_DIR) if DEBUG: print '\tLIBRARY DIRS ', allLibDirs # Create a list of all macro definitions that must be passed to distutils. allMacroDefs = [] if len(CUSTOM_PREPROCESSOR_DEFS) > 0: allMacroDefs.extend(CUSTOM_PREPROCESSOR_DEFS) # Create a list of all extra options to pass to the compiler, linker. allExtraCompilerArgs = [] if len(PLATFORM_SPECIFIC_EXTRA_COMPILER_ARGS) > 0: allExtraCompilerArgs.extend(PLATFORM_SPECIFIC_EXTRA_COMPILER_ARGS) allExtraLinkerArgs = [] if len(PLATFORM_SPECIFIC_EXTRA_LINKER_ARGS) > 0: allExtraLinkerArgs.extend(PLATFORM_SPECIFIC_EXTRA_LINKER_ARGS) extensionModules = [ distutils.core.Extension( "kinterbasdb._kinterbasdb", sources=["_kinterbasdb.c", "_kievents.c"], libraries=allLibNames, include_dirs=allIncludeDirs, library_dirs=allLibDirs, define_macros=allMacroDefs, extra_compile_args=allExtraCompilerArgs, extra_link_args=allExtraLinkerArgs ), ] # 2003.02.18: IB 5.5 build hack: allPythonModules = [ 'kinterbasdb.__init__', 'kinterbasdb.k_exceptions', # 2003.03.30: dynamic type conv: 'kinterbasdb.typeconv_active', 'kinterbasdb.typeconv_backcompat', 'kinterbasdb.typeconv_preferred', # 2003.05.19: additional components of refactored dynamic type conv: 'kinterbasdb.typeconv_fixed_stdlib', 'kinterbasdb.typeconv_fixed_fixedpoint', 'kinterbasdb.typeconv_datetime_mx', 'kinterbasdb.typeconv_datetime_stdlib', 'kinterbasdb.typeconv_util_isinstance', ] # Build somewhat differently if we're dealing with an IB version before 6.0. # (Innocent until proven guilty.) isIBLessThan_6_0 = 0 for incDir in allIncludeDirs: headerFilename = os.path.join(incDir, 'ibase.h') if os.path.exists(headerFilename): # Using the isc_decode_sql_time symbol as the detector is kinda arbitrary. if open(headerFilename).read().find('isc_decode_sql_time') == -1: isIBLessThan_6_0 = 1 break if isIBLessThan_6_0: print >> sys.stderr, \ 'WARNING: Not building the kinterbasdb._services module because' \ ' IB 5.5 does not support it.' else: # Only include the services module if dealing with >= IB 6.0. allPythonModules.append('kinterbasdb.services') extensionModules.append( distutils.core.Extension( "kinterbasdb._kiservices", sources=["_kiservices.c"], libraries=allLibNames, include_dirs=allIncludeDirs, library_dirs=allLibDirs, define_macros=allMacroDefs, extra_compile_args=allExtraCompilerArgs, extra_link_args=allExtraLinkerArgs ) ) # end IB 5.5 build hack of 2003.02.18 # Now we've detected and verified all compilation parameters, and are ready to # compile. if DEBUG: print '*** SETTINGS DETECTION PHASE COMPLETE; READY FOR BUILD ***' print ("\tThe DEBUG flag is enabled, so the setup script stops\n" "\t before actually invoking the distutils setup procedure." ) sys.exit(0) # The MEAT: distutils.core.setup( name=kinterbasdb_name, version=kinterbasdb_version, author='''Originally by Alexander Kuznetsov ; rewritten and expanded by David Rushby with contributions from several others (see docs/license.txt for details).''', author_email='woodsplitter@rocketmail.com', url='http://kinterbasdb.sourceforge.net', description='Python DB API 2.0 extension for Firebird and Interbase', long_description= 'kinterbasdb allows Python to access the Firebird and Interbase\n' 'SQL servers according to the interface defined by the Python\n' 'Database API Specification version 2.0.', license='see docs/license.txt', # 2003.02.18: IB 5.5 build hack: # For IB 5.5, need to include only specific components of the kinterbasdb # package, not the whole package. #packages=['kinterbasdb'], package_dir={'kinterbasdb': os.curdir}, py_modules=allPythonModules, ext_modules=extensionModules, data_files = [ # documentation: ('Lib/site-packages/kinterbasdb/docs', [ 'docs/index.html', 'docs/installation-source.html', 'docs/installation-binary.html', 'docs/usage.html', 'docs/changelog.txt', 'docs/license.txt', 'docs/Python-DB-API-2.0.html', 'docs/links.html', 'docs/global.css', 'docs/w3c.png', ] ) ] ) setup.py end ========================================= __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From jason at tishler.net Fri Aug 15 11:33:36 2003 From: jason at tishler.net (Jason Tishler) Date: Fri Aug 15 10:31:27 2003 Subject: [Distutils] Re: segmentation fault using kinterbasdb extension on cygwin.dll In-Reply-To: <20030815081740.8937.qmail@web40805.mail.yahoo.com> References: <20030815081740.8937.qmail@web40805.mail.yahoo.com> Message-ID: <20030815143336.GA1012@tishler.net> On Fri, Aug 15, 2003 at 01:17:40AM -0700, eumir camara wrote: > I was able to build and install kinterbasdb_3.1_pre4 on cygwin > successfully. But I kept getting a segmentation fault (core dumped) > when connecting to firebird 1.03. See below... > [snip] > > QUESTIONS: > ====================================================== > Did i build the extension properly? I don't know, but it sounds like you did. > Is it possible that it couldn't find a required gds32.dll? Unlikely, because you would have gotten an import error (along with a winerror of 126): $ fgrep 126L /usr/include/w32api/winerror.h | head -1 #define ERROR_MOD_NOT_FOUND 126L > Is it possible that it could find it gds32.dll, but is not because it > uses MSVCRT.dll while the _kinterbasdb.dll uses cygwin1.dll? The above is most likely the problem. You cannot use two C runtimes in the same program. You will have to either use all Win32 or all Cygwin components. A mixture of the two is a recipe for disaster... Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 From xml-bindings-admin at gnome.org Tue Aug 19 12:12:02 2003 From: xml-bindings-admin at gnome.org (xml-bindings-admin@gnome.org) Date: Tue Aug 19 11:12:45 2003 Subject: [Distutils] Your message to xml-bindings awaits moderator approval Message-ID: <20030819151202.3588.45660.Mailman@moniker.gnome.org> Your mail to 'xml-bindings' with the subject Re: That movie Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. From sonystyle at custhelp.com Tue Aug 19 11:59:59 2003 From: sonystyle at custhelp.com (sonystyle@custhelp.com) Date: Tue Aug 19 14:04:19 2003 Subject: [Distutils] Re: That movie [Incident: 030819-000689] Message-ID: <3F42659F.000017.28249@websc-utils01.int.rightnowtech.com> A Sony Style team member will reply to your question shortly. You may reply to this email by typing between the [=3D=3D=3D> symbols bel= ow. [=3D=3D=3D> Please enter your reply below this line <=3D=3D=3D] [=3D=3D=3D> Please enter your reply above this line <=3D=3D=3D] You can view or edit your question and answer online here. http://sonystyle.custhelp.com/cgi-bin/sonystyle.cfg/php/enduser/acct_logi= n.php?p_userid=3Ddistutils-sig@python.org&p_next_page=3Dmyq_upd.php&p_ref= no=3D030819-000689&p_created=3D1061315998 Question #030819-000689 --------------------------------------------------------------- Summary: Re: That movie Product: General Email Address: distutils-sig@python.org Date Created: 08/19/2003 10:59 AM Last Updated: 08/19/2003 10:59 AM Status: Pending Discussion Thread --------------------------------------------------------------- Customer - 08/19/2003 10:59 AM Please see the attached file for details. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D application = File Attachment =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D application.pif, 73710 bytes, added to incident From kavkeeper at epconline.net Fri Aug 22 03:14:59 2003 From: kavkeeper at epconline.net (kavkeeper@epconline.net) Date: Fri Aug 22 09:28:41 2003 Subject: [Distutils] Virus found in message from you! Message-ID: S2FzcGVyc2t5IEFudGktVmlydXMgNC4wLjAgcmVwb3J0cyBhIHByb2JsZW06IHlvdSBzZW50I GEgbWVzc2FnZSB3aXRoIGEgdmlydXMgIQ0KSW4gdGhlIGZvbGxvd2luZyBtZXNzYWdlOg0KLS 0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRnJvbTpkaXN0dXRpbHMtc2lnQHB5dGhvbi5vcmcNClR vOnRsdXVAZXBjdXNhLmNvbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KUGxlYXNlIGNoZWNr IHlvdXIgY29tcHV0ZXIgd2l0aCBBbnRpdmlydXMgU2Nhbm5lciENClBsZWFzZSBjb250YWN0I GthdmtlZXBlckBlcGNvbmxpbmUubmV0IGZvciBmdXJ0aGVyIGFzc2lzdGFuY2UuA From MAILER-DAEMON at azalea.noc.ucla.edu Thu Aug 21 12:30:35 2003 From: MAILER-DAEMON at azalea.noc.ucla.edu (Mail Delivery Subsystem) Date: Fri Aug 22 10:16:45 2003 Subject: [Distutils] Returned mail: see transcript for details Message-ID: <200308211830.h7LIUZsw021267@azalea.noc.ucla.edu> The original message was received at Thu, 21 Aug 2003 11:30:35 -0700 from periwinkle.noc.ucla.edu [169.232.47.11] ----- The following addresses had permanent fatal errors ----- (reason: 552 5.2.2 Over quota) ----- Transcript of session follows ----- ... while talking to s-7.mail.ucla.edu.: >>> DATA <<< 552 5.2.2 Over quota 554 5.0.0 Service unavailable <<< 503 5.5.1 No recipients -------------- next part -------------- Skipped content of type message/delivery-status-------------- next part -------------- An embedded message was scrubbed... From: Subject: Thank you! Date: Thu, 21 Aug 2003 20:26:29 +0200 Size: 1239 Url: http://mail.python.org/pipermail/distutils-sig/attachments/20030821/c02bc7b0/attachment.eml From sonystyle at custhelp.com Tue Aug 19 21:00:45 2003 From: sonystyle at custhelp.com (sonystyle@custhelp.com) Date: Fri Aug 22 10:59:13 2003 Subject: [Distutils] Re: That movie [Incident: 030819-000689] Message-ID: <3F42E45D.000001.01580@websc02.int.rightnowtech.com> Recently you submitted a question to Sony Style. Our response can be found at the bottom of this message. We hope that this answers your question to your satisfaction. If this issue is not resolved to your satisfaction, you may reopen it within the next 7 days. You may reply to this email by typing between the [=3D=3D=3D> symbols bel= ow. [=3D=3D=3D> Please enter your reply below this line <=3D=3D=3D] [=3D=3D=3D> Please enter your reply above this line <=3D=3D=3D] You can view or edit your question and answer online here. http://sonystyle.custhelp.com/cgi-bin/sonystyle.cfg/php/enduser/acct_logi= n.php?p_userid=3Ddistutils-sig@python.org&p_next_page=3Dmyq_upd.php&p_ref= no=3D030819-000689&p_created=3D1061315998 Subject --------------------------------------------------------------- Re: That movie Discussion Thread --------------------------------------------------------------- Customer - 08/19/2003 10:59 AM Please see the attached file for details. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D application = File Attachment =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D application.pif, 73710 bytes, added to incident Question #030819-000689 --------------------------------------------------------------- Product: General Email Address: distutils-sig@python.org Date Created: 08/19/2003 10:59 AM Last Updated: 08/19/2003 08:00 PM Status: Solved From pwoods at telus.net Fri Aug 22 05:39:51 2003 From: pwoods at telus.net (Auto-reply from pwoods@telus.net) Date: Fri Aug 22 17:19:21 2003 Subject: [Distutils] Re: Wicked screensaver In-Reply-To: <20030822103949.OANC14923.priv-edtnes47.telusplanet.net@WSU808> Message-ID: <20030822103951.OAOE14923.priv-edtnes47.telusplanet.net@priv-edtnes47> This is my Auto Reply. I don't use the email anymore. Sorry. See my web page for my new address. From seefeld at sympatico.ca Fri Aug 22 18:05:16 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Sat Aug 23 11:35:55 2003 Subject: [Distutils] compiling extension modules with 'make' Message-ID: <33854ae4a6453286817c9bcf6570c18a3f469dcb@Orthosoft.ca> hi there, I'v repeatedly tried to convert build systems of my python projects to distutils. As they contain C++ extensions with non-trivial build commands, I failed to get these modules to compile using the default 'Extension(...)' mechanism. I'm now wondering what ways exist to extend distutils such that I can hook up to the old autoconf/make based builds for individual extension modules without the need for manual intervention. I'v seen some packages derive from distutils classes such as distutils.core.Distribution (for example the 4Suite tool) but that looks quite complex so I'm looking for either a simpler way, or some reference manual explaining how to get started. Any hints / links are highly appreciated ! Stefan From 238889 at msn.com Sat Aug 23 04:17:38 2003 From: 238889 at msn.com (238889@msn.com) Date: Sat Aug 23 14:14:36 2003 Subject: [Distutils] Copy VHS tapes to CD too! 238889 Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20030823/8389a219/attachment.htm From mal at lemburg.com Sun Aug 24 01:45:15 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Aug 24 01:46:40 2003 Subject: [Distutils] compiling extension modules with 'make' In-Reply-To: <33854ae4a6453286817c9bcf6570c18a3f469dcb@Orthosoft.ca> References: <33854ae4a6453286817c9bcf6570c18a3f469dcb@Orthosoft.ca> Message-ID: <3F47EE7B.6060805@lemburg.com> Stefan Seefeld wrote: > hi there, > > I'v repeatedly tried to convert build systems of my python projects > to distutils. As they contain C++ extensions with non-trivial > build commands, I failed to get these modules to compile using > the default 'Extension(...)' mechanism. > > I'm now wondering what ways exist to extend distutils such that > I can hook up to the old autoconf/make based builds for individual > extension modules without the need for manual intervention. > > I'v seen some packages derive from distutils classes such as > distutils.core.Distribution (for example the 4Suite tool) but > that looks quite complex so I'm looking for either a simpler > way, or some reference manual explaining how to get started. > > Any hints / links are highly appreciated ! If you're looking for examples on how this can be done, have a look at mxSetup.py in the egenix-mx-experimental package -- that package builds C libraries which are then used by Python wrappers in C. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Aug 24 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2003-08-12: Released eGenix mx Extensions for Python 2.3 ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From csmail at support.prognet.com Fri Aug 22 23:46:16 2003 From: csmail at support.prognet.com (csmail@support.prognet.com) Date: Sun Aug 24 03:36:51 2003 Subject: [Distutils] We will not receive your email Message-ID: <200308230546.h7N5kG4Y013096@support.real.com> Greetings, You have received this message as a result of replying via email to a RealNetworks Order Receipt or Customer Service message. We will -not- receive this email, and have no means of responding. If you received this mail as a result of replying to your Order Receipt from our e-commerce system at www.real.com or www.realstore.com, you will need to submit your service request at the following URL: http://service.real.com/faq/contcs.html If you received this message as a result of replying to a customer service response, there are instructions on how to reply to the customer service agent that responded to your inquiry. This reply method is handled with a web form, and you may find the URL in the Customer Service response message. Thanks again for seeking assistance, and we hope that your problem is resolved shortly. Best regards, Customer Service RealNetworks, Inc. From gatekeeper at EUnet.yu Sun Aug 24 12:24:26 2003 From: gatekeeper at EUnet.yu (gatekeeper@EUnet.yu) Date: Sun Aug 24 07:24:27 2003 Subject: [Distutils] PORUKA KOJU STE POSLALI SADRZI VIRUS / VIRUS IN YOUR MAIL Message-ID: ICAgICAgICAgICAgIFUgUCBPIFogTyBSIEUgTiBKIEUgLSBEIEUgVCBFIEsgVCBPIFYgQSBOI CBWIEkgUiBVIFMKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWIEkgUiBVIFMgIEEgTC BFIFIgVAoKCiAgTmFzIGFudGl2aXJ1cyBzb2Z0dmVyIHByb25hc2FvIGplICB8ICAgT3VyIHZ pcnVzY2hlY2tlciBmb3VuZCB0aGUKCiAgICAgdGhhbmtfeW91LnBpZglwYWNrZWQ6IFBFX1Bh dGNoDQoJcGFja2VkOiBUZUxvY2sNCglpbmZlY3RlZDogSS1Xb3JtLlNvYmlnLmYNCgogIHZpc nVzKGUpIHUgcG9ydWNpIGtvanUgc3RlIHBvc2xhbGkgfCAgIHZpcnVzKGVzKSBpbiB5b3VyIG VtYWlsCiAgbmEgc2xlZGVjZSBhZHJlc2U6ICAgICAgICAgICAgICAgICB8ICAgdG8gdGhlIGZ vbGxvd2luZyByZWNpcGllbnQocyk6CgogICAgIHJvc2tlQG1haW5zdHJlYW0uY28ueXUKCiAg TW9saW1vIHZhcyBkYSBza2VuaXJhdGUgdmFzIHNpc3RlbSB8ICAgUGxlYXNlIGNoZWNrIHlvd XIgc3lzdGVtIGZvcgogIGFudGl2aXJ1cyBzb2Z0dmVyb20gaWxpIG5hcG9tZW5ldGUgfCAgIH ZpcnVzZXMgb3IgYXNrIHlvdXIgc3lzdGVtCiAgdmFzZW0gYWRtaW5pc3RyYXRvcnUgZGEgdG8 gdWNpbmkuICB8ICAgYWRtaW5pc3RyYXRvciB0byBkbyBzby4KCiAgWmFyYXplbmEgcG9ydWth IGplIGlzcG9ydWNlbmEgICAgICB8ICAgVGhlIGluZmVjdGVkIG1lc3NhZ2UgaGFzIGJlZW4KI CBwcmltYW9jKHUvaW1hKSB1IHZpZHUgYXR0YWNobWVudGEsIHwgICBkZWxpdmVyZWQgdG8gdG hlIHJlY2lwaWVudChzKQogIHNhIHBvcnVrb20gdXBvem9yZW5qYS4gICAgICAgICAgICAgfCA gIGFzIGFuIGF0dGFjaG1lbnQgdG8gdGhlIHdhcm5pbmcKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICBtZXNzYWdlLgoKICBQQVpOSkE6IFNhbW9kaXN0cmlidWlyY Wp1Y2kgdmlydXNpIHwgICBBVFRFTlRJT046IFNlbGYtZGlzdHJpYnV0aW5nCiAgY2VzdG8ga2 9yaXN0ZSBsYXpuZSBhZHJlc2UgdSBGcm9tOiB8ICAgdmlydXNlcyBvZnRlbiB1c2UgZmFrZSB hZGRyZXNzZXMKICBwb2xqdSBwb3J1a2EsIHBhIG5pamUgaXNrbGp1Y2VuYSAgIHwgICBpbiBG cm9tOiBmaWVsZCBvZiB0aGUgbWVzc2FnZSwKICBtb2d1Y25vc3QgZGEgamUgemFyYXplbmEgc G9ydWthICAgIHwgICBzbyBpdCBpcyBwb3NzaWJsZSB0aGF0IHRoZQogIHBvc2xhdGEgc2Egcm FjdW5hcmEga29qaSB1IHN2b20gICAgfCAgIGluZmVjdGVkIG1lc3NhZ2Ugd2FzIHNlbnQgZnJ vbQogIGFkcmVzYXJ1IHBvc2VkdWplIHZhc3UgYWRyZXN1LCBiZXogfCAgIGEgaG9zdCB0aGF0 IGNvbnRhaW5zIHlvdXIgYWRkcmVzcwogIHpuYW5qYSBuamVnb3ZvZyB2bGFzbmlrYS4gVWtvb GlrbyAgfCAgIGluIHRoZSBhZGRyZXNzIGJvb2ssIHdpdGhvdXQgaXQncwogIGplIHRvIG92ZG Ugc2x1Y2FqLCBuYWp2ZXJvdmF0bmlqZSAgfCAgIG93bmVyJ3Mga25vd2xlZGdlLiBJZiB0aGl zIGlzIHRoZQogIHZhcyByYWN1bmFyIG5pamUgemFyYXplbi4gICAgICAgICAgfCAgIGNhc2Us IGl0IGlzIG1vc3QgbGlrZWx5IHRoYXQgeW91cgogIE1lZGp1dGltLCBwcmVwb3J1Y3VqZW1vI HZhbSBkYSAgICAgfCAgIGNvbXB1dGVyIGlzIG5vdCBpbmZlY3RlZC4KICBpcGFrIHByb3Zlcm l0ZSB2YXMgc2lzdGVtLiAgICAgICAgIHwgICBIb3dldmVyLCB3ZSByZWNvbW1lbmQgdGhhdCB 5b3UKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICBjaGVjayB5b3Vy IHN5c3RlbSBhbnl3YXkuCgogPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09P T09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQogPT09PT0gX19fICAgICAgIC AgICAgICAgICAgICAgICAgPSBZVW5ldCBBbnRpdmlydXMgRS1NYWlsIEdhdGV3YXkKID09PT0 gLyAgICAgLyAgLyAgIF9fICAgX19fICBfL18gPT0gRVVuZXQgWXVnb3NsYXZpYSwgWVVuZXQg SW50ZXJuYXRpb25hbAogPT09IC8tLS0gIC8gIC8gIC8gIC8gIC9fXyAgIC8gID09PSA0IE9ia WxpY2V2IFZlbmFjLCAxMTAwMCBCZWxncmFkZSwgWVUKID09IC9fX18gIC9fXy8gIC8gIC8gIC 9fXyAgIC8gID09PT0gcGhvbmU6ICszODEgMTEgMzExOTIzMwogPT0gICAgICAgICAgICAgICA gICAgICAgICAgICAgID09PSBodHRwOi8vd3d3LkVVbmV0Lnl1LwogPT0gQ29ubmVjdGluZyBF dXJvcGUgc2luY2UgMTk4MiA9PSBlLW1haWw6IGdhdGVrZWVwZXJARVVuZXQueXUKID09PT09P T09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT 09PT09PT09PT09PT0KA From seefeld at sympatico.ca Sun Aug 24 15:12:19 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Sun Aug 24 15:59:00 2003 Subject: [Distutils] compiling extension modules with 'make' In-Reply-To: <3F47EE7B.6060805@lemburg.com> References: <33854ae4a6453286817c9bcf6570c18a3f469dcb@Orthosoft.ca> <3F47EE7B.6060805@lemburg.com> Message-ID: <3F490003.6030608@sympatico.ca> M.-A. Lemburg wrote: > If you're looking for examples on how this can be done, > have a look at mxSetup.py in the egenix-mx-experimental > package -- that package builds C libraries which are then > used by Python wrappers in C. thanks ! That's certainly a good start. I didn't even know there is a 'config' command (skeleton). That looks as it could serve. What's the best way to generate files (headers, python scripts, etc.) by means of a 'config' command such that these generated files contain settings that can later be used by C code as well as python modules (paths, for example) ? Regards, Stefan PS: the distutils documentation is really sparse...:-( From seefeld at sympatico.ca Sun Aug 24 11:28:13 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Sun Aug 24 16:00:07 2003 Subject: [Distutils] accessing data files Message-ID: <3F48CB7D.8090800@sympatico.ca> hi there, I'm creating a package that contains python modules as well as data files. My understanding is that there are options for 'python setup.py install' to specifically tell where to put the data files. How does my python code then know where to look for these files ? Is there a way to generate part of the python code such that these locations are stored and remembered ? Thanks, Stefan From postmaster at cnrs-orleans.fr Sun Aug 24 23:37:08 2003 From: postmaster at cnrs-orleans.fr (MailScanner) Date: Sun Aug 24 16:44:52 2003 Subject: [Distutils] Warning: E-mail viruses detected Message-ID: <200308242037.h7OKb8rn009736@admin.cnrs-orleans.fr> Our virus detector has just been triggered by a message you sent:- To: Subject: Re: Your application Date: Sun Aug 24 22:37:08 2003 One or more of the attachments are on the list of unacceptable attachments for this site and will not have been delivered. Consider renaming the files or putting them into a "zip" file to avoid this constraint. The virus detector said this about the message: Report: Shortcuts to MS-Dos programs are very dangerous in email in details.pif -- MailScanner Email Virus Scanner From MAILER-DAEMON at ecbaldwin.net Sat Aug 23 10:44:58 2003 From: MAILER-DAEMON at ecbaldwin.net (Mail Delivery Subsystem) Date: Sun Aug 24 17:24:57 2003 Subject: [Distutils] Returned mail: Message to graduate@CS.ColoState.EDU Not Delivered In-Reply-To: <200308231542.h7NFgjq6015682@bach.cs.colostate.edu> References: <200308231542.h7NFgjq6015682@bach.cs.colostate.edu> Message-ID: <20030823154458.399DDE8C7F@mail.pippins.net> This is an automatic response to your email. To: From: Date: Sat, 23 Aug 2003 9:41:56 --0600 Subject: Re: Wicked screensaver Try this link (make the message short): mailto:graduate@CS.ColoState.EDU?subject=Add_me_to_your_list Your email was NOT delivered. This means that the recipient has not read your message. If you are trying to send legitimate mail and you're certain that the address is correct sorry for the inconvenience. You may try this: 1 - Send a SHORT email to the recipient with "Add me to your list" in the subject exactly as you see it there. If the message is short it is guaranteed to get through. The link that you see above should work in most situations. 2 - Wait for a reply. The recipient will tell you if you are ok to resend your message. If you are still confused maybe the following Q&A will help clarify things. Q: Why didn't my email get sent? A: Your email was scanned by automatic SPAM detecting software. It determined that it is probably SPAM. There are a number of reasons that this might happen and there is a possibility that legitimate email could get detected as unwanted mail. If this is the case, sorry for the inconvenience. Follow the directions above to request permission to send email to the recipient. Q: Does the recipient know that I've tried to send him/her a message? A: No, the email was intercepted before he/she knew anything about it. Q: Why don't you just accept every message that gets emailed to you like everyone else? This is inconvenient for me. A: If you are trying to send legitimate email I'm sorry for the inconvenience. Anyone who's had an email address for more than a year or two gets unwanted mail and knows that the longer one has an email address the more time is wasted by filtering though it. In some cases the unwanted mail is something that the user may wish that he never saw such as email with immoral content. The postmaster for ecbaldwin.net decided to take the chance that someone's legitimate mail might bounce for the benefit of not having to ever see unwanted mail. Q: Where can I learn about the software that caught my message? A: See http://spamassassin.org From MAILER-DAEMON at ecbaldwin.net Sun Aug 24 12:59:04 2003 From: MAILER-DAEMON at ecbaldwin.net (Mail Delivery Subsystem) Date: Sun Aug 24 19:01:02 2003 Subject: [Distutils] Returned mail: Message to graduate@CS.ColoState.EDU Not Delivered In-Reply-To: <200308241757.h7OHvmq6022071@bach.cs.colostate.edu> References: <200308241757.h7OHvmq6022071@bach.cs.colostate.edu> Message-ID: <20030824175904.0C4D0E8C75@mail.pippins.net> This is an automatic response to your email. To: From: Date: Sun, 24 Aug 2003 11:56:59 --0600 Subject: Re: Re: My details Try this link (make the message short): mailto:graduate@CS.ColoState.EDU?subject=Add_me_to_your_list Your email was NOT delivered. This means that the recipient has not read your message. If you are trying to send legitimate mail and you're certain that the address is correct sorry for the inconvenience. You may try this: 1 - Send a SHORT email to the recipient with "Add me to your list" in the subject exactly as you see it there. If the message is short it is guaranteed to get through. The link that you see above should work in most situations. 2 - Wait for a reply. The recipient will tell you if you are ok to resend your message. If you are still confused maybe the following Q&A will help clarify things. Q: Why didn't my email get sent? A: Your email was scanned by automatic SPAM detecting software. It determined that it is probably SPAM. There are a number of reasons that this might happen and there is a possibility that legitimate email could get detected as unwanted mail. If this is the case, sorry for the inconvenience. Follow the directions above to request permission to send email to the recipient. Q: Does the recipient know that I've tried to send him/her a message? A: No, the email was intercepted before he/she knew anything about it. Q: Why don't you just accept every message that gets emailed to you like everyone else? This is inconvenient for me. A: If you are trying to send legitimate email I'm sorry for the inconvenience. Anyone who's had an email address for more than a year or two gets unwanted mail and knows that the longer one has an email address the more time is wasted by filtering though it. In some cases the unwanted mail is something that the user may wish that he never saw such as email with immoral content. The postmaster for ecbaldwin.net decided to take the chance that someone's legitimate mail might bounce for the benefit of not having to ever see unwanted mail. Q: Where can I learn about the software that caught my message? A: See http://spamassassin.org From ozhmuds at tulane.edu Tue Aug 26 09:47:42 2003 From: ozhmuds at tulane.edu (Oleksandr) Date: Tue Aug 26 09:48:23 2003 Subject: [Distutils] Extending Python under Cygwin Message-ID: <3F4B64FE.CFAD670@tulane.edu> Dear Sir/Madam, My name is Oleksandr Zhmudskyy and I am working at Tulane University (Center for Computational Science). I have a problem with Extending Python when I try to use GNU software. I installed Cygwin shell on PC and try to repeat example from Lutz's book (p, 1098-1100): Mark Lutz. Programming Python, O'REILLY. Second Edition. At the bottom of this message you can see these programs for your convenience. The only difference is that path to the Python folder is changed. This example is working Ok on Unix machine (IRIX 6.5) after the next two steps: 1. gcc -g -c hello.c -I/usr/local/include/python2.2 -o hello.o 2. ld -shared hello.o -o hello.so Here I deliberately use command line (not Makefile) in order to simplify the question. At the first step file hello.o is created and on the second one file hello.so. And everything is working. Under the Cygwin shell on PC the first step is Ok: gcc hello.c -g -c -I/usr/include/python2.3/ -shared -o hello.o And I have object file hello.o but the second step gives me mistakes like this: $ ld hello.o -g -I/usr/include/python2.3/ -shared -o hello.so hello.o(.text+0x2a): In function `message':/home/AAZH/MarkLutz/hello.c:14: undefined reference to `PyArg_Parse' hello.o(.text+0x4a):/home/AAZH/MarkLutz/hello.c:17: undefined reference to `strcpy' hello.o(.text+0x5c):/home/AAZH/MarkLutz/hello.c:18: undefined reference to `strcat' hello.o(.text+0x6f):/home/AAZH/MarkLutz/hello.c:19: undefined reference to `Py_BuildValue' hello.o(.text+0xb8): In function `inithello':/home/AAZH/MarkLutz/hello.c:32: undefined reference to `Py_InitModule4' Note that simple GUI applications that don't need Python Extending are working correctly on Cygwin (for example, hello.py or some programs like this). In general we don't need any paths like -I/usr/local/include/python2.2 or -I/usr/include/python2.3/ because they are already installed by Python. I checked this. Also on STI Python we can see this directly: >>> import sys >>> sys.path ['', '/usr/local/opt/Python-2.2.3/lib/python2.2', '/usr/local/opt/Python-2.2.3/lib/python2.2/plat-irix646', '/usr/local/opt/Python-2.2.3/lib/python2.2/lib-tk', '/usr/local/opt/Python-2.2.3/lib/python2.2/lib-dynload', '/usr/local/opt/Python-2.2.3/lib/python2.2/site-packages'] And the same command on Cygwin (PC): >>> import sys >>> sys.path ['', '/usr/lib/python23.zip', '/usr/lib/python2.3', '/usr/lib/python2.3/plat-cygwin', '/usr/lib/python2.3/lib-tk', '/usr/lib/python2.3/lib-dynload', '/usr/lib/python2.3/site-packages'] Would you be so kind to help me? The thing is that installation Python on Cygwin was done correctly: no mistakes. Thank you beforehand. Sincerely, O. Zhmudsky ************************************************************** import hello print hello.message('C') print hello.message('module ' + hello.__file__) for i in range(3): print hello.message(str(i)) ************************************************************** #include #include /* module functions */ static PyObject * /* returns object */ message(PyObject *self, PyObject *args) /* self unused in modules */ { /* args from python call */ char *fromPython, result[64]; if (! PyArg_Parse(args, "(s)", &fromPython)) /* convert Python -> C */ return NULL; /* null=raise exception */ else { strcpy(result, "Hello, "); /* build up C string */ strcat(result, fromPython); /* add passed Python string */ return Py_BuildValue("s", result); /* convert C -> Python */ } } /* registration table */ static struct PyMethodDef hello_methods[] = { {"message", message, 1}, /* method name, C func ptr, always-tuple */ {NULL, NULL} /* end of table marker */ }; /* module initializer */ void inithello() /* called on first import */ { /* name matters if loaded dynamically */ (void) Py_InitModule("hello", hello_methods); /* mod name, table ptr */ } **************************************** From nhv at cape.com Tue Aug 26 11:17:12 2003 From: nhv at cape.com (Norman Vine) Date: Tue Aug 26 10:12:35 2003 Subject: [Distutils] Extending Python under Cygwin In-Reply-To: <3F4B64FE.CFAD670@tulane.edu> Message-ID: Oleksandr writes: > > I have a problem with Extending Python when I try to use GNU software. > I installed Cygwin shell on PC and try to repeat example from Lutz's > book (p, 1098-1100): > Mark Lutz. Programming Python, O'REILLY. Second Edition. > At the bottom of this message you can see these programs for your convenience. > The only difference is that path to the Python folder is changed. > This example is working Ok on Unix machine (IRIX 6.5) after the next two > steps: > > 1. gcc -g -c hello.c -I/usr/local/include/python2.2 -o hello.o > 2. ld -shared hello.o -o hello.so > > Here I deliberately use command line (not Makefile) in order to > simplify the > question. At the first step file hello.o is created and on the second > one file > hello.so. And everything is working. > > Under the Cygwin shell on PC the first step is Ok: > gcc hello.c -g -c -I/usr/include/python2.3/ -shared -o hello.o > > And I have object file hello.o but the second step gives me mistakes > like this: > > $ ld hello.o -g -I/usr/include/python2.3/ -shared -o hello.so use gcc -shared instead of ld you will also need to link with the Python Library as Win32 does not allow undefined symbols For example using your test file < named as hello_py,c > <550> tmp $ gcc -shared -o hello.dll hello_py.c -I/usr/include/Python2.2 /lib/python2.2/config/libpython2.2.dll.a <551> tmp $ ls *.dll hello.dll <552> tmp $ python Python 2.2.3 (#1, Jun 8 2003, 14:58:23) [GCC 3.2 20020927 (prerelease)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import hello >>> dir(hello) ['__doc__', '__file__', '__name__', 'message'] >>> hello.message >>> hello.message("Hi There") 'Hello, Hi There' >>> HTH Norman From jason at tishler.net Tue Aug 26 11:27:34 2003 From: jason at tishler.net (Jason Tishler) Date: Tue Aug 26 10:25:11 2003 Subject: [Distutils] Extending Python under Cygwin In-Reply-To: <3F4B64FE.CFAD670@tulane.edu> References: <3F4B64FE.CFAD670@tulane.edu> Message-ID: <20030826142734.GA1044@tishler.net> Oleksandr, On Tue, Aug 26, 2003 at 08:47:42AM -0500, Oleksandr wrote: > Would you be so kind to help me? With the attached patch (first attachment), your example can be built as follows: $ gcc -shared -I /usr/include/python2.3 -o hello.dll hello.c -L /usr/lib/python2.3/config -lpython2.3 But, why not use Distutils which will do the "heavy lifting" for you? See the attached setup.py (second attachment). Using this script, your example can be built as follows: $ python setup.py build running build running build_ext building 'hello' extension creating build creating build/temp.cygwin-1.5.2-i686-2.3 gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I/usr/include/python2.3 -c hello.c -o build/temp.cygwin-1.5.2-i686-2.3/hello.o creating build/lib.cygwin-1.5.2-i686-2.3 gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.5.2-i686-2.3/hello.o -L/usr/lib/python2.3/config -lpython2.3 -o build/lib.cygwin-1.5.2-i686-2.3/hello.dll Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -------------- next part -------------- --- hello.c.orig 2003-08-26 10:02:15.188960000 -0400 +++ hello.c 2003-08-26 10:19:26.141396800 -0400 @@ -1,4 +1,4 @@ -#include +#include #include /* module functions */ @@ -22,7 +22,8 @@ static struct PyMethodDef hello_methods[ }; /* module initializer */ -void inithello() /* called on first import */ +PyMODINIT_FUNC +inithello(void) /* called on first import */ { /* name matters if loaded dynamically */ (void) Py_InitModule("hello", hello_methods); /* mod name, table ptr */ } -------------- next part -------------- from distutils.core import setup, Extension setup( name = 'hello', version = '1.0', ext_modules = [ Extension( 'hello', ['hello.c'])]) From Kuser-admin at kde.gr.jp Thu Aug 28 05:33:32 2003 From: Kuser-admin at kde.gr.jp (Kuser-admin@kde.gr.jp) Date: Wed Aug 27 15:33:37 2003 Subject: [Distutils] Fml status report (Kuser ML) References: <20030827193327.621461F8021@duaron.kde.gr.jp> Message-ID: <200308280433.FMLAAB22208.Kuser@kde.gr.jp> ATTENTION! Your mail is too big, so not processed!!! This ML restricts the maximum mail size, so pay attention to the mail with e.g. attachments. --Kuser@kde.gr.jp, Be Seeing You! ************************************************************ Help: Unsubscribe: If you have any questions or problems, please contact Kuser-admin@kde.gr.jp or send e-mail with the body "help"(without quotes) to Kuser-ctl@kde.gr.jp (here is the automatic reply, so more preferable) e.g. on a Unix Machine (shell prompt)% echo "help" |Mail Kuser-ctl@kde.gr.jp ************************************************************ From seefeld at sympatico.ca Thu Aug 28 00:27:21 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Wed Aug 27 23:29:41 2003 Subject: [Distutils] making Extensions more flexible Message-ID: <3F4D7699.4030705@sympatico.ca> hi there, I'v been having problems with extension compilation and I'm looking for ways to enhance the situation. Let me start with an extreme case, where I have an existing C/C++ library with autotools based build system, and I want to provide a python wrapper for that. Let's assume that my library doesn't exist stand-alone, i.e. I want to make it a python module with minimal changes, i.e. for example only a single additional file that provides the interface python <-> C/C++. That's currently not possible, as the 'build_ext' command has a very specific idea of how to process source files into a loadable python module. How can this be enhanced ? I can of course write my own 'build_ext' that is a wrapper around my existing build system, i.e. which calls 'configure', 'make', etc. One of the problems is that there is still the 'Extension' class which is used. With my new 'build_ext', I can't just list the individual src files, as they are opaque to the library I'm wrapping. A way out of this situation would be to allow arbitrary keywords to 'setup()', which are stored as attributes in the 'distribution' object, and then accessible to the commands. So if I add my own attributes *and* my own commands, they can share some specific knowledge. For example class my_build(Command): def run(self): my_data = self.distribution.my_data ...process them... setup(cmdclass={'my_build':my_build}, my_data="some data to be processed by 'my_build'", ...) you get the idea... This covers the extreme case where I have to write my own commands since the existing ones aren't suitable. However, there is already quite a bit that can be done to make the existing 'build_ext' more flexible. For example, I have situations where different source files need different commands to be compiled. Think about the use of 'lex', 'bison', and other tools. This could be achieved in two steps: * provide an abstract 'Target' class that knows how to process its 'input files' * derive 'Extension' from 'Target', and make it be composable out of (sub)targets That would work almost as traditional Makefiles, such that one could compose a tree of targets, each node its own build rules. The variables (CXX, CPPFLAGS, LEX) could still be provided through the 'build_ext' command. What do you think ? Regards, Stefan From seefeld at sympatico.ca Thu Aug 28 00:29:49 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Wed Aug 27 23:32:11 2003 Subject: [Distutils] existing documentation Message-ID: <3F4D772D.4090303@sympatico.ca> hi there, in contrast to other modules, which contain detailed API references, the distutils documentation seems only to consist of two papers, one explaining how to prepare distributions, the other how to use them. Why is that so ? It took me quite some time even to learn that I can customize and extend the commands, i.e. the setup's 'cmdclass' keyword. It was just nowhere documented (outside the code, of course). Am I missing something ? Regards, Stefan From mal at lemburg.com Thu Aug 28 10:29:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Aug 28 03:30:02 2003 Subject: [Distutils] existing documentation In-Reply-To: <3F4D772D.4090303@sympatico.ca> References: <3F4D772D.4090303@sympatico.ca> Message-ID: <3F4DAF61.8010602@lemburg.com> Stefan Seefeld wrote: > hi there, > > in contrast to other modules, which contain detailed > API references, the distutils documentation seems only > to consist of two papers, one explaining how to prepare > distributions, the other how to use them. > > Why is that so ? It took me quite some time even to > learn that I can customize and extend the commands, > i.e. the setup's 'cmdclass' keyword. It was just nowhere > documented (outside the code, of course). > > Am I missing something ? No; distutils has always been this way -- the source code is rather well documented, though. Feel free to submit documentation patches :-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Aug 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2003-08-12: Released eGenix mx Extensions for Python 2.3 ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Thu Aug 28 10:34:46 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Aug 28 03:35:12 2003 Subject: [Distutils] making Extensions more flexible In-Reply-To: <3F4D7699.4030705@sympatico.ca> References: <3F4D7699.4030705@sympatico.ca> Message-ID: <3F4DB096.60900@lemburg.com> Stefan Seefeld wrote: > hi there, > > I'v been having problems with extension compilation and I'm > looking for ways to enhance the situation. > > Let me start with an extreme case, where I have an existing > C/C++ library with autotools based build system, and I want > to provide a python wrapper for that. Let's assume that my > library doesn't exist stand-alone, i.e. I want to make it > a python module with minimal changes, i.e. for example only > a single additional file that provides the interface > python <-> C/C++. > > That's currently not possible, as the 'build_ext' command > has a very specific idea of how to process source files into > a loadable python module. > > How can this be enhanced ? I can of course write my own 'build_ext' > that is a wrapper around my existing build system, i.e. which > calls 'configure', 'make', etc. Right, that's how you'd do it. If you come up with a good implementation, I'd suggest you post it as patch to SF. I can't see why you would want build on build_ext for this, though. Writing a new command from scratch using the available tools would be much cleaner. The code for mx_build_unixlib you find in the mxSetup.py module of egenix-mx-experimental is an example of how this can be done. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Aug 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2003-08-12: Released eGenix mx Extensions for Python 2.3 ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From anthony at interlink.com.au Thu Aug 28 19:18:33 2003 From: anthony at interlink.com.au (Anthony Baxter) Date: Thu Aug 28 04:19:35 2003 Subject: [Distutils] existing documentation In-Reply-To: <3F4DAF61.8010602@lemburg.com> Message-ID: <200308280818.h7S8IfBU009042@localhost.localdomain> >>> "M.-A. Lemburg" wrote > > No; distutils has always been this way -- the source code > is rather well documented, though. > > Feel free to submit documentation patches :-) Note that there's a largish chunk of docs in nondist/sandbox/distutilsref that's waiting for a free lump of round tuits to bash it into a decent shape. Anthony -- Anthony Baxter It's never too late to have a happy childhood. From seefeld at sympatico.ca Thu Aug 28 09:54:34 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Thu Aug 28 08:54:21 2003 Subject: [Distutils] existing documentation References: <3F4D772D.4090303@sympatico.ca> <3F4DAF61.8010602@lemburg.com> Message-ID: <30ce5f264aabd338271084936dc48cac3f4df9ae@Orthosoft.ca> M.-A. Lemburg wrote: > Feel free to submit documentation patches :-) Well, as you say, the code itself is already quite well documented. How is the documentation on python.org's module documentation put together ? Is that just the inline comments extracted by some tool such as happydoc ? Or is that manually written ? If the former, it seems all that is missing is the necessary infrastructure to generate these doc pages from the current code base. What I'd like to see online is a detailed description of all those commands, and a precise list of what keywords setup() expects. That would be a very good start. Regards, Stefan From seefeld at sympatico.ca Thu Aug 28 10:00:22 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Thu Aug 28 09:01:15 2003 Subject: [Distutils] making Extensions more flexible References: <3F4D7699.4030705@sympatico.ca> <3F4DB096.60900@lemburg.com> Message-ID: <9f112696e085cc0c019ba4111f7291db3f4dfb4b@Orthosoft.ca> M.-A. Lemburg wrote: >> How can this be enhanced ? I can of course write my own 'build_ext' >> that is a wrapper around my existing build system, i.e. which >> calls 'configure', 'make', etc. > > > Right, that's how you'd do it. If you come up with a good > implementation, I'd suggest you post it as patch to SF. > > I can't see why you would want build on build_ext for > this, though. Writing a new command from scratch using > the available tools would be much cleaner. agreed. Though the issue I see with this is that some of the other commands which I'd still use rely directly or indirectly on build_ext. For example, the existence of Extension objects in the distribution object is used to decide where to compile ('pure' or not), and the automatic file list that is generated for commands such as 'sdist' will inspect the Extensions, too. So the question is how I can provide my own extension mechanism in a transparent way, i.e. such that the rest of the framework will be able to deduce all it has to know to work. > The code for mx_build_unixlib you find in the mxSetup.py > module of egenix-mx-experimental is an example of how this > can be done. yeah, I had a quick look, before I wrote my own. Again, the problem I see is not so much with the command itself as with the way to integrate that. Regards, Stefan From seefeld at sympatico.ca Thu Aug 28 10:38:20 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Thu Aug 28 09:44:04 2003 Subject: [Distutils] sdist's default file list looks incomplete Message-ID: <907fb37afb40db58badc3d2b2b42318a3f4e03f0@Orthosoft.ca> hi there, When generating a distribution, a list of files to be included is needed. This list is either provided by the packager (a 'MANIFEST' file), or it is generated by distutils from its limitted knowledge coming from existing commands. The documentation for sdist.get_defaults() states: "Add all the default files to self.filelist: - README or README.txt - setup.py - test/test*.py - all pure Python modules mentioned in setup script - all C sources listed as part of extensions or C libraries in the setup script (doesn't catch C headers!) Warns if (README or README.txt) or setup.py are missing; everything else is optional." I'm wondering why this list is lacking the scripts and data files that I can provide to setup(). They clearly are part of a distribution, and they are known to the distribution object, so they could be computed here. Is that a deliberate choice or an omission ? If the former, why ? If the latter, should I send in a patch ? (where ?) Regards, Stefan From amk at asti-usa.com Thu Aug 28 10:48:07 2003 From: amk at asti-usa.com (A.M. Kuchling) Date: Thu Aug 28 09:49:06 2003 Subject: [Distutils] sdist's default file list looks incomplete In-Reply-To: <907fb37afb40db58badc3d2b2b42318a3f4e03f0@Orthosoft.ca> References: <907fb37afb40db58badc3d2b2b42318a3f4e03f0@Orthosoft.ca> Message-ID: <20030828134807.GB21543@vail.asti-usa.com> On Thu, Aug 28, 2003 at 09:38:20AM -0400, Stefan Seefeld wrote: > here. Is that a deliberate choice or an omission ? If the former, why ? > If the latter, should I send in a patch ? (where ?) Probably an accidental omission -- most projects have a MANIFEST or MANIFEST.in, so no one thought to add it. You can submit a patch to the Python project patch tracker on SourceForge. --amk From seefeld at sympatico.ca Thu Aug 28 10:59:17 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Thu Aug 28 09:59:04 2003 Subject: [Distutils] sdist's default file list looks incomplete References: <907fb37afb40db58badc3d2b2b42318a3f4e03f0@Orthosoft.ca> <20030828134807.GB21543@vail.asti-usa.com> Message-ID: <87a83535b9ff18e99853585c0903d7753f4e08da@Orthosoft.ca> A.M. Kuchling wrote: > On Thu, Aug 28, 2003 at 09:38:20AM -0400, Stefan Seefeld wrote: > >>here. Is that a deliberate choice or an omission ? If the former, why ? >>If the latter, should I send in a patch ? (where ?) > > > Probably an accidental omission -- most projects have a MANIFEST or > MANIFEST.in, so no one thought to add it. You can submit a patch to > the Python project patch tracker on SourceForge. ok, will do, thanks. Regards, Stefan From seefeld at sympatico.ca Thu Aug 28 11:24:29 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Thu Aug 28 10:27:02 2003 Subject: [Distutils] sdist's default file list looks incomplete References: <907fb37afb40db58badc3d2b2b42318a3f4e03f0@Orthosoft.ca> <20030828134807.GB21543@vail.asti-usa.com> Message-ID: <17df222ab1d2fef0af81ca32bf064ef93f4e0f11@Orthosoft.ca> the distribution has a 'headers' attribute that is used in 'install_headers'. Where is that attribute set from ? In the current design I would expect 'Extension' to set them, but they don't contain them... Regards, Stefan From amk at asti-usa.com Thu Aug 28 12:04:38 2003 From: amk at asti-usa.com (A.M. Kuchling) Date: Thu Aug 28 11:05:13 2003 Subject: [Distutils] sdist's default file list looks incomplete In-Reply-To: <17df222ab1d2fef0af81ca32bf064ef93f4e0f11@Orthosoft.ca> References: <907fb37afb40db58badc3d2b2b42318a3f4e03f0@Orthosoft.ca> <20030828134807.GB21543@vail.asti-usa.com> <17df222ab1d2fef0af81ca32bf064ef93f4e0f11@Orthosoft.ca> Message-ID: <20030828150438.GA30045@vail.asti-usa.com> On Thu, Aug 28, 2003 at 10:24:29AM -0400, Stefan Seefeld wrote: > the distribution has a 'headers' attribute that > is used in 'install_headers'. Where is that attribute > set from ? In the current design I would expect 'Extension' > to set them, but they don't contain them... It would be set by the call to setup(): setup(..., headers=["NumPy.h"], ...) The code that does it would be at the end of the Distribution.__init__ method (around line 230 or so of dist.py). --amk From postmaster at grad.hr Fri Aug 29 01:56:14 2003 From: postmaster at grad.hr (MailScanner) Date: Thu Aug 28 18:56:26 2003 Subject: [Distutils] Warning: E-mail viruses detected Message-ID: Our virus detector has just been triggered by a message you sent:- To: fresl@grad.hr Subject: Re: That movie Date: Fri Aug 29 00:56:09 2003 Any infected parts of the message have not been delivered. This message is simply to warn you that your computer system may have a virus present and should be checked. The virus detector said this about the message: Report: >>> Virus 'W32/Sobig-F' found in file ./19sRqI-0000iT-00/document_all.pif Shortcuts to MS-Dos programs are very dangerous in email in document_all.pif -- MailScanner Email Virus Scanner From seefeld at sympatico.ca Thu Aug 28 21:19:05 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Thu Aug 28 20:21:34 2003 Subject: [Distutils] the contents of MANIFEST.in Message-ID: <3F4E9BF9.4030707@sympatico.ca> hi there, I'm sorry if this isn't specifically a problem related to distutils, but more related to generation of distributions. I'm writing a MANIFEST.in file for my package. I'm testing it with 'python setup.py sdist' and 'python setup.py bdist_rpm'. During the build, some files are generated which are part of a (binary) distribution, such as html or pdf documentation. When I compile an rpm package, I'll get an error because these files were found, but were not part of a package: RPM build errors: Installed (but unpackaged) file(s) found: ... This sounds as if I should add them to the MANIFEST.in file. That, however, isn't even possible, since the list of files seems to be filtered (i.e. matched with existing files) before the installation (or even building) process even starts, i.e. these files don't exist yet ! Does this mean I can't use a manifest template, but have to write a full manifest manually ? Or am I missing something ? Thanks, Stefan From scanner at pt.lu Fri Aug 29 17:05:01 2003 From: scanner at pt.lu (P&T SecurityScan AntiVirus) Date: Fri Aug 29 10:05:09 2003 Subject: [Distutils] Warning: E-mail viruses detected Message-ID: <200308291405.h7TE51u20230@ophelia.pt.lu> ------------------------------------------------------------ This is a message from the P&T SecurityScan AntiVirus Tool ------------------------------------------------------------ Our virus detector has just been triggered by a message you sent To: Subject: Re: Approved Date: Fri Aug 29 16:05:01 2003 Any infected parts of the message have not been delivered. This message is simply to warn you that your computer system may have a virus present and should be checked. Please find the report of the AntiVirus tool below. ------------------------------------------------------------ Ceci est un message de l'outil AntiVirus du P&T SecurityScan ------------------------------------------------------------ Notre outil AntiVirus a ete declenche par un message que vous avez envoye A: Objet: Re: Approved Date: Fri Aug 29 16:05:01 2003 Les parties infectees du message n'ont pas ete distribuees au destinataire. Ce message sert a vous avertir que votre systeme informatique est peut-etre infecte par un virus et devrait etre controle. Veuillez trouver le rapport de l'outil AntiVirus ci-apres. Report / Rapport: >>> Virus 'W32/Sobig-F' found in file ./h7TE4ut20146/your_details.pif Shortcuts to MS-Dos programs are very dangerous in email (your_details.pif) --P&T Internet------------------------------AV120--- From administrator at vt.edu Sat Aug 30 14:43:42 2003 From: administrator at vt.edu (administrator@vt.edu) Date: Sat Aug 30 13:43:45 2003 Subject: [Distutils] Virus Warning Message-ID: <200308301743.BPD72915@vivi.cc.vt.edu> The message you emailed to system@vt.edu, dated 08/30/03 13:43:42, contains the W32/Sobig-F virus in the thank_you.pif attachment. The action taken was: deleted the attachment.