From calvin@cs.uni-sb.de Wed Nov 1 03:46:09 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Wed Nov 1 03:46:09 2000 Subject: [Distutils] Manifest.in not included in sdist... In-Reply-To: <20001031142729.D12192@kronos.cnri.reston.va.us> Message-ID: Hi all, >I don't think sdist will automatically add any files to the manifest for you, >so you have to explicitly add an include line for it. For example, PyXML's MANIFEST.in starts with: Quoting from sdist.py standard files added are - 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!) >>Another thought - a "reallyclean" command would be nice (deletes all >>intermediate and generated files - essentially all of the "build" and "dist" >>directories, at least... python setup.py clean --all deletes the 'build' directory and all temporary 'dist' files. It does not clean generated Distributions packages in 'dist'. Bastian From Paul.Moore@uk.origin-it.com Wed Nov 1 04:14:02 2000 From: Paul.Moore@uk.origin-it.com (Moore, Paul) Date: Wed Nov 1 04:14:02 2000 Subject: FW: [Distutils] adding docs/samples to bdist ?? Message-ID: <714DFA46B9BBD0119CD000805FC1F53B012A8377@UKRUX002.rundc.uk.origin-it.com> Meant to include the list in the reply... Paul -----Original Message----- From: Moore, Paul Sent: 31 October 2000 09:17 To: 'Pete Shinners' Subject: RE: [Distutils] adding docs/samples to bdist ?? From: Pete Shinners [mailto:pete@visionart.com] > i'd like to start using distutils to create my source and > binary distributions. everything is working for the most part > (i have a feeling i'll be looking into the code for further > refinements :]). anyways, when i create my binary distribution > it is not packaging any of the examples or help files. i > guess the problem is; where should these files go??? > > it seems like this type of stuff hasn't been nailed down yet? As a relative newcomer, my feeling is that you're probably right. It feels to me (having come from Perl) that Python doesn't have a particularly formalised installation directory structure. You can just drop the .py and .pyd files anywhere in sys.path, and it works. While this is great for rapid development and prototyping, I believe that a more formal definition of where installed code should be stored would be useful. I've already raised the question on comp.lang.python of having a proper "site packages" directory on Windows. Having standard directory structures for things like sample code and help files may also be useful. First question - is this sort of issue within the remit of this SIG? If so, is there any interest in defining a standard directory structure? And finally, assuming we do want to do this, can anyone give a reasonably complete explanation of what currently goes into sys.path, where it comes from, and what the reasons for the current practice are? (Assuming the answers to the first two questions are "yes", I'm willing to do the research on this one, but I can't provide the rationale...) Paul. From calvin@cs.uni-sb.de Wed Nov 1 06:22:02 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Wed Nov 1 06:22:02 2000 Subject: FW: [Distutils] adding docs/samples to bdist ?? In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B012A8377@UKRUX002.rundc.uk.origin-it.com> Message-ID: Hi developers and users, >> it seems like this type of stuff hasn't been nailed down yet? It has been nailed down. Distutils has installation "schemes". Modules are installed per default in the sys.prefix and sys.exec_prefix directories. Also we have default prefix directories for data files and scripts. Look at http://www.python.org/pipermail/distutils-sig/2000-February/001181.html for a complete overview. Bastian From Paul.Moore@uk.origin-it.com Wed Nov 1 08:28:01 2000 From: Paul.Moore@uk.origin-it.com (Moore, Paul) Date: Wed Nov 1 08:28:01 2000 Subject: FW: [Distutils] adding docs/samples to bdist ?? Message-ID: <714DFA46B9BBD0119CD000805FC1F53B012A837C@UKRUX002.rundc.uk.origin-it.com> From: Bastian Kleineidam [mailto:calvin@cs.uni-sb.de] > >> it seems like this type of stuff hasn't been nailed down yet? > It has been nailed down. Distutils has installation > "schemes". Modules are installed per default in the sys.prefix > and sys.exec_prefix directories. Also we have default prefix > directories for data files and scripts. > > Look at > http://www.python.org/pipermail/distutils-sig/2000-February/001181.html > for a complete overview. Thanks, I hadn't seen that. I'd downloaded the list archive, but 1600 messages is a lot to get through... In which case, I think what I'd say is that the Windows setup (default installation directory is the Python application directory) isn't what I'd like. But it looks like I may have to persuade Guido over that... (Actually, there's a thread going on comp.lang.python on this topic, so I'll go and see what's happening in that). Paul. From R.Liebscher@gmx.de Thu Nov 2 09:46:01 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Thu Nov 2 09:46:01 2000 Subject: [Distutils] compiling extension for app References: <002001c0385f$2354c320$f73f93cd@visionart.com> Message-ID: <3A017DDE.77019E9C@gmx.de> Pete Shinners wrote: > > is there a simple way to get distutils to compile > an extension for my end-user app? i need a small > extension compiled and just placed in the current > directory (not installed to PYTHONHOME) > > i'm not sure if distutils supports anything like this, > but i imagine someone out there has done something > similar? i'd be glad to get my hands on some info > or examples, thanks > There might be also a simpler way to do this, but I have for this purpose a tiny shell script. install-here.sh --------------------------------- #!/bin/sh python setup.py install --install-base . --install-lib . --install-data . --install-headers . --install-scripts . --------------------------------- So I can always test a local installation (if it is a package). May be the parameters for build (build-base,build-lib) are that what you need. Kind regards Rene Liebscher From robin@alldunn.com Fri Nov 3 12:45:08 2000 From: robin@alldunn.com (Robin Dunn) Date: Fri Nov 3 12:45:08 2000 Subject: [Distutils] Fw: [wxPython] Problem building 2.2.2 on Solaris... Message-ID: <00d301c045bd$bebac2e0$3225d2d1@ARES> This is from a wxPython user. Any advice? > Greetings... > > Using SunOS 5.7, Python 1.5.2, Distutils 1.0.1, wxGTK 2.2.2 > I'm using WorkShop Compilers 5.0 98/12/15 C 5.0 which I have used to > build everything else. > > Everything is fine other than the build insists in compiling with cc. > Since .cpp files are being compiled, cc objects. It should be > compiling with the C++ compiler (/opt/SUNWspro/bin/CC in this case) > instead. It works fine if I cut and paste the compile commands and > substitute the CC. > > Anyone know how do I tell distutils to use the C++ compiler? > I don't really know anything about distutils... > -- Robin Dunn Software Craftsman robin@AllDunn.com http://wxPython.org Java give you jitters? http://wxPROs.com Relax with wxPython! From mfletch@tpresence.com Fri Nov 3 13:15:05 2000 From: mfletch@tpresence.com (Mike Fletcher) Date: Fri Nov 3 13:15:05 2000 Subject: [Distutils] Bug Report: The return -- bdist includes local python executables path in archives Message-ID: e.g. [for the PyOpenGL project] python 1.5.2 install directory is d:/bin/lang/python. When I run setup bdist (with info zip), I get an archive where the paths are specified as: bin\lang\python\OpenGL\* As the bin/lang/python directories were copied into the bdist.win32/dumb directory during collection of the files. Of course, on anyone else's machine, that's just a royal pain, so I'd prefer not to have it occur (I'm just creating the archive manually again today). Distutils 0.9.2 Oh, another thing, you might want the default names for binary archives to include the Python version? Py2, Py152, or something so that people don't get the wrong distributions for their Python versions. Enjoy, Mike From igorr@ifi.uio.no Fri Nov 3 14:33:02 2000 From: igorr@ifi.uio.no (Igor V. Rafienko) Date: Fri Nov 3 14:33:02 2000 Subject: [Distutils] Fw: [wxPython] Problem building 2.2.2 on Solaris... In-Reply-To: <00d301c045bd$bebac2e0$3225d2d1@ARES> Message-ID: on Nov 3, 2000, 09:44, Robin Dunn std::cout'ed: | This is from a wxPython user. Any advice? Yes -- hack distutils. That is what I had to do. Everything worked fine (although linker had to be re-run (wxPython might need a C++ linker)). As a side-comment, is there any simple way to specify a _particular_ compiler/linker for a build in distutils? Something along the lines of CXX = g++ in the traditional makefile context. ivr -- VB, by comparison, treats you like a secretary pecking on MS Office. -- Phlip, on c.l.c++ From calvin@cs.uni-sb.de Fri Nov 3 15:28:01 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Fri Nov 3 15:28:01 2000 Subject: [Distutils] Fw: [wxPython] Problem building 2.2.2 on Solaris... In-Reply-To: Message-ID: >As a side-comment, is there any simple way to specify a _particular_ >compiler/linker for a build in distutils? Something along the lines of > >CXX = g++ Currently not supported. Here is the source code snippet from build_ext.py: # XXX and if we support CFLAGS, why not CC (compiler # executable), CPPFLAGS (pre-processor options), and LDFLAGS # (linker options) too? Workarounds: make an alias or a link from cc to gcc Bastian From calvin@cs.uni-sb.de Fri Nov 3 19:02:02 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Fri Nov 3 19:02:02 2000 Subject: [Distutils] Bug Report: The return -- bdist includes local python executables path in archives In-Reply-To: Message-ID: >Oh, another thing, you might want the default names for binary archives to >include the Python version? Py2, Py152, or something so that people don't >get the wrong distributions for their Python versions. Use the --target-version option for bdist_wininst. Under bdist_rpm use --requires. Bastian From iny@iki.fi Mon Nov 6 03:35:02 2000 From: iny@iki.fi (Ilpo =?iso-8859-1?q?Nyyss=F6nen?=) Date: Mon Nov 6 03:35:02 2000 Subject: [Distutils] Will distutils be an alternative for autoconf + make? Message-ID: Could distutils be an alternative for autoconf + make combination? I'm rather new to distutils, but I looked distutils from this point of view yesterday and I think that with some changes distutils could be used as an building and installing system for applications also. Specially for python apps with extension modules that need to be compiled, this could be very useful. At least installing is a problem with the current distutils as it wants to install to PYTHONHOME. (Yes, this is a feature request, think about it.) --=20 Ilpo Nyyss=F6nen # biny /* :-) */ From pete@visionart.com Mon Nov 6 13:08:23 2000 From: pete@visionart.com (Pete Shinners) Date: Mon Nov 6 13:08:23 2000 Subject: [Distutils] Bug Report: The return -- bdist includes local python executables path in archives References: Message-ID: <003601c0481c$94c4e630$f73f93cd@visionart.com> > e.g. [for the PyOpenGL project] python 1.5.2 install directory is > d:/bin/lang/python. > When I run setup bdist (with info zip), I get an archive where the > paths are specified as: bin\lang\python\OpenGL\* i have the exact same problem. the ZIP created by bdist includes my full python installation path. only helpful if other users have installed python with the same path. From R.Liebscher@gmx.de Tue Nov 7 05:12:03 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Tue Nov 7 05:12:03 2000 Subject: [Distutils] Bug Report: The return -- bdist includes local python executables path in archives References: <003601c0481c$94c4e630$f73f93cd@visionart.com> Message-ID: <3A07D50F.11AD9EE5@gmx.de> Pete Shinners wrote: > > > e.g. [for the PyOpenGL project] python 1.5.2 install directory is > > d:/bin/lang/python. > > When I run setup bdist (with info zip), I get an archive where the > > paths are specified as: bin\lang\python\OpenGL\* > > i have the exact same problem. the ZIP created by bdist > includes my full python installation path. only helpful if > other users have installed python with the same path. > try the following: python setup.py bdist install --install-lib=/ (The install part of the command line sets a parameter for the internal install that is executed by bdist.) Kind regards Rene Liebscher From gward@python.net Tue Nov 7 21:35:01 2000 From: gward@python.net (Greg Ward) Date: Tue Nov 7 21:35:01 2000 Subject: [Distutils] Distutils 1.0.1 releasee In-Reply-To: ; from calvin@cs.uni-sb.de on Mon, Oct 16, 2000 at 11:39:05AM +0200 References: <20001015202258.A7540@beelzebub> Message-ID: <20001107213237.A678@beelzebub> On 16 October 2000, Bastian Kleineidam said: > I have a feature request. At the moment I am storing configuration values > in a Python module file Conf.py. > This file can include values from the config command (libs, includes), > from the install command (install dirs), metadata and customized values > varying from package to package. Ummm, I'm confused. Is this "info needed to build/install the package", or "info needed to run the software"? Those are two very different kinds of configuration info. The Distutils could probably do something in both areas, but I don't think the two should be confused. Eg. about all we can do for run-time configuration is promote a standard place for Python applications to install and find such config data, whereas we can specify everything about build-time config data. So which are you talking about here? Greg -- Greg Ward - Unix bigot gward@python.net http://starship.python.net/~gward/ I have a very good DENTAL PLAN. Thank you. From gward@python.net Tue Nov 7 21:39:01 2000 From: gward@python.net (Greg Ward) Date: Tue Nov 7 21:39:01 2000 Subject: [Distutils] compiling extension for app In-Reply-To: <002001c0385f$2354c320$f73f93cd@visionart.com>; from pete@visionart.com on Tue, Oct 17, 2000 at 10:24:42AM -0700 References: <002001c0385f$2354c320$f73f93cd@visionart.com> Message-ID: <20001107213646.B678@beelzebub> On 17 October 2000, Pete Shinners said: > is there a simple way to get distutils to compile > an extension for my end-user app? i need a small > extension compiled and just placed in the current > directory (not installed to PYTHONHOME) The Big Question of dealing with Python applications in general -- as opposed to Python modules -- has not really been addressed. (The main difference, as I see it, is that modules get installed to the standard directory for third party modules, whereas applications should get their own installation tree. The main outcome of this is that scripts included with applications would need to be hacked at install-time [automatically, by the Distutils, of course!] to find the right modules.) However, don't let that stop you. If all you want to do is build an extension to the "current directory" without installing it, this should work: python setup.py build_ext --inplace as long as "current directory" means "the directory where the extension source file lives". ;-) Greg -- Greg Ward - programmer-at-large gward@python.net http://starship.python.net/~gward/ ... bleakness ... desolation ... plastic forks ... From gward@python.net Tue Nov 7 21:58:01 2000 From: gward@python.net (Greg Ward) Date: Tue Nov 7 21:58:01 2000 Subject: [Distutils] extra files into the package dir In-Reply-To: <39EF0380.2D4E5A87@gmx.de>; from R.Liebscher@gmx.de on Thu, Oct 19, 2000 at 04:21:52PM +0200 References: <00be01c0387f$64287930$f73f93cd@visionart.com> <39ED9849.A0AF5CBF@gmx.de> <39EF0380.2D4E5A87@gmx.de> Message-ID: <20001107215541.C678@beelzebub> [Berthold Höllmann mentions...] > There is support for installing data files, but they get to data > directories. When writing setup.py for biggles, I had the problem, > that a config file had to go to the package directory. All I did was adding > > class my_install_data (install_data): > def finalize_options (self): > self.set_undefined_options('install', > ('install_lib', 'install_dir'), > ('root', 'root'), > ('force', 'force'), > ) > > and > > cmdclass = {'install_data': my_install_data}, > data_files = [('biggles', ["src/config.ini"])] > > to the setup command line. This got everything to the right place. [Rene Liebscher replies...] > This is probably the simplest possible solution. My approach goes > further, it handles also MANIFEST.in-like templates and some other > special things, and it was written primary to replace distutils' > install_data as whole. > (Greg, do you remember my mail of 06/26/2000? > http://www.python.org/pipermail/distutils-sig/2000-June/001671.html ) As it turns out, the Berthold's "my_install_data" solution is really a bare minimum -- the "install_data" command should work that way, or have an option to work that way. I wrote a setup script for IDLE that does basically the same as Berthold's, and if the Distutils installed their own config file, the Distutils setup script would also need this -- d'oh! I don't think I should have to extend the Distutils in order to install the Distutils -- droit de seigneur, in a sense. ;-) Rene, I originally thought your "DataFiles" concept was overkill, but I originally thought having a class to describe extensions was overkill too. If nothing else, introducing a simple class may be the only sane way to maintain backwards compatibility with the current "install_data class. Here's a somewhat simpler conception of the "DataFiles" class... DataFiles -- represents a collection of files to be installed in a common location, the "base directory". Files in the collection are fragmentary paths that are concatenated to the base directory at install time to create a complete installation path. The base directory may be a literal path, or it may use any of the configuration variables allowed in installation directories -- dist_name dist_version dist_fullname py_version py_version_short sys_prefix prefix sys_exec_prefix exec_prefix as well as the config vars corresponding to the installation directory options to the "install" command (most of which are just one of the entries in an installation scheme): install_base install_platbase install_root install_purelib install_platlib install_headers install_scripts install_data (?maybe obsolete?) Thus, a base directory of "$install_base" would expand to /usr/lib/python2.0/site-packages on a typical Linux installation, or C:\Python on a Windows installation. Or you could use "$install_base/mypkg" to install to (eg.) C:\Python\mypkg -- presumably the directory where modules from your distribution get installed. (As usual, Unix paths would be translated to native paths by the Distutils, so that setup scripts port across operating systems.) (There probably ought to be a special name for "the directory where the highest-level package from this module distribution is installed", which would expand to eg. /usr/lib/python1.5/site-packages/distutils.) This gets rid of dependence on the manifest machinery -- since that's now been factored out into a separate class (FileList, in distutils.filelist), developers can use it if they want. Or they can use the standard 'glob' module if that's good enough, or they can list files manually if *that's* good enough. Just off the top of my head... Greg -- Greg Ward - geek-on-the-loose gward@python.net http://starship.python.net/~gward/ I'll eat ANYTHING that's BRIGHT BLUE!! From gward@python.net Tue Nov 7 22:08:03 2000 From: gward@python.net (Greg Ward) Date: Tue Nov 7 22:08:03 2000 Subject: [Distutils] Package installation strategy ! In-Reply-To: <1001023115013.ZM74191@noah.scripps.edu>; from sanner@scripps.edu on Mon, Oct 23, 2000 at 11:50:13AM -0700 References: <20001013231046.G639@beelzebub> <87bswoq6x7.fsf@kc.net> <20001014182254.A878@beelzebub> <87n1fy50u9.fsf_-_@kc.net> <1001023115013.ZM74191@noah.scripps.edu> Message-ID: <20001107220604.D678@beelzebub> On 23 October 2000, Michel Sanner said: > Hello, > > I had a look at Python2.0 over the week end and I noticed that the > installation procedure creates a site-packages directory under $prefix > but not under $exec_prefix. > > Is there a consensus about wher packages containing a mix of .py and > .so files should go ? There's not just a consensus on this: there is an iron-clad, hard-coded, disobey-it-at-your-peril policy dictated by the BDFL. Specifically, "impure" module distributions are completely installed under exec_prefix. I believe this is documented in the new "Installing Python Modules" manual. (If it's not, that's my fault.) > Should we ise the PyOpenGL strategy of extending the path with a > sub-directory for platform specific stuff at run time ? Absolutely not. I think it's pretty much agreed that this is madness. > or should we > place all .so files in lib-dynload ? Absolutely not. That directory is for standard extensions, not third-party additions. > or should we have a site-packages > under $exec_prefix and duplicate the .py files (my concern here is not > disk space but rather keeping these files in sync!) This is the same problem as with C libraries -- if there are N copies of libfoo.a installed (for N architectures), should there be N copies of foo.h, or 1 copy? The traditional answer is to save the great expense of (N-1)*10k (or however big foo.h is) and keep 1 copy. Obviously disk space is no argument nowadays, but the synchronization thing still comes up. This argument is a red herring. In fact, life is *harder* if you keep 1 copy of foo.h (or foo.py) for N copies of libfoo.a (or foo.so), and here's why: imagine that foo 1.0.4 is installed for Linux and Solaris. Everything works fine for many months. Then someone comes along and installs foo 1.1.2, but only on Linux. Now your Linux directories have the 1.1.2 version of libfoo.a and foo.h, and your Solaris directories have libfoo.a from 1.0.4, but foo.h from 1.1.2. You *lose*! If you kept separate copies of the header file for each architecture, then you'd still have the minor headache of different versions of foo, but at least foo would be internally consistent on each architecture. When you try to share files, though, then *you* *will* *lose*. Based on a true story... (hello, Jeremy!) > I know I have already brought this up ! so forgive me .... but I > rather have a mechanism allowing Python to search platform dependent > extensions first (to get fast versions if they are available) and then > search platform independent packages even if a package match has be > found earlier. If you want foo.so under exec-prefix and foo.py under prefix, then the will have to be separately distributed. If there are *any* extensions in your module distribution, the entire thing is installed under exec-prefix. I think in this case foo.so would shadow foo.py, and anyways this exec-prefix had better not be visible to hosts that can't load foo.so! Greg -- Greg Ward - maladjusted nerd gward@python.net http://starship.python.net/~gward/ If you can read this, thank a programmer. From gward@python.net Tue Nov 7 22:15:03 2000 From: gward@python.net (Greg Ward) Date: Tue Nov 7 22:15:03 2000 Subject: [Distutils] Installation directory In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B012A8351@UKRUX002.rundc.uk.origin-it.com>; from Paul.Moore@uk.origin-it.com on Tue, Oct 24, 2000 at 02:59:49PM +0100 References: <714DFA46B9BBD0119CD000805FC1F53B012A8351@UKRUX002.rundc.uk.origin-it.com> Message-ID: <20001107221310.E678@beelzebub> On 24 October 2000, Moore, Paul said: > Agreed. I guess that is what I should do. Two questions spring to mind: > 1. Is it possible for me to specify a default --install-lib value which will > be used in all installs unless overridden (effectively a site preferences > file for distutils)? If not, is it feasible to add such a thing? Create distutils.cfg in the Distutils package dir -- typically C:\Python\Lib\distutils on Windows. Contents: [install] install-lib=C:\Python\SiteLib for whatever value of "C:\Python\SiteLib" you prefer. For the record, this *is* documented now. Should be in Fred's latest doc snapshot, which I think is on SourceForge. Then make sure that this is always added to Python's search path. There's more than one way to do it (oops! did I say that on a *Python* list? ;-), but the easiest and most straightforward is a .pth file. Eg. create "site.pth" in C:\Python, containing exactly one line: "SiteLib". (This should work because "SiteLib" is relative to "C:\Python".) Completely untested, off-the-cuff, no idea if it'll work on Windows, use at your own risk, etc. etc. Greg -- Greg Ward - programmer-at-big gward@python.net http://starship.python.net/~gward/ I have the power to HALT PRODUCTION on all TEENAGE SEX COMEDIES!! From gward@python.net Tue Nov 7 22:17:01 2000 From: gward@python.net (Greg Ward) Date: Tue Nov 7 22:17:01 2000 Subject: [Distutils] Some suggested additions for distutils In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B012A8350@UKRUX002.rundc.uk.origin-it.com>; from Paul.Moore@uk.origin-it.com on Tue, Oct 24, 2000 at 02:39:11PM +0100 References: <714DFA46B9BBD0119CD000805FC1F53B012A8350@UKRUX002.rundc.uk.origin-it.com> Message-ID: <20001107221515.F678@beelzebub> On 24 October 2000, Moore, Paul said: > Missed that one. I think I was looking at the help for the install command, > not at the global help. *All* Distutil commands have a --dry-run option -- it's a universal constant, along with --verbose. One caveat: the "install" command is completely filesystem-driven, so if you do a dry-run build and install, it looks like nothing would get installed, since there's nothing actually in the "build" tree to drive installation. Bug? feature? I dunno... Greg -- Greg Ward - Linux nerd gward@python.net http://starship.python.net/~gward/ Just because you're paranoid doesn't mean they *aren't* out to get you. From gward@python.net Tue Nov 7 22:20:03 2000 From: gward@python.net (Greg Ward) Date: Tue Nov 7 22:20:03 2000 Subject: [Distutils] Network Admin Full Python 2.0 Setup In-Reply-To: <15118451682.20001025160515@clarisay.com>; from mark.evans@clarisay.com on Wed, Oct 25, 2000 at 04:05:15PM -0500 References: <15118451682.20001025160515@clarisay.com> Message-ID: <20001107221726.G678@beelzebub> On 25 October 2000, Mark Evans said: > As a network admin with dozens of machines to configure, how do > you recommend I proceed. The machines will need the following basic > configuration: > > - Python 2.0 Final (BeOpen version) > - win32all-135 > - wxPython 2.2 > - NumPy 17.0 > > The distutils, unfortunately, will only work for NumPy. My > question is about the basic Python system and the other add-ons. At one point, Thomas Heller was working on a setup script for win32all -- dunno what became of that. Also, I thought Robin had a setup script for wxPython. Haven't tried it or looked at it myself, though. In other words, "stay tuned to this channel and see what pops up". ;-) Of course, if it were me, I'd just setup an NFS server and mount /usr/local from it on all the machines... ;-) Greg -- Greg Ward - Unix bigot gward@python.net http://starship.python.net/~gward/ Am I accompanied by a PARENT or GUARDIAN? From jack@oratrix.nl Wed Nov 8 05:05:30 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed Nov 8 05:05:30 2000 Subject: [Distutils] distutils Mac changes still pending Message-ID: <20001108100229.1948631C49C@snelboot.oratrix.nl> Greg, you still don't seem to have checked in all the Mac mods I sent you 6 weeks ago, for using the new GetArgs dialogs and such. Did it slip by, or is there a reason you haven't checked them in? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From calvin@cs.uni-sb.de Wed Nov 8 08:54:01 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Wed Nov 8 08:54:01 2000 Subject: [Distutils] Distutils 1.0.1 releasee In-Reply-To: <20001107213237.A678@beelzebub> Message-ID: Hi all, Im Jahre 2000 schrieb Greg Ward: > but I don't think the two should be confused. Yes, I agree. >all we can do for run-time configuration is promote a standard place for >Python applications to install and find such config data, whereas we can >specify everything about build-time config data. So which are you >talking about here? I am talking about both, but lets have a look my source: class MyDistribution(Distribution): def __init__(self, attrs=None): Distribution.__init__(self, attrs=attrs) self.config_file = self.get_name()+"Conf.py" def create_conf_file(self, directory, data=[]): """generate a configuration file with all metadata the data supplied in the 'data' argument""" data.insert(0, "# this file is automatically created by setup.py") filename = os.path.join(directory, self.config_file) # add metadata metanames = dir(self.metadata) + \ ['fullname', 'contact', 'contact_email'] for name in metanames: method = "get_" + name cmd = "%s = %s" % (name, `getattr(self.metadata, method)()`) data.append(cmd) util.execute(write_file, (filename, data), "creating %s" % filename, self.verbose>=1,self.dry_run) So create_conf_file generates a file Conf.py. You can call the function from any place in your code (or you can call it never). I call in two places: 1) If I need to store some configuration values, my custom "config" command creates this file with the config values in the 'data' list. 2) When installing. This way the Conf.py is installed as a module and my program has runtime information by importing the module. I think this approach is nice because you can have both configuration and runtime information stored in the file. Furthermore the patch is just adding a function so it does not break any existing apps. Bastian From R.Liebscher@gmx.de Wed Nov 8 09:55:02 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Wed Nov 8 09:55:02 2000 Subject: [Distutils] extra files into the package dir References: <00be01c0387f$64287930$f73f93cd@visionart.com> <39ED9849.A0AF5CBF@gmx.de> <39EF0380.2D4E5A87@gmx.de> <20001107215541.C678@beelzebub> Message-ID: <3A0968BF.801F6801@gmx.de> This is a multi-part message in MIME format. --------------7004C26B0F2FA02762F9DA02 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Greg Ward wrote: > > [Berthold Höllmann mentions...] > > There is support for installing data files, but they get to data > > directories. When writing setup.py for biggles, I had the problem, > > that a config file had to go to the package directory. All I did was adding > > > > class my_install_data (install_data): > > def finalize_options (self): > > self.set_undefined_options('install', > > ('install_lib', 'install_dir'), > > ('root', 'root'), > > ('force', 'force'), > > ) > > > > and > > > > cmdclass = {'install_data': my_install_data}, > > data_files = [('biggles', ["src/config.ini"])] > > > > to the setup command line. This got everything to the right place. > > [Rene Liebscher replies...] > > This is probably the simplest possible solution. My approach goes > > further, it handles also MANIFEST.in-like templates and some other > > special things, and it was written primary to replace distutils' > > install_data as whole. > > (Greg, do you remember my mail of 06/26/2000? > > http://www.python.org/pipermail/distutils-sig/2000-June/001671.html ) > > As it turns out, the Berthold's "my_install_data" solution is really a > bare minimum -- the "install_data" command should work that way, or have > an option to work that way. I wrote a setup script for IDLE that does > basically the same as Berthold's, and if the Distutils installed their > own config file, the Distutils setup script would also need this -- > d'oh! I don't think I should have to extend the Distutils in order to > install the Distutils -- droit de seigneur, in a sense. ;-) > > Rene, I originally thought your "DataFiles" concept was overkill, but I > originally thought having a class to describe extensions was overkill > too. If nothing else, introducing a simple class may be the only sane > way to maintain backwards compatibility with the current "install_data > class. Here's a somewhat simpler conception of the "DataFiles" class... I changed my my_install_data.py a little bit too. > > DataFiles -- > represents a collection of files to be installed in a common > location, the "base directory". It is called in my class copy_to, but it is only a name. > > Files in the collection are fragmentary paths that are concatenated > to the base directory at install time to create a complete > installation path. This is at my class, the files list parameter. > > The base directory may be a literal path, or it may use any of the > configuration variables allowed in installation directories -- > dist_name > dist_version > dist_fullname > py_version > py_version_short > sys_prefix > prefix > sys_exec_prefix > exec_prefix > > as well as the config vars corresponding to the installation directory > options to the "install" command (most of which are just one of the > entries in an installation scheme): > install_base > install_platbase > install_root > install_purelib > install_platlib > install_headers > install_scripts > install_data (?maybe obsolete?) Can you read my thoughts, I was putting this in my class when I got your email. > Thus, a base directory of "$install_base" would expand to > /usr/lib/python2.0/site-packages on a typical Linux installation, > or C:\Python on a Windows installation. Or you could use > "$install_base/mypkg" to install to (eg.) C:\Python\mypkg -- > presumably the directory where modules from your distribution > get installed. (As usual, Unix paths would be translated to > native paths by the Distutils, so that setup scripts port across > operating systems.) > > (There probably ought to be a special name for "the directory where > the highest-level package from this module distribution is installed", > which would expand to eg. /usr/lib/python1.5/site-packages/distutils.) > > This gets rid of dependence on the manifest machinery -- since that's > now been factored out into a separate class (FileList, in > distutils.filelist), developers can use it if they want. Or they can > use the standard 'glob' module if that's good enough, or they can list > files manually if *that's* good enough. Supporting an additional template parameter is about ten lines of code. For PyOpenGL it looks then like this: ------------------------------------------------------------- data_files = [ Data_Files( copy_to = '$install_lib/OpenGL/Demo', strip_dirs = 2, template=[ # take the whole tree 'graft py/Demo', # python files are already installed 'global-exclude *.py*', 'global-exclude Cvs/*', 'global-exclude CVS/*' ], ) ], ------------------------------------------------------------- For an example how it looks if you have to specify the files even by using glob(), look at the setup file of 4Suite ftp://ftp.fourthought.com/pub/4Suite/4Suite-0.9.1.tar.gz (glob doesn't work recursiv through subdirectories.) To show you what I mean: the code (about 20% of 4Suite's data files section) -------------------------------------- ('4XSLT/demo',glob.glob('Xslt/demo/*.*')), ('4XSLT',['Xslt/README', 'Xslt/ChangeLog', 'Xslt/TODO', ]), ('4XSLT',glob.glob('Xslt/docs/*.*')), ('4XSLT/test_suite',['Xslt/test_suite/README']), ('4XSLT/test_suite',glob.glob('Xslt/test_suite/*.*')), ('4XSLT/test_suite/borrowed',glob.glob('Xslt/test_suite/borrowed/README')), ('4XSLT/test_suite/borrowed',glob.glob('Xslt/test_suite/borrowed/*.*')), ('4XSLT/test_suite/profile_data',glob.glob('Xslt/test_suite/profile_data/*.*')), ('4XSLT/test_suite/graph_trav',glob.glob('Xslt/test_suite/borrowed/graph_trav/README')) , ('4XSLT/test_suite/graph_trav',glob.glob('Xslt/test_suite/borrowed/graph_trav/*.*')), --------------------------------------- could be replaced by something like this --------------------------------------- Data_Files( copy_to = '$install_data/4XSLT', strip_dirs = 1, # this is a number template=[ # take the whole tree 'graft Xslt/demo', 'graft Xslt/doc', 'graft Xslt/test_suite', 'include Xslt/README', 'include Xslt/ChangeLog', 'include Xslt/TODO', ], ) --------------------------------------- I think the second is easier. Kind regards Rene Liebscher --------------7004C26B0F2FA02762F9DA02 Content-Type: text/plain; charset=us-ascii; name="my_install_data.py" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="my_install_data.py" """my_install_data.py Provides a more sophisticated facility to install data files than distutils' install_data does. You can specify your files as a template like in MANIFEST.in and you have more control over the copy process. """ # created 2000/08/01, Rene Liebscher ########################################################################### # import some modules we need import os,sys,string from types import StringType,TupleType,ListType from distutils.util import change_root,subst_vars from distutils.filelist import FileList from distutils.command.install_data import install_data ########################################################################### # a container class for our more sophisticated install mechanism class Data_Files: """ container for list of data files. supports a directory where to copy files supports variable substitution e.g. '$install_lib','$install_header',... supports templates as in MANIFEST.in supports preserving of paths in filenames eg. foo/xyz is copied to base_dir/foo/xyz supports stripping of leading dirs of source paths eg. foo/bar1/xyz, foo/bar2/abc can be copied to bar1/xyz, bar2/abc """ def __init__(self,files=None,copy_to=None,template=None,preserve_path=1,strip_dirs=0): self.files = files self.copy_to = copy_to self.template = template self.preserve_path = preserve_path self.strip_dirs = strip_dirs self.finalized = 0 def warn (self, msg): sys.stderr.write ("warning: %s: %s\n" % ("install_data", msg)) def debug_print (self, msg): """Print 'msg' to stdout if the global DEBUG (taken from the DISTUTILS_DEBUG environment variable) flag is true. """ from distutils.core import DEBUG if DEBUG: print msg def finalize(self): """ complete the files list by processing the given template """ if self.finalized: return if self.files == None: self.files = [] if self.template != None: if type(self.template) == StringType: self.template = string.split(self.template,";") filelist = FileList(self.warn,self.debug_print) for line in self.template: filelist.process_template_line(string.strip(line)) filelist.sort() filelist.remove_duplicates() self.files.extend(filelist.files) self.finalized = 1 # end class Data_Files ########################################################################### # a more sophisticated install routine than distutils install_data class my_install_data (install_data): def check_data(self,d): """ check if data are in new format, if not create a suitable object. returns finalized data object """ if not isinstance(d, Data_Files): self.warn(("old-style data files list found " "-- please convert to Data_Files instance")) if type(d) is TupleType: if len(d) != 2 or not (type(d[1]) is ListType): raise DistutilsSetupError, \ ("each element of 'data_files' option must be an " "Data File instance, a string or 2-tuple (string,[strings])") d = Data_Files(copy_to=d[0],files=d[1]) else: if not (type(d) is StringType): raise DistutilsSetupError, \ ("each element of 'data_files' option must be an " "Data File instance, a string or 2-tuple (string,[strings])") d = Data_Files(files=[d],preserve_path=0) d.finalize() return d def run(self): self.outfiles = [] install_cmd = self.get_finalized_command('install') config_vars = install_cmd.config_vars.copy() config_vars.update({ "install_purelib": install_cmd.install_purelib, "install_platlib": install_cmd.install_platlib, "install_lib": install_cmd.install_lib, "install_headers": install_cmd.install_headers, "install_scripts": install_cmd.install_scripts, "install_data": install_cmd.install_data, }) for d in self.data_files: d = self.check_data(d) # copy to an other directory if d.copy_to != None: if not os.path.isabs(d.copy_to): # relative path to install_dir dir = os.path.join(self.install_dir, d.copy_to) elif install_cmd.root: # absolute path and alternative root set dir = change_root(self.root,d.copy_to) else: # absolute path dir = d.copy_to else: # simply copy to install_dir dir = install_dir # warn if necceassary self.warn("setup script did not provide a directory to copy files to " " -- installing right in '%s'" % self.install_dir) # replace variables ($install_lib, ...) in dir dir = os.path.normpath(subst_vars(dir,config_vars)) # create path self.mkpath(dir) # copy all files for src in d.files: if d.strip_dirs > 0: dst = string.join(string.split(os.path.normcase(src),os.sep)[d.strip_dirs:],os.sep) else: dst = src if d.preserve_path: # preserve path in filename self.mkpath(os.path.dirname(os.path.join(dir,dst))) out = self.copy_file(src, os.path.join(dir,dst)) else: out = self.copy_file(src, dir) if type(out) is TupleType: out = out[0] self.outfiles.append(out) return self.outfiles def get_inputs (self): inputs = [] for d in self.data_files: d = self.check_data(d) inputs.append(d.files) return inputs def get_outputs (self): return self.outfiles ########################################################################### --------------7004C26B0F2FA02762F9DA02-- From akuchlin@mems-exchange.org Wed Nov 8 13:12:04 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed Nov 8 13:12:04 2000 Subject: [Distutils] Catalog-SIG created Message-ID: A mailing list for the Catalog SIG has been created, to discuss the design and construction of a Vaults/CPAN/LSM-like index for Python. Web pages for the SIG don't exist yet, but will be created soon. The SIG's charter: The Python Catalog SIG aims at producing a master index of Python software and other resources. It will begin by figuring out what the requirements are, converging on a design for the data schema, and producing an implementation. ("Implementation" will almost certainly include mean a set of CGI scripts for browsing the catalog, and may also contain a standard library module for automatically fetching & installing modules, if the SIG decides that's a worthwhile feature.) --amk From fdrake@acm.org Wed Nov 8 14:55:12 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed Nov 8 14:55:12 2000 Subject: [Python-Dev] Re: [Distutils] Catalog-SIG created In-Reply-To: References: Message-ID: <14857.44698.672928.206695@cj42289-a.reston1.va.home.com> Mark W. Alexander writes: > Is there another way to subscribe, or did I just jump the gun? You can get to the Mailman interface at: http://www.python.org/mailman/listinfo/catelog-sig/ The Web pages aren't actually there yet; Andrew will get to this when he can, I'm sure. ;) -Fred -- Fred L. Drake, Jr. PythonLabs at Digital Creations From robin@alldunn.com Wed Nov 8 14:56:05 2000 From: robin@alldunn.com (Robin Dunn) Date: Wed Nov 8 14:56:05 2000 Subject: [Distutils] Catalog-SIG created References: Message-ID: <010e01c049bd$d42e8900$3225d2d1@ARES> > > The catalog-sig link off the sigs page (http://www.python.org/sigs/) > gives me a 404 Not Found. > > Is there another way to subscribe, or did I just jump the gun? > http://www.python.org/mailman/listinfo/catalog-sig -- Robin Dunn Software Craftsman robin@AllDunn.com http://wxPython.org Java give you jitters? http://wxPROs.com Relax with wxPython! From trotts1@llnl.gov Wed Nov 8 15:37:01 2000 From: trotts1@llnl.gov (Issac Trotts) Date: Wed Nov 8 15:37:01 2000 Subject: [Distutils] CFLAGS and g++ References: <20001108145103.G14410@kronos.cnri.reston.va.us> Message-ID: <3A09B80E.EC9A47CE@llnl.gov> Does anyone know how to get distutils to use g++ instead of gcc and how to specify the CFLAGS? Just setting CFLAGS and CC in the setup.py script for FXPy doesn't do the job. Thanks, Issac From trentm@ActiveState.com Wed Nov 8 16:09:01 2000 From: trentm@ActiveState.com (Trent Mick) Date: Wed Nov 8 16:09:01 2000 Subject: [Python-Dev] Re: [Distutils] Catalog-SIG created In-Reply-To: <14857.44698.672928.206695@cj42289-a.reston1.va.home.com>; from fdrake@acm.org on Wed, Nov 08, 2000 at 02:50:50PM -0500 References: <14857.44698.672928.206695@cj42289-a.reston1.va.home.com> Message-ID: <20001108130739.H27185@ActiveState.com> On Wed, Nov 08, 2000 at 02:50:50PM -0500, Fred L. Drake, Jr. wrote: > http://www.python.org/mailman/listinfo/catelog-sig/ .replace("catelog", "catalog") :) -- Trent Mick TrentM@ActiveState.com From R.Liebscher@gmx.de Thu Nov 9 05:21:01 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Thu Nov 9 05:21:01 2000 Subject: [Distutils] extra files into the package dir References: <00be01c0387f$64287930$f73f93cd@visionart.com> <39ED9849.A0AF5CBF@gmx.de> <39EF0380.2D4E5A87@gmx.de> <20001107215541.C678@beelzebub> <3A0968BF.801F6801@gmx.de> Message-ID: <3A0A79E6.68D7C710@gmx.de> It seems I attached the wrong version of my_install_data.py at my last email. You can find the right one at http://www.informatik.htw-dresden.de/~htw7192/PyOpenGL/my_install_data.py (The only difference is where the substitution of "$install_xxx" variables is done.) Kind regards Rene Liebscher From Jason.Tishler@dothill.com Fri Nov 10 09:34:01 2000 From: Jason.Tishler@dothill.com (Jason Tishler) Date: Fri Nov 10 09:34:01 2000 Subject: [Distutils] Cygwin Python DLL and Shared Extension Patch Message-ID: <20001110093336.K209@dothill.com> --zN+5Yck3deUF6VTH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Attached is a patch that builds Cygwin Python with its core as a DLL -- similar to the way that one builds Win32 Python. Once Cygwin Python is built as a "shared library" (i.e., DLL), one can build extensions using the same procedure as on other UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. Actually, attached is two versions of the same patch. The first one is the real patch but requires autoconf. The second one was generated after I ran autoconf and hence only requires the more typical build environment. Use the following procedure to patch and build Cygwin Python if you *have* autoconf: $ tar -xvzf Python-2.0.tar.gz $ cd Python-2.0 $ patch -p1 <../CygwinPython-2.0-minimal.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install Use the following procedure to patch and build Cygwin Python if you *do not* have autoconf: $ tar -xvzf Python-2.0.tar.gz $ gunzip CygwinPython-2.0-full.patch.gz $ cd Python-2.0 $ patch -p1 <../CygwinPython-2.0-full.patch $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. My goal is to ultimately submit the patch (redone against Python CVS) to the Python patch collector. I am hoping interested people will help me refine the patch before submittal. The following is an annotated ChangeLog for the patch: Wed Nov 8 23:22:46 2000 Jason Tishler * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? Any feedback is greatly appreciated. Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corporation Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com --zN+5Yck3deUF6VTH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="CygwinPython-2.0-minimal.patch" diff -rc Python-2.0.orig/Makefile.in Python-2.0/Makefile.in *** Python-2.0.orig/Makefile.in Mon Oct 16 17:50:06 2000 --- Python-2.0/Makefile.in Wed Nov 1 07:37:11 2000 *************** *** 131,136 **** --- 131,137 ---- LIBRARY= libpython$(VERSION).a LDLIBRARY= @LDLIBRARY@ + @SET_DLLLIBRARY@ # Default target all: $(LIBRARY) python$(EXE) sharedmods *************** *** 247,252 **** --- 248,257 ---- $(INSTALL_DATA) libpython$(VERSION).so $(LIBDIR); \ else true; \ fi + if test -f "$(DLLLIBRARY)"; then \ + $(INSTALL_DATA) $(DLLLIBRARY) $(BINDIR); \ + else true; \ + fi # Install the manual page maninstall: *************** *** 371,379 **** else true; \ fi; \ done ! @if test -d $(LIBRARY); then :; else \ ! $(INSTALL_DATA) $(LIBRARY) $(LIBPL)/$(LIBRARY) ; \ ! $(RANLIB) $(LIBPL)/$(LIBRARY) ; \ fi $(INSTALL_DATA) Modules/config.c $(LIBPL)/config.c $(INSTALL_DATA) Modules/python.o $(LIBPL)/python.o --- 376,384 ---- else true; \ fi; \ done ! @if test -d $(LDLIBRARY); then :; else \ ! $(INSTALL_DATA) $(LDLIBRARY) $(LIBPL)/$(LDLIBRARY) ; \ ! $(RANLIB) $(LIBPL)/$(LDLIBRARY) ; \ fi $(INSTALL_DATA) Modules/config.c $(LIBPL)/config.c $(INSTALL_DATA) Modules/python.o $(LIBPL)/python.o diff -rc Python-2.0.orig/Modules/Makefile.pre.in Python-2.0/Modules/Makefile.pre.in *** Python-2.0.orig/Modules/Makefile.pre.in Mon Oct 16 17:49:33 2000 --- Python-2.0/Modules/Makefile.pre.in Wed Nov 1 07:37:11 2000 *************** *** 105,110 **** --- 105,111 ---- LIBRARY= ../libpython$(VERSION).a LDLIBRARY= ../@LDLIBRARY@ + @SET_DLLLIBRARY@ # === Rules === *************** *** 126,131 **** --- 127,140 ---- $(LINKCC) $(LDFLAGS) $(LINKFORSHARED) $(MAINOBJ) \ $(LDLIBRARY) $(MODLIBS) $(LIBS) $(SYSLIBS) -o python$(EXE) $(LDLAST) mv python$(EXE) ../python$(EXE) + + # This rule builds the Python DLL for Cygwin + $(DLLLIBRARY): $(LIBRARY) + test -d cygwin || mkdir cygwin + (cd cygwin; ar x ../$^) + dlltool --export-all --output-def $(basename $@).def cygwin/*.o + gcc -shared -Wl,--enable-auto-image-base -Wl,--out-implib=$(LDLIBRARY) -o $@ $(basename $@).def cygwin/*.o $(MODLIBS) $(LIBS) $(SYSLIBS) + rm -fr cygwin clean: -rm -f *.o python$(EXE) core *~ [@,#]* *.old *.orig *.rej diff -rc Python-2.0.orig/Modules/makesetup Python-2.0/Modules/makesetup *** Python-2.0.orig/Modules/makesetup Mon Oct 16 17:49:33 2000 --- Python-2.0/Modules/makesetup Wed Nov 1 08:07:29 2000 *************** *** 79,84 **** --- 79,102 ---- NL='\ ' + # Default module names to so that their basename ends in "module" + module='module' + + # Cygwin specific definitions: + # 1. do not append ${module} to the end of Cygwin module names + # 2. use -DUSE_DL_IMPORT when compiling shared extensions that are not + # part of the Python core + # 3. use -L$(LIBPL) -lpython$(VERSION) when linking shared extensions + # that are not part of the Python core + case `uname -s` in + CYGWIN*) module='' + if test $srcdir != . + then + CygwinFlags='-DUSE_DL_IMPORT' + CygwinLibs='-L$(LIBPL) -lpython$(VERSION)' + fi;; + esac + # Main loop for i in ${*-Setup} do *************** *** 149,154 **** --- 167,173 ---- *.so) libs="$libs $arg";; *.sl) libs="$libs $arg";; /*.o) libs="$libs $arg";; + *.def) libs="$libs $arg";; *.o) srcs="$srcs `basename $arg .o`.c";; *.[cC]) srcs="$srcs $arg";; *.cc) srcs="$srcs $arg";; *************** *** 196,202 **** case $doconfig in no) cc="$cc \$(CCSHARED)";; esac ! rule="$obj: $src; $cc $cpps \$(CFLAGS) -c $src" echo "$rule" >>$rulesf done case $doconfig in --- 215,221 ---- case $doconfig in no) cc="$cc \$(CCSHARED)";; esac ! rule="$obj: $src; $cc $cpps \$(CFLAGS) $CygwinFlags -c $src" echo "$rule" >>$rulesf done case $doconfig in *************** *** 206,219 **** do case $objs in *$mod.o*) base=$mod;; ! *) base=${mod}module;; esac file="$base\$(SO)" case $doconfig in no) SHAREDMODS="$SHAREDMODS $file";; esac rule="$file: $objs" ! rule="$rule; \$(LDSHARED) $objs $libs -o $file" echo "$rule" >>$rulesf done done --- 225,238 ---- do case $objs in *$mod.o*) base=$mod;; ! *) base=${mod}${module};; esac file="$base\$(SO)" case $doconfig in no) SHAREDMODS="$SHAREDMODS $file";; esac rule="$file: $objs" ! rule="$rule; \$(LDSHARED) $objs $libs $CygwinLibs -o $file" echo "$rule" >>$rulesf done done diff -rc Python-2.0.orig/acconfig.h Python-2.0/acconfig.h *** Python-2.0.orig/acconfig.h Mon Oct 16 17:50:06 2000 --- Python-2.0/acconfig.h Wed Nov 1 07:37:11 2000 *************** *** 179,181 **** --- 179,193 ---- /* Leave that blank line there-- autoheader needs it! */ + + @BOTTOM@ + + #ifdef __CYGWIN__ + #ifdef USE_DL_IMPORT + #define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE + #define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE + #else + #define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE + #define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE + #endif + #endif diff -rc Python-2.0.orig/configure.in Python-2.0/configure.in *** Python-2.0.orig/configure.in Mon Oct 16 17:50:06 2000 --- Python-2.0/configure.in Wed Nov 1 07:37:11 2000 *************** *** 217,226 **** # LDLIBRARY is the name of the library to link against (as opposed to the # name of the library into which to insert object files). On systems # without shared libraries, LDLIBRARY is the same as LIBRARY (defined in ! # the Makefiles). AC_SUBST(MAKE_LDLIBRARY) AC_SUBST(LDLIBRARY) LDLIBRARY='' # LINKCC is the command that links the python executable -- default is $(CC). # This is altered for AIX in order to build the export list before --- 217,229 ---- # LDLIBRARY is the name of the library to link against (as opposed to the # name of the library into which to insert object files). On systems # without shared libraries, LDLIBRARY is the same as LIBRARY (defined in ! # the Makefiles). On Cygwin LDLIBRARY is the import library, DLLLIBRARY is the ! # shared (i.e., DLL) library. AC_SUBST(MAKE_LDLIBRARY) AC_SUBST(LDLIBRARY) + AC_SUBST(SET_DLLLIBRARY) LDLIBRARY='' + SET_DLLLIBRARY='' # LINKCC is the command that links the python executable -- default is $(CC). # This is altered for AIX in order to build the export list before *************** *** 263,268 **** --- 266,275 ---- beos*) LDLIBRARY='libpython$(VERSION).so' ;; + cygwin*) + LDLIBRARY='libpython$(VERSION).dll.a' + SET_DLLLIBRARY='DLLLIBRARY= $(basename $(LDLIBRARY))' + ;; esac AC_MSG_RESULT($LDLIBRARY) *************** *** 272,278 **** LDLIBRARY='libpython$(VERSION).a' MAKE_LDLIBRARY="true" else ! MAKE_LDLIBRARY='$(MAKE) $(LDLIBRARY)' fi AC_PROG_RANLIB --- 279,288 ---- LDLIBRARY='libpython$(VERSION).a' MAKE_LDLIBRARY="true" else ! case $MACHDEP in ! cygwin*) MAKE_LDLIBRARY='$(MAKE) -C Modules ../$(DLLLIBRARY)';; ! *) MAKE_LDLIBRARY='$(MAKE) $(LDLIBRARY)';; ! esac fi AC_PROG_RANLIB *************** *** 297,302 **** --- 307,313 ---- if test -z "$LN" ; then case $ac_sys_system in BeOS*) LN="ln -s";; + CYGWIN*) LN="ln -s";; *) LN=ln;; esac fi *************** *** 539,550 **** AC_SUBST(CCSHARED) AC_SUBST(LINKFORSHARED) # SO is the extension of shared libraries `(including the dot!) ! # -- usually .so, .sl on HP-UX AC_MSG_CHECKING(SO) if test -z "$SO" then case $ac_sys_system in hp*|HP*) SO=.sl;; *) SO=.so;; esac fi --- 550,562 ---- AC_SUBST(CCSHARED) AC_SUBST(LINKFORSHARED) # SO is the extension of shared libraries `(including the dot!) ! # -- usually .so, .sl on HP-UX, .dll on Cygwin AC_MSG_CHECKING(SO) if test -z "$SO" then case $ac_sys_system in hp*|HP*) SO=.sl;; + CYGWIN*) SO=.dll;; *) SO=.so;; esac fi *************** *** 602,607 **** --- 614,620 ---- fi;; SCO_SV*) LDSHARED="cc -G -KPIC -Ki486 -belf -Wl,-Bexport";; Monterey*) LDSHARED="cc -G -dy -Bdynamic -Bexport -L/usr/lib/ia64l64";; + CYGWIN*) LDSHARED="gcc -shared";; *) LDSHARED="ld";; esac fi --zN+5Yck3deUF6VTH Content-Type: application/x-gunzip Content-Disposition: attachment; filename="CygwinPython-2.0-full.patch.gz" Content-Transfer-Encoding: base64 H4sICPoXADoAA0N5Z3dpblB5dGhvbi0yLjAtZnVsbC5wYXRjaADsXXtX28a2/5us+yEmjltj go3eD6izQoG23BLIAs5puk5OHSHLWI0t+Uoygba5n/3uPaOX7bGRjAG757LS2hrNaz/mN3vv ebjjdrukEdjk/V3U872G1BSafuBe77yzPjtdt+80XS/3Lp/8Ymtra16xjXe+R87siIgaEfVd VdgVNCIJgvCi0WjMqHPjF6dDTv0bQkQi6LuyviuKrMzW+B9tXJTFbVHWCE3ASlmCTuB74wUh 8O/k+Pvz/fNfWxt992pIm6xu/vPo/OL47LTetDDDYZKF0L+3acLbF6/J24ujy/bhyUmaRCt9 RQ6drjXqRySygmsngiSr39/d2KhuxhnrJGns6MNRnYQ9K3A6A78TcumQFH1bUqWMDkkxICGl YwNrPj69uNw/OWkf7l/u1wmPnNAntAOHx+f1PfKRFnT6obMRBSMnSei6QNbGhtslkRNGpNEl lepmRmG9skeinuNB7te8dsfywtP3x6dJc68nm3vNmotZduyFEXAJaycDyxtZfTK0rh14B08u e7nLZY+si9uybjL2UG5MUQXtJF87vue8eAlf3qY0dkgmmJi83T2ClUCZl3wyczTC1/cn9Z1c 2l5W7nz/FJJnZyMJE6Ybeed3Rn0n3LF9r+teN+2sjiRlbjEm/6afFUtSqA7JurYtG0pOhxbh 2mFpvh1yOXdYlHeHz8+9zkxMjMumgDUMpvCRn4WPlfy8E7ipmLuyzMfNGeXLYaigbouikMNQ miDyMLTZ3LkfRjFXMRBttVrkHCnAb5jI7Z+kAaSLuf5J+raoCJleowBPfz44YNr3w8n+jxdM pU5//uHs/OKn/fOjQ0x4t398evb9f9djtSKTyvruDJ/isuzz4tcL9rXhjwM6Lbp/cVmnVQ1u xt8CB/LPwAL494pc9tyQBEAwuRq5/U5IoZDJkwB7SNcPyMHd9RdQl9fjQLubAyQKq8kItWl2 8tdfZPC54wbxM82yaSev94gVkFvsVfU3VrzT70e+3wceOrdDP4gaCMyNhj+KhqOo0XG60N6V FTqeNXBI9W29iUmssp0tGCFYx7Vtkwab2Ejjl/421OVZV32nYY0iv+EOANsbWEf8EuqGxCHo T2uM78DZ6tv5zc2XDe1MMICZLCWf6pfddyxvl8qnQV8TrGpMTrYfOGTrf8m/3m6/+vcWvu93 8P8wOOEjcH6/HwoGMPZCJxoNeQMzfTl3+Ke5Sg/8rGR+yBu7MOolc/aQ181tmBfSAQWPoiAl 4+n0pFXDAVJDLr7OmToD2ihBGYHm+gSsjahnRajEoHip+BwPFBtUssLyV6AO9q1VY5+1ZDgw VSfh0LHdrmsTELrruZHre+EuzYB/YpN0fOL5EbGGQ6ibVP9k1XzFPuAAwkS/m9SW72VaidQk I1TEw39cHAEQtY/fvT87vyRfcEKz/cHQ7bvedWykEec2crwQe8Hog0RsP60M/oZWEGGbufGL qpRmkeP2TpK5hTT6k6jJWoeGP3PbzjeX78actm0cbJ9GVAqN8BOhOHDw64+/HJ9u1TcSIdTG zL9qGNiIGy9bpMmABXrFLD/G0B/61nXYqk2wrpbPcuJeYY55xNZiW3BvD744oWWjDuAU8M4C mfV9fwhPCH8uqk71z63GBar1V0jt+PxpQQGtVXNaLGowLehyztzZAoO4voGGf9iqVPGDVMFc r0Ankvf9ee8Rema8f83Kg8bObwDLA4fxNX6QTxnKQUbS9D817Vz2f9kH/54oMVGhbc94z+WR qW1LgpSzm6mKVDs+s5AIhUpI9qCftg1VAqR/rG4eHMSTZtowFRk12nD6goz+1e+7VHn2CBaq 2sNhSIvG02/Dpm8rcXG754ObgWUr5M0b+iXsZnYnfpnuGnWERHVbksScVJ+MhGpuACyFHp6I JAFEJOZcG1D3HJnQxzAlcasKY7jpw1hGLWrhExBHSYK0OBHR8Ssb62OUx+Y+pRxzAqEXZ/XK vTxlbITp9wIKZg+kinVVppuImYtvd1n/K2Ncx489ZPPJYWqZUSrZ+EFrgNZcmNH0k6qKBKoi G5mqLIWV6XSzjtysZgC9KGdnGkCWHbtZvbxlkqVyTZ7sdeHgUK5IOb8GzRoj7zdgginn/Jr/ gv92tsiJY904bJK96lveZ5yU8dkJHCiG1mzPsTpOQDzHQdsmekm2dpgR8/b7s8vLs3dvY5PG 7aLh2m6zSbfdztLGZk9MpsaOQ9K0zfPLX9+DSdpudxy7jzbRJhjpYDCDdV4n9OV4saMPs4sx oz5XDF324q1OFV+0VQ+0J/syU5USAU+40rlkrjLl3hfWpnyZcZtZ1HYldbY6abK4rYE5nqoT TVDy6gSqdMgYBdbVnT8iPaZX8Ow4DkbsAiu4I5uNPj7XmwTVCIygkYca8tP+P4/aYEAdHx0d /b86PVydRoEzLXhInKNK8LakImGJaTWa43qBziRz/auXZOcKHNywh+rzEozhHwJ/QNKKcTSc OzcuugO74AeJukSSyMmPIycMyY3Vh09qN4d3YeQMwHNHH8nxIngXuOiNh8QC/8gOHCtySBIo CpusFsdzAkjvUJAbWJFrW/3+Hfgu6JJgGnaG3DgB9gG8KFEmDEqBiljvy1MhrwIVXNkIMrgQ giqnEsqiWsRl0Rpqu8feVzKgwQ9FN45Y1xaGscmmFRJ/OPRD6BLzUWldvKKuBxm+9Fy7hzmh tIPO3dXvDmggJRFQ4syL+RLSar64oIOjKPEYWU2uE25PdzbEFqEzSfImG3gdNElQUpgnZSa0 xOQyFsyr1RJhsRhbUjV4zQMUCZ01kXqWzPw+cGMdexSh4EBN0K+nAQQoioZ5nYmNBsPgn9WP HCQE5b9//AH9Pz/A2RYYQsNkzMmnYAAtAX+vnC7GbWgtsf/cZL2kRk3Vstseqdg9x6auNet4 pdJsNuk7u0LEN99qwAFmA6WquguyF3fJZEHy5lsV6k7D4n+A2ZS8aljkJUs5+PABLSvqPjOv neVpxa9YZJUpWDZ4/sMUDFqKwzRTVbGpKen3NsmCn3EOWmHcp0236TRpnnpSognv+fr7moyH n//jdFp5LJ3mgyjGYQQ9BdHY0YBORpWsEdrbOfQlAixGoj42bNOyMZWUqafOh0vSDUBhv/jB 5yQAHzj/M3IDJw1kkpoV1NLBc4U64cHEEVGVjnxakwWFvQ6oAZtgIDOG0pvxCNcFpD4d4U9C vbIC1PN1wVCBG+bY4pJhYFK6tH3l+OFW/UUS6syNXP4Kdy3NSsNwLOC/hYsAhSoAu7Jp1dLc k8iQ+76RX5LILVjUs9LUX4+d9QlBZ1JIZM1nkKng4ltqE97bf4vR/27/Z3AW0qwVXNTFoUoN 85fTGWq4+vXz0fj6LFaVLc8f3UaBZTM96LoBoAKoCo2sVwLLg75UtjHk70bEtjxUDosMA/8a dIpNPDhtECu4plZZ6ESkMxoM7ggru0eAMVhfqyrN0noEy2qcrZDii0Je8ceKZ/jmgHlJKhTl PlY+0Tpq1VrtzxrWfdNGEtpsGbr2Gnr9tfbpY4W0kIB4IwTld77Dm7YFjXbqY92LWU9VXBRE XEBNMWBpQmWBpXf7Bz8dHr1ncyz+JWNgptAbB8mqN10DzC8s1mjYC/+gPPsrpDpxsVj511qL xJXTIi5UiLIMWiWbmXMyh9dYKXZqMW4npR+H37K+HH7vny9vxCrIW8XM7PI15a2yUrzl67Eh Aa8NPWcTiCYmmWnoftwsPa2QtO04tg5NgcfSZl5LEmD/3jm7ABA7OW1V+h5phMk6XbICOv4G S7C0vsceMyzj9lsSoZOSaCTjj2LeK8ZtFr34xymY+jRi4UXx2jHK/QD0wgGu2k4YQq40pDFL 6j3/C/oJwcij2jdevJAaSKKWU4P59cV68Qp9s4uRF6JSD5zIxUX+6sH79/F6v0U6YCnakY+e Vk5CHroJ799XyLffprvGWEpOX+CxFW/dkWCgSVI60FaZiZK+ekzkayZuiJKymSHuCPYT7f5t ght1jrDviZ/bQZs/8EfXvcTxHYKHHtRC3F0QOsF2XAvuN/h9FEZpbns4bNJ3NsjlDY3yYYeb yEvnNiLffXd09gN66nQJBTol5niKtswr17P7I2ifJoMXHTZ7Y+nfWSHGKJq9N5B6cedF1i05 CgI/gEesmyBuRsFdi+Iw9Ge6E292Os7Njjfq94n0Jn3rjyJcO/uTbFIApPLOixunpY/MgA/u PlbqqBjqXpw7Tq5DhZj4lXXDCYLWp2tQBNK4IbXfyNbrGsm3R/4iydvKb1k3/2T9/PqxWvk0 iXas1rzcd+ORI4PfJKlCZlSujJAVaW2ErBirKmT+yFYUFHrOPcSNbEE37cBWCg2V6p8HBw3b /opa0ADjpUN3Uln9BrCvUkqcxtqIE0NbqylONmZVFcSn6dmYfQLxqebaiE9TV1V8/NGogV8v ZZHNYuL0/L5/7YNYS0lRU9dGihh8XU0pxrvF0W7PzkE8ptR0bW2kZkirKjX+2EMXURYE/qoC NZ7vCarHazHFbH9Tm/CjsWRs5RfUBbP4NMq2eUATlAN34NWws2yCjCcfRP5awrJploXJ2EFp mmWh+NwzTTNX7rIIvo0sp5jLNDG0uk6LhS4qA9dzb9N9PRVQQlwWrd1909x53fim3R62v6l9 msegiQoK8UoSJ3g12Yui0Ra2s6xdjYlaRtSlOF7JUnm8Gif0zSPDlCyv6OQyNYewESuBkyYr Sm5T2Cpoqyz9LbRV1lddW5UVnVSntJWPtRqetNOlHNbO0sQvPQf3x5LqwQEQYTvDKCSNs/eX u2d9d+BGLaGYYupCTjHvr7OwnvrDqO3TUm3/89JWCWQd5yIjv+XzkfljiGvCH74+6ahPRi56 QWDoTFJJHDR3d+kqCoaiaIgVO56spnzpuX2H2IEfhtlhLdq8tEecWzciIhtNZfHEEAriietF ZGC53mYd+h840SjwiMDaZDUCx2digpHGKHBfDw8UMD1FhSwGHKYUxKPdwQGP7zebO8krxgEs nQLWi9yOHY64W3csap6ptYFqbeaiFKslJrNoDPlBYjLV1RUTd3Qp6B0ogpkfXclelITDJbCJ tktEVSgGTcqYt3BvlTEyFcKmpeO2IirAKUnIK/gTcko01oFTfB0TUcckeUURXBGLWoQPgQZF Ep8fGmaityKhcsvKiqK3IhUNgzxIRLK0miLijypFBJGpeTt7bAk8Pm1GN03PjeycXhyTg7Hs xRBJUScjPZyayjqFYdSxn9YhVNSiBlzmEEIv++4VcwXHUq2AOohsTKkSCEjLG/pPKyB1Kvy4 ngLSyi//3ycg/ohSEQS1NDqcFez2fSt6fM9fUVd0YZkfp1I0Ffilp5Hlp+eXZq4Jv/j6piOC 63qib+ltGlMDDoYZTAe5Bl7hBqGzC6I0b0kYBXjOo0c6vhPSeRnPP+JFHwNnsLWNvYiSA0CI AM3CkXhFL79+mPQmkT3TFNytpxhTW/NWh1KjfAx7klK+jA0TKDfVhWR8fHFA8HCpRBI8m6a8 GzjOgyg35QehaypjcDu24X/aQjJ+CkpVQXkwpVwZqyJSLuYiVLvlZzlVLN87O7obOvEkF5+G Pr44Ofvl6HzTrpPNmlUj37UIfkdLFD7gqfZHrR4LTAL4UaVcxGaRbkvlIWLhbvO5n5ARc5+6 GZtCnSF+EbsfaHhGuz9lOhOKDEipZvePLECNrK0CNXxZqTJQp6XRJnq3ysTaFnaw1wkWWNRK ShYxjlWVt8edtrsWy1iqVn67ZEzhY1tlqraie2D5VqyqgdWvGmlc7xl1UjPWWyf18qbEU+mk vi6eFR838YCnJqiPipvsmASbkENyeHxeTGnNGUo7XV1ZLcZjDl70TMqsCQvYxXfhDto24WTg IdVydsUgXo2rZSc7V0iammD+PaW5gHV9vzS5Y1UTdJRuutoBvCJbQPwQ6BTwiNhe2bi0JqZL B/HxCx6Axa9SEJsHMpTJVGrzRIQh6PTkMNNc0QDapHSZYAm0SdLz08aXI1rimmxkJ2Uvv/jJ /T8hnuH08X4hNyBORKx+k16t6nqk0cc0vAGk0b8lvkcuDs7IB8dzb/OntagO5XsGHGRfmr2U upljPGk5aa7Y2JYn48FT1cRjmroIV+0bK4jhCN7V2rUk+yxIuh8KsNZqVvuDMIApJB651fJH btddSFNnb9daSPyRpQgotFy8hA7KGwcvrsMrLfEDByd7ZLIiaWpBxFeKIv7OFjkDjQlceGV5 d+TatiVcR3QCD39cIvAjH6cBDDhZN77bgUxsITS5eg8q+MWhVzXbPSsgV45t4QNdinSve7gg Gdns+FyMjrQ+UE6LNharsioCV9RcOOYxuKIWDdc8P1f4upNwKdadWN036wtNPupyAz9lpqWJ UcaZazWcf7Q0EvQwSrXlBoWWRSlfxjqCevZLLZm5Vwxrb4shrT4XaW9n4uztyqEs0xcDfURT yC03PwbXjEl3b225xtc9A/HF0AvPTbflMdhYHwxmmoWnprTsYo3H4IlZdP3t+XnC15uER0uZ l8zVRGt2/zXuGNUFcynzki7oK0kpV8Y6er+6lF29m9/Ng0qCWgrpX6yw7Ubt+BbLlufPw2C7 79uf2xHCJ970UfAwji5NHsaZrqfUoTtdKh8gYe2MLQLrkok/n6Fn/tjzsUiWl8wiufxS5ziL +FqloFap5tg+vkuEHOvGcvvWldt3o7uYj/PYNPA7Dp7pLMIbdeosFytcOKiHsmyzQk8bydPV 8ue3piJ5XXJxeXjQ/ulo//Do/CJWXRVVVxfGtus9thy0SR1dHzlo5S/4uE8O/PGBFpluSmM3 Zs21arvdouw3JrewsrLluE/LPDHzzQX2rBYaBGjGGII8drPWkpg9dRp+TZhtCAvsP11E0w08 YWJIamFNH7qdgsw3xEm3jZUtx3xa5omZLy1hGY6n6cBnYLasFdb0EsyWJhfR1oXZ8hJWyQpp uqID81WjkKZPeGGhe42eXs/C+6ODYlvhjbEb+e+psJyYWOknlpO6wG7VWauZjID01AJIBUSj mYXGxTJEo0l/K9FoSzBPp0XDH0Ua/jaVnu0t9sC3WWgV1tDlR1iFnRJFCwMyY8EEwxCABCPb NLw4CdkJ6ScjgS8VvJreMM0C9x/QH6tx/yjqLRjmpNcWFy47LP54cm/BMB/JawNGb4umKBS4 TaEkt01h0jdbG26bwhP5ZibuvTbl4r7ZCI0aDMDkmismDWnSVeNWVU42o6c3sUz5wZ5bGmwz cYeKqRR31hbn/tTWkTXlvvJgV25mHM9UwaY1NXksjncBo59uQ8Grpv0RPRU98D38nWvXpmbO zFASAgeWhCmxmIy0vI2bL11YLFjI77ahzNJuTTA1mA1NXRmLqj0lV3RptbjC1x08SWnq4ore kGBq5W+DDaOO67Mhw87jx/qAt/mYhrSiFw2YhW/zmUcpX8YJ5amMsZ94tAceCpm40Llnv58g GwytT8jSpDB04NP4wMf7gMzsh3IXINd8/hszipDLlzb90XShyC1oCSj1fVDhApiGvwrKwTRa vCyoYaFlYT30SweaxSI3m5WnWeTNbs9KM0/uwAMFeSCsJpJD9xbwDLhIDkSqQKkkriaSQ/eW MWfxZZxQviiSY+dWBdpwNMyHciAVsUyWFoZyKLwyM9d8evnyllHeilgCy+nOo61iyCabHGSL KyiLbVisPVweoisoeVUqgehlKFd589izU87XAUVGHTBXFdeVBeJrM3BdxRlME1YV19VlzGB8 GSeUL47r2QU+z41zbDzch+waIpsuPgDZtZWZye6jmC9zHWVuCCWwHbeNFsM33eDgGy1eFt2w 0PJQ3UCpm2IJVC9Os8GbzZ6VZr7cDQnlbqwqni90HxEfz02cuUxzVfF8kZWhgnieUL44npvL 3Z78AHTD0XAPmovoe4qisDiai8LKzF/z6eXKWxRlpL/IymsCTGHPDwoFkqFenQNsrHxZZKOl lgbnooRil4ssgS5AtsSbw56ZbL70JRHYIOkriujiAhdlzUB0UZZQ4MaKIrooL2Pu4ss4oXxh RBef9Xas6eFwH6Sj25n7SekFCFZWZgq7h+D/a+/L29s2kj7/lj8FwjirI6SEq3HEq3lHlhRb G0XyI8o5drPDUCQkcUyRXAK0okzmu29VN240yAYIkqDnnWciWSDQRFX96uquruZLnKDEo0pB AeNGm4+KGbdEh9zk80WNG32qOptuoNyjKrxqyTZ4rmzDZPOlb8jIhpqe/QFvVqqjJNemm+i9 zJoenwFvVoX34ss4oLy8TTc3f+pGXB0W2XRMPRXLWsKmW7VxYgsI5kvcRonbZgGb3h/P7oaO mHWzCce6+QMUNW/sscrMuiqD6CG5L2DWC1Cuyjx3tnHKczBgIydITS27Wqb7G9+yQ1INlEbd 3upGaZnOaGKWPaS8tGWHl6uLoWP6sMC0q5iDqvGWyoUp3mgv4kIU82Wuocw1o0i8Phm7YjXZ MLDOi1zZAIVDV/pYdbZdR9nrZpGQvQDlOs+rbZzyHAxYyAm9rrZdL946Oc+26+jFCKmrbSdV eDG+jAPKy9t2otXF0jF9WGTbMRdVDWMJ227UxpstopgvcxM5YInYdtwigJU27Ic7m0xEJ5xV M27i+eP49u4RWxDhB6yohzYREVQMU3TR6VXySDH4M3qdP95If4Dp3Auv7JfqgQosXcXWNcoJ xgpGDjDhN9ZjOzh14f3JT+edy+urd/SHpPhAt9CR2SKObAkxZ1ovrELMlmityFrEHB0OumEx 87Xb1psQvYWVEExk+Eog0ddJIYRBQNApNXsDPeNFmt8lNV7GK14KrNq8JalojDL1wNUWQmsy AVYqYYFFbVmpybxqjZqwkotSDWdQNLmudRuaXFndhoar2ZpS17oNTfjU1MKxZUh56dhSU2qz 6BU5rvnhpYar+Jq2RPGGptameEOAaL7ksdJaI0qB/cQjb+JNO16h4EPT0g1asuPEg4/w0yLB hyacZmaDj+h1guAjvFIy+NB0e4PBx8eLq9sPtzed2yDG1LCwXDPUAluXSwk6UWG+KkELZ9lr EbQh10TQfA0nNgqezIkyQw7khUaxG4qERtFjQtBJtObLjlE0NAqfrC7KxHRcM405UWZNWGny Zm1rwko+Sg0TWVvTE+vhzUqdiMyNMk0LKLVqevA7vFkVc7V8GQeUl48yrc2fF59WiUVRpoXm 1yZLRJl2baZtBYjmSl6XlSb8MBOdOt4/TR4PpZPTzun789MfOu2L/w2sAC+Nx9COdrHVCacf yOEiQyncHhPeh7fAU7BFps+YyppkUszoCqTcumIlWnhsnF0Kr9Zhw+zKQZuN7KtrpYOuLLVG lNMnhwFHhQBFV+ta+aCXaHm+mHI+BrAuQFeXqHHT61MXQNVlgZ/RsVBb15aocdPrU6i9gGC+ xLFwW9dF9qI8PzrwvVM8scIZde8A68Pu9MGBnBj+WSTb1RNnhwkNG5nKuXPPra70G9y2w9LK JGMaUuvBk1KfsIdzHosN34IX4g7qW18GJtyXqxsiG1yq4yWxvjRe8nFKLOStnoiFBNy6f7DB Qo+O94m6dIPXqssfoKhPZ49VFwMZ6MRNkoiBNsQmkzcxsXE28dFlGMg2ta6xj7lUt6/sMR8M K6YJRFtaXcMea6nJgyzRfMljdq0vk13r9cmumZYsCnkwtdaXSa31+qTWiyjmypzg2ixRrIQv AXrRD0oT73HqdLFpKH6jf5K0xCxn58Pt+5vzk7PObZ6dpE30gxGEzCSR0y1Lo+fjU/7h1SJT /kQu3lzK/yKmRallgIg5/jLAwV546aDkQgBRjBUsBKR49sI6dYZKQHDplqh2wk9uDAJK+oTH KiGgFvcda4eAaq4VAnyrgAvbRAvrilLxcUwkqRUIwRArYuphJmDJhEkFAcTd/J4BUYF4K3y2 ssiU4JI50cNao21iL7fzWW3Yy0czTmwQra71R2S5vfc5xooBDWc0iF7XeiSyXAe0HMr5GNDR opFEj89YrCcY7RG9NuU6kTGfH+ISgrbGSLT8LEE4qU3LMAHC+QjALbwk6h7luN3enFkpDD1a reeB99gawRu37kERnOfx9JOYmbTSkSx/rMz8E97UwZs60U0RK3auP9weN17DT6l1Pxq3WA/2 hi9pbJ1EoqZRqyXQTsdpKyWQL1Hcj2rI4mev+a/Yfxn2hYg0MseJxEcQIk1qjYNP6EMxUlMP so+pJA3chGko4uecFSZMSW/YWDlhXAkaKkDW0Ehyxv1rqX0tDVx6nDN8qTNyB+MRa2HUnTp9 aTi4m3anAwiMft9jDgCpwLv7Y++rffQvQI80c2fd4fBFOnTHTfgxlGCQ9x9aH3/J42T7Wox5 iaPi4KEUv1p/AuVwOcaRXtd16LDui4v/ec4TRGv4yePk4K/3Hw72wcq1r4/hLd+gVd452N8J rozZFV+bAQoMIhr4MyO9c3HVnIO/+kP65+nLw/Mgt+ZIlJO6vFpOfivtnP767ueLq/AyvP5i DvOxqqG10UOsfi3ttdNcxVOKHwf42/W6o54jwecB75/G/dkQ7vHG0p0jDcfdPlyEhHJMx/rw 4j2OR02p60rjyWTswmd442wwpCJiH0sDz3WG93hTNynSl8P9PFlcnrXfn9ycnwlKJG7xwkd5 cgk/nC+do+DPqTN0uvTQdh/BRAF+ktix018iPwlZAz/5eLUs4K/t18NRlpsy+BVTDv3Kzs79 gGG/fXrdaf8EWhK8xXGj15Na76TWDx8uTuHnQMcD3+6QW62fh83WW+cPuoDGHv9xPPKcqfPC G6D/IrXe9l9G3acBXPCfk1qXRzN3egTcPhp0DX1o6I2UvkYDPeBITDyNUHmjj4fB1UUKbBOk XokU+PSUjUFhhVbwVDq4H3Yf3AMwgQwxPYg1Pchx7/7p9DwKtocxRVmIGDqSjxppj6FyH60o Qy7gbwSmdOQ4iE90tV3p3nmWmDRzz8wJXk0MZXbcI4WP8lAWflhSa00ZUGUqeqS1XwoTTUVd AxO5yDQVcC2mGnMtlxdXP3x/fZPiLGWrNOm6Pl/x2uu909N9zMqfuiO4+AgpEWZiLh0Gb5gw UweJV2/m0XXwZdmaeDkx3qoJt5J4nmsLE3eUhSpO+5hRPcuXx9XECW+r5yofu8QALhtqYgGJ vpTLtggHznxe/tIfjifOCN19a9gfihFvpLeJpAbxOUBnJu46n7EzLR2kP9zt7Pr3/iWhzHdf vjk8+rb1Tacz6Xyz+/srkclLHPN1NPZSc5cMrVitYKaqFdbBRzOd424tH/n4NHTka2ziD4GN 0+yXF2/bx6gVb9uoDOxPJFmSwoti85imIbpn/ehAuv7sTKcD+Kg7epEgtFHREzpTPDN5Mh17 Y3qOMrpGeqhGd8RmZw8l6eCIDfCzg46V9meHyLfXnVHt9KSnwcMjLk95vUdqolLnMnfpl/lg w3IHM17usAKmCNcsbJ4pfOSYGC9aYbzIsL6HiUHhVT3TrHb+dNF6H9M6rorh4l8jMUVsYqZg 2mFMtxShdrUVIFURypWwJWtN+GEnJhB3vpbO/GwF3zSwiu3Z6Lp91B4PwQhDughRQfvX9k/z jLH7OOxgWhpYUrGpOUtOT6xmx8k3yX2wyeH99bDKFGKWAlGCpSb3jm6a02o6gthyTvMxrijA ecUs4P/6hW29pYi2mt28rWd4xAIHK75zfxVcUbcnLOBjR1WblAofOwHey7kGS612d0ClPtDC kgwrKslYklStnu6eL2Vs126RZAngKdrF+MrQ5KXv3M0e5pnh5J1iNpjkrJMGg/gGOHihoKg/ eZcUPjeeeeHF564rPQw+O6PDV/HFrH/RRSn/JmpufVsbYzLeAiw99lewgpfxoYIHcFmmksjU 1sUvI90Fo9b84uPNRLxZZjTbFUtz/SWdvgMRaN8B83X67bfRUpYbbNygNtj1905EsxYNfy3o 5OKXg/2dXMY/OKMZWmi4LWd8MWGYafAKDOwLaGdH0IeYhY/Oa7CZ9cnk6I/h6ZF/9QiNGbsx 0zSt2z8Z9S9GA2+v0WhKclNqNMpZPava/W4VNLgAQXTenV99vLg675x+uPzYxv+ChiYWnqlm y3I0QbitQLTSVmEFQLQLb0HYHBDtasu0VghEroW0sRedrYQzDxc3CCOJrnId5C5Moty9TjR3 N3LFZgBtOY2e9Ch5WRB8BlmQf3c9ciCq2LZiAf/UcEJjxfxT1S+Hf3w84g4BO97cbUG2BIQV zpZs4eZ0m8+WGMrwiG07fsT2KriiiW5Z2DxX+NjBTNuOthIwtJdLq+yKu+VVmkHamgmE6uGc +lKE6kotCeVLWEdvlWoAiKVoP93oc2ftxr1PjsesJPu3mLnV0+6KM1CexWUf49Qde6YeRpfh B3d124aemCJdIRuNtNfaejby0UnQdxFx3+WTRK8XttZk23wYbva2TXEfthR3hLdub547fCzh WrIdrSUzZpQ08UadfRmuD9vR+vBShFrb5MtwQ7hth5VYc3L7t851e34yETeoI1GzbKfLMdKj 5CYT9TPIiCVNltUm/AjLsNbNUvju9DTdFrOUj1rbRBZr4vlZSRMOX7I9RR0MfYoMrImf5LYy 1ggfyrZ51vBQhDrapFQs791gmHqWgTBMqAoQGp34thShFfd4W6V302QNTbFWYgskfIUrZmy1 nAU9OsL81Sm8Jbk0Ra/MXZfCO8QWpegL+ACAjFWTSXTWxwr4kMlS68UHPj50G/kSRj8f2+cd v8XHj9dnHy/PjxsNMT71nV6L7dMVZBfJ22kZG8jnWj7jYjcn+Rf/YC4b4caOfyOHmww8BiqR EcYza2SSkaNbtWISH1mQZ2qyqSY3ei5iUCHmmOlqrtQg83WOyxEhbuRzgqN8wcv4UDJR36x4 zXfVXLFy9KqeXOFiR5H1pqaocgw7YRx37/iheuMJguWjnj8SxFm58Xoue9MjiPBXka0UfzPv Idrd7xEecKbUoSNdVXRDCdcmFwavSomOwilK/+aHS1Qy3vTlmPUwmkyyXx51eYCwKPwUsNWA N8qLtBQlnDCB0XmBFlwO4yz2GhA1H//+MHUmUuuztPsP6eDbXSn+fQCS4NPGP6LXZPGY9+/f Xjd+f5XaRMNGbcyL06huKwrkZIqmxXS7PqhVlS8DtWrxzjnrRq2mbAlq+bZX1wDFevxYLwom +uKNxmgcis7H98JiN08QonpOfxEcIGwylV/o5j2mitzgwvwCN+9RsLgNXsBXcQJBjWLEJs/X xZzM3rdaMYePJAORZMSQFGcKh2dzGRY0AfJ3FtOZPP+aIAfz2gzyRsybH/Q/3+3spp6ux1wh A6mJILViIN0o3600cr9AvvPxbyogB1N8H4ZPWtGKEfiO7dqLAZjA+N4W34tRmjPCRwtvnjN8 DFlqk1LhYyiJ/nITmIpV310ZgArS1FQ5nKirhGB7e/ZmaKoCVkNV1eXjr4B1fccDkyVkrFUl fd53ahDhLOF+Nup1kg+vN1NQhTv/gua2Wek3S21Qx/0a3k7H9WZ3mCtNx2xj4uN44tzPsFUW NngI7YLb9KXx/DgALce+mvglw0HPowETMwpJfuztvwEzMRw/MxNC4a+qYBlVjSwfYJaRvpqe 2the6Wuisxs1kT7fFmg2oEGPN8srbPxUvdp29UWMHwcGWYuvEnBxKokfXFacSLI5l7aISL5k TRmItoz5M5yfIPpwhkfX7VLzRPGnhdTfTLeITHz/VswPqWbxlv8xKlc9N6Ra+pbMDTHVtCCD V217/ozmmlFqpfP4LUSpXfy81HWi1Da3BKVc26rJ4DW1+FGOy8ZQnJkKscU4TUkvxs0dcsHs h1vX6Q9qLCB8BLarVnWha3m2q3mnynxRbOejH1ehIHIsOuvkFp5cgWxxayZXGEI1CLo0Tbwy sDxrtC2vDAQ9blIqKpx3gkFrOQ3DsKErQHDUXbsSgvUtqhTUCNoNQ1uN1+x1pmKW20ivU+eN lme04bO62msGNMz8NNNYjZsU5nMm1/uC+MzHt0GQ74qwXwQCi9t9QzT93Lzd99GIdt7ShV1i Ka5YounO5rnCxw6uqCIVVXpDXBetoXNgsLAwhYpOyayE4IrPzVypN9RlsBa6oizvDTudvtHh GdcCa+h6pl/HolHzrHa4jM4boB7WmwJQV8Au6aq+vJeshP+Zfh9fMP/5+qBoqA/ie6pLLtjr W9YSBKABrkEv0BKkLGO2vCsIKnOTUuEjiKMA5fyKXuMWIUAwZFV61CKkOqq3qF8I5MFoPUgF NaXcLOWpK2bFiUgFII6Wm/M8deua8zC04Z4b3aygPHUpPmf25XxBfObj21CA74Z4pR8QWNwD GFtW5aebaPEt8Sq/UlwR7pa5ea7wsWOqTUpFhbmlbta4wk+3MLWyK63w060tqvAjuFBGVCu5 M3KuOZ65jFhmOp8mPSFDTDLLYNlx8kwwfAYmOLy/HsaX4gePUtdiR6mvjn1aOuvecvbx0YiL YngguajvAtIKW2myRethDGS4CypxjPoquCJ8GPrmucLHDi6aIRU+dgK8lzPipKbLZQwQBIIZ YoTBzJKkknrmrHwpGxaQbuqJbo+LTC449bKzbcTMdNflD7Zwki32XD0sMIOShVpjhUvNK+en lS7q/2L4yccrrtYQS131XCWxtmdKzgeeDYyxyarnKoldoPi+ln7NMpuUCh9BEe5Lmnu7npN1 FBWGDAGgER0RvSyxhqzXkliupA2sczKiOqdXrLvPu9NEZ59Fu7h7L72h03oQSysMLe3e0qPM 79AS3Jbc0B1enburm97VeeiJbe0O7vY3vxsY7RlRidQ6eKWnXVf9ecXHGYGk1TCUFM7ets/O 3hZiHyC7fyfGO5LfjwyGWNiQrH+X6UgGlxa1JOvfCfckg5fwgYUBpmHqKWCtlDmZGLOGzOEj yQZmmXJsLQXf82LkeuCqm9KzI/1zBt/qTfHnwMPDqSHGoyO+CQ9dfB4Mh9J9dzDEtxx44TBw 82jsHS4KRvt32OheiNGmnGa0/3CxvYTsofXu0jDlAun5mvYQMj7wdo6auG/YVGNrP/XGRWan 8fbgooY7i7m44NoPEwsWTE1dZk+pqW2udi0m9mwsa+KGWVOPt9crTtymN8xyiONLkkDgbpL4 HlLOqYTPPURRC0f28DQwATeafkRMoUm6ojhvtPnONX170s9mPp3rctndnfBuMe+bfsqPUkxs Z2Qa8c2Qm2R3pp3Rl8NuPtpxndSM1knPLi+uTi/PLm6Oj14JNdF0HwatvtD5XvA1OW1X/THm s5TdlGSkf20u++CeTn8oxjR2b4BMXFE1oxXVlbImc/BgXVnDR5EN3s+SC3al7Q9bgkeMw9g5 jdr8Mebzh92UatLLrs3vzzuE//fF+MPu9aFj4V5ZPMu7UD/aIvzI7ICtKz+4eLFUUC0rWh1F AoBgNFYYPveH6Krhen88j22v/UfEOKamNSx8vFhsHDy23ujYKrLUu6boOOAEL2+yNMinrWil dx0S1tM58XZJuMiy9WYlzNdprEa1omrUMkmCRczNJgkBwdkcyMIiUCsqAi1FnrnhBI9LHl+a 2CHPijrkfU1PFUbFGt9LT+P+bOi4h3Pc2tmvV5fXJ2ffX1yeiymvFY8N409Huhv1sIh//koK uLBDT0TCL4oORDoK/pw6Q6dL17B8eWJHPDvqiLdyAm17bQRyJWqroJ92tCaDc1ajHi46z0bd Jwc8/8CbDPpS58HxJt5LtbbZVtN51VbZZjycdktsMwW3rYGxsqM1pfXKWk/H6tsla71AQXgN /bBNFJA9MZfxwzbZXM3YAj+MR0dqeHTkEn54k0dGFvTDNlY12baakylhFF29Amcqm7ZLge36 LSTMNda23tRlmeSkSqsRsZ3uSbpNItbxiMYtETFPq+H9bRC5skwHUnh8wwsquTZal1UVyFOX 6T0Kj2+496iwjdZlTQFytdDjhmDO2yaYq8O+rrPy0Zk3EJo8hq9O2+vsOHlFqPjhbmc3eKAe 9acMRDqaRRI6+rVzVU+byC3nag520RLpRLiqF0krWroKX7A9pasMfAQtGIl1XVwJW4josUub ZwsfPURuUip89PiAL1XhCuPUs8KVAcLQgNJomXo5So3NTXMWreXV8WxFXbblnAwE/vxUdXiq Z09b3K7wtMj5KJvPQEC6YO0UWcvJQFYjYjtdDLBVIlaKnN9ewwxEkU0QuaItk4Eoyub2XyzI QBQVHBOearhEBqKom/NHBTMQRQUbrWhk+QzE1/WCsbKipe11dpwFsXLwQD1iZQYiHc2ibi2f gZTkqp42kVvOVT52NbREunhn7VKhtqJvV1dtXcHQWiHiXbXLsYVsTwcBPnp0q0mpiKLTT6Xj coXUt5W2rhgKUGqYsSBtCUqNejYF4MsYMxAlPwNxHeeTobPfY/jldb3P964EXz8c4nX8PZb8 y9VGscp2JyqFDnKsQaKiYKKi5icqm0TCducz6pbnMyrmM+py+Yxa33xGxXxGXS6fUbcnn1E1 AuTqufXBs4kqPThe77kPyjyFP/EXjTakJ+fpafzZqVa51UzPqu1Sbn2riofhfSGoU0lu8fDa xU+2ubIYXn+rK4t1FefeVWOZymJ4vK6VxbpqGkCetUxlMTy+LZXFuooxnCZrObYdKxIfppOK FXi7gzNte4IzimhNBvetKUaO/V6JiLXMYQ7bJWJla1w0V6s1DFA11VjGRmu1DFAZojVwQZpm L2OjNa2OLogvTawK0UhYdfq1DzA65T1liqy8Co5LFYW4cBFIdDzrbDRwvT47m5XOFHYHo719 6V/wp29F9uT9N6WkQUKP2Rs/TQZDhycQ/6NQJot4TjnBWMHIASb8xrgU8PDd+e2HdzcfOu9P fjrvnNy8A0YyiGHJiWaEZaDV8Fy4wmQtPDe02vCcj3sDHZeZl3e6K3FcxnY7LnNrHBdTMxNy S83Kyy1XI2Jrq/NHzdru/FGz0XnbS+WPml1H500RrcuQP+rKUvmjrmxN/giUArkqqTQ20ZVK /aQb+MlmSU+pqxvylO2c6AQYDlzXrEqjE8jL68V1zagN1/nY18B56bqdP3fiDZ6c8X2/W3G1 nr7VvRXg9bfGgzFtIwrI2VDzJ1BWJWeyzVv/gGVbs/WPr98GunJzmS6Cul7LJhMM1ljIoVvL 9BGEx+u47Y0vTQt9pm1VG6lYxX2m++IeocHIy+lDY7K353rTGcAXrwDhB/tyM37pz/HIgWsl vau9pHf9Lm4Q0qaL9ld1+qidD9PuEzay+o7ZLAY9GzwnUZRK4xcii7aFqJssiGxvRBZcPSEY 0RNVS3TcpE7IpS6IEQ0D57Z9DPqbMcZSmx3xGRj8It2NwR7fYbkhlYNQlzV4sfiyUYkvEfaZ zAl1cKz1ekyiii4tpSCM/o9hmI9tqnUEswY8BSve3LMWkk10g/syJSvcMa6gZPk6rBoo6TBy CQzVk3TgTcqZKG0VE/QZoaAbTwQpBNc+SNTsuAJK9FUk83Mp4ctIN4EyEsYjwQlJcxUvIp+1 No8pxjjQGDGVIwpH5YSGF1Y2NlrHe1qzqpVYZclVtaQBNWQQmRmGLWsWmaF/sSIzSobR80TG 1zoqQsPgW0bJm7T+5j11XKdXzrYY+spsSyiaY0Zg0kyaGiLT5pvJpckyzbWTxZeepQCZsf5L 8xSQHgL31MHInCpGwBIxZcueJ8cbqrhi0UHWrF3CLZgEtOt1ip7ANGLbJCPWNml1ksk0S9pe yRjCnZNKSYavQ0xSctYCek9A7NOhz4lylsK2Vm8p6OtlIkUD9xwYipY1gRXQZUSbEdZIF1d+ hoLyU+PdqpKpP1fb/sROk0L6ZSgZ/WIPC2vU5y6EwPSZNWuTWlybosmfrwf3I7jDpxanpL8H 2tvvLmIrAYaKGNPirbSq5b2mbCvvteJBtzDv+XqAu+yNaJd91xsP9g7YCOWm4QxtvZPZaYll TRpueTeiLe8VkKivt4/bPBL5UsW6O8OUY9ZtbhTBMh3vEUDK5pBdqTv00JCKKRxJl6LPG7HM NFPHf3jN6mgUn0jMnQf3MeYTUg53xuriAg6zs5qEpYSGpcUM90phlaki/EJgJVxeuCZYWasL yxbAim+9LANgZsdP2n3uup2B12Ey7x+PcqsDwgkdiO9dZ+j0vApn2A1b5s0dFf0qH6mCYLFF 1+Py8xumvDZ4ejyoMlLeenDVlLW1c9WURRui53OVj13G5TCeKqWQlCMbqdn6td1pn1+en952 fr64fd/Bv28vfjwPKuZMXNU0lTCUKkedsqmKtHzquLI0FXB3pho7LyS2zOe/35QWxHR7njMd uN6g587xiQG0aQnNwJVmI3fwMBLVEoW3upcZStgLwg94thM8WJUHjI7Xend6imOBsY8N9bUE l6XJ1Am8t/cIb+++PN2Nh9KYzrt7zpOL9E0dPHu2O5kMB+zUEkHNVsVTKPxD6nRO35/cdD5e tS/eXZ2fdTr0RdFHMcirFoBAj52pskkQJA6E/28Q5IJAE18JWQACvmXAPs4mkaP+XhKYu0zJ CN2+/x0tohuNPWk6GzG+hDUkjwAeCUvyXB9KIFbKTvWN5PwBlCvMphYMME29QAucz+Nh18P3 AIF8dkaey9pg3U/HT9J4Ah538CeCDXtY0ZfvPoP3RSlNutOeG3TCAj5KX/mBxF6n0749O+10 9qW//pKCP6SvjkM3Qkxgn6FFfcDqxT7htG/t7OOjkSAajRgaw5eipqEHGqgSwniy15P+p8Qq rMS8Nan2XBH8fO/wKPiIvRQ+fdR3Ph+NZsPhKykyFVwzlclLTQPxZMbwVCUDzGo76FTMAD4i cEOYadnCK3zP4yn9N7yV64m5osz+r+QYRXwQPrDeFNwU3v6VzrgZ4GylqePZsKLrdCX4a6eX TreJv5Ysulia5i8Xz5YGeYelWcvUkFsr2QiT4HHGMFk6ZBAWUZYpDrf0Jctai703n/9EAzpM TdieDEaIAyGg0/MxeQ8XQDh7oiqIJ0dl0yL+bpVPz7g+zj4A18z+Ac45+OcbtnFFWE0M0ZnA 7MTfv+nrwwvdj8f+peLYMlc38xfyj73mG+lu6nQ/JdUDt4ZYliFsRovAykyf2PcfBCuzrHer CFbW6gq45sOKb71ssMK2El8NQ1/qzpnwjPvbIJYUg52dXrPIDFNootIWbpOUFWUYBOP1P95I fwB+5VJTdra8ioUnJoS0z4TvAmmp8UWmlUnLVvKC2JLSEu54tFJpqauw6hlpcXUNvhukpxkl dY3lNzRrExOgmhclx0cqJkO1vPGMfalUrkjU1lZhOnM0TdNBVrpdUtMKy0pLl0QtLyu9bJpR iaz0VRT0CuoZ7nuwjfiu2kdspB9t5F0gxehGMeGRdE1VbIBiMiOi9WUoMIxCqEEEoaXkw18I xweUkjsIbWND/bNoj4QPN9e317e/fjhvB/OkNpbZ22Z8b/FqhZzYG7GUkA3RVZj1C9nc0OJq Vsh8zTbRg5p2QQ/6uTsddO8gfBg6owfvMSY5tnru9bvTB8E9MgC5FA5ERy8GkiJpSmwR3v8y v67BttCL2WpBL1Ypv6y0Z1sNv4R3IOTwi483G42MHUZsCRVrSo1GU9IOFb2kstmrCGdEla19 e3Zy8y5rWIksa034EUY+VdIM464iLFiGZp7c4TUN4IGqBHKPFm1TPia9gHvX7Yt7ILhZcv5w egcFfRGRlfT8DXeoIgoEYxbvbTCnNxMNHQ8OvDf4Vp+dvcbfG02v6ZVEjbKZ7gVMHxQbsKDp gT7UDQtq+kSaCrCgilaAbQALmlqbThb4MoANPd7JAqUOUnjuTucVDQZywqNpBj3Jf0BM4Fq6 oJwzUDSR62OVVgJ0YpUA6cKTOlUZAEsLzOz527BcIACB131Df92h1H0N1glIicS7UqxeSnp6 rvMLlJLwYXILpMTXLYJxCAlj/X+zcRYbCFJt585iNQmhdWHIMzCOMMP4W5iGint6laSBLxcT bZ4VXzH43IXXcb3OwO10p9Pui0C1tP8IluYBbOlTYnpl8lr08EYr5vFM0aqwV2FdHD+k9AVv ocmx4xP162SSxauHXZ5JdgGrPJ9JfGRZJmOaj6zghfGH0qS/wGDRv8Awsj9LhRD2kmsAy4ST iiw34UfojFZFpCIvmV1WGScpmFMqip7o+OUOHh6BC9gE7XHsencvuH2vQ6t1u9KT44LfA9eE Xg0DbUlrSgQbjhgA3YfZEy0n/K61N893p0YW0h1FTpdcpEcp1hgz9fRaS42A5aJJ3fr6Y6YY wmmHCq8NblNRzUQbsZrCRU2n4tsMF+G8ry5w4VsbTQH4aOYSFXHw+OYOzOUBIdNclSi6DlQS eYn6ORij2gLmSqnky5agbI1wZo7N8mX0IdTItLWgwKI2QWx6RUk0SJ43mq/nknR9edY5/f7y 5F37+DX7TS/7lxr+Nen1j792Tj98iP64fX9zfnKWvMbubRTRYSK6vYNaVUkKZ3BGjte/C5YO gMcILzOc9lo5ow1ryxhtFtl8ymU0H+GYXymmFe1YKKXZ5ioqen2DnTvfzpCDuY9iK9GOg1IE WKso7V1EAF8iNkhEleWERKKoGN/DazRG49DtFlMSUkBJEucazhstVBJhONtFMmA6cI7lUGWQ v6poCflvhF1q4ozAStmlKkVy4Rx2cdEGIyP7zPj+uTIKpCpkdQq0yAaoKngPVZPju9hKEaGu orhyMRF8yWBcqWp2xg7Mh3YRcGsFwK0tjEy0DLiF4a0VKT/wh86zBxioqkTN2IPNsE1fGGcs wTZSpAohl2189OkWslGP24WSSkWWXEKbr1QLbYOBamSYcdtQkhBjpSausH2wEOg2iSSUPccl QturKg9yge9Ol9mEj2/BQS7ANdHCx40f5MIwbJtNoslWhOH1iVqT0+WmWyVqTRYtf9y4qLla rimQDWjKMvst4fH1NskTP7OHaCpE75q2zLZMGMOuIXl8aRIZyI3mk6hfvhyMZn8A0f9vNpgG LThYS5Pp1AHg3B9ODiXA27TrDcaj3LMs8JFO534yw52k3nQ8FFNvki40To5RTMcTz65Z0YVn otan6Al28Ay7ZmiAh2jaqwZ4MNILUtuKB+EJs3rggW8vTIjCNUtfyvpb6mbNY4JqjguwIUDX bHMpF2BveP0kn0a+XG2jSXQ53DOUWvnOpqhiGo6hYGs4cByhPZfwAunVxLzRfK2nbLzD9rfH TOHxw93ObvKxv0C5+9LuyzeHR9+2vul0Jp1vdn8Xshk4+OvoS5YyGBRbumwDn5Vw286G+Kyk i2a/ID5z8a3LOvI9NocNT7hYwHx58RYXS/AXqgj7k1EvSeFlMROvywWaa11/dqbTAXzUHb2w xlCDkedMR8Co0Iqj5e9+Hg/6WLJE6xyDrlAwwM+ONHP9NkZ3Tq+Lf9DS48HDIxYge71H2lvK N110vPG91KVf5sNRgTxOV2Nz1Sthi/Cha5tnCx89CmlSKnz0pNxmGQehK5vLEVLalvWAugpe Xo9q/qugV9uc059HL1/eONeok2S91inaS2osWy2MoFr3Ewh+h/NsdOJGMctM0l0HkmP49jh4 m6C2MXGTFD41nnnBteeuKz0MPjujw1fxiut/4W0ddg81ur7FjbEX7wBmgjGI3dvwgYJzmbqR rFRaD6OM9D7EujKKjzAT/VFURXywjyb2x+PW8An55HZ7AuwCPD8dt29vLq7eifHMTE+Scgaa zzi8M8k2emUu0/AOMZbhnQGysBhWjyqI18MgOz21WEsG8RFlg48icuij/Ga0KSp6x8CGV/M7 KcXvLsS89JYPzkALmdfLMK+3kHk9Yeb1fHQRGQw8UUIHt3ZmkUx3mVoyi4s0gjsCiRbartTU /+PLZOxVO+VPMpv8tmrKn6gF0oIarO4Q3NYHEVvYe231As5s6tsuAQvv19u4gPkarYOzBSEs M6tHz7ut3aIHw7MhA3lGfANkcfKig0drRB5fmiZK0+KcLx8U6I8n3jzVfXBGM0Qku1NMga10 5JQapPA2AHioCiVmALARADbnXPYVcsROr2PVhCN8zGDRKrGVxPxY8rv9DXsFLaNV4txhrz8Y s530MKIzHdHpG2yYPuo38bcznTZ9LoJ1C0QMEZ0hhxFdVQQYcvG+EEUJ4EsESyzw+FJfIju0 Qbl4c3J4dvPNyePcT7WYI4YCSmkooVIWJ1Cp1iRXSCBXogbOIhqqwrHLQWj/1B0Oxz1ggu+e XOnq4+UlRvmjca6BesYjzzJPChkpI3VyDHcgYUPFHu386UzHlZluA6ciDU3nmO6NMS110kqt mMZHnqoh8ux47WSNGikYwm01uTY2tdX68uKtDx3NAKr1WOFtvagWblApSjVf9rqKXLDK+5GK TzQtY2ZjSgJefOTfFLMSBE2roZT3JaTa5ZiKieRL1kDTGNVixEPaZ8wBDx9f+Qt6946/btvw P2jkLtbmxsDBk0Im0sw0Tw6+V9Qu+qdDvvbff70JvSHcfjDSTZ/Cv70KNgviWv705ZjVZ08m 2S+NwADACD8dz7wGvEkuUqPqGRidB1S4HOKUvQaYuOPfH6bORGp9lnb/IR18uyvFvw/AEHza +Ef0mgzP3r9/e934PTaZ2PqTFSrAqI15aSzTTEsBkEbFNHUCqZVpEL1dIBXu+bh+kEblTzUH Kdeymrg8YCo2z7LOXNq8kzKyg+Elu9DxLxw3ZqNP4+dRYx5Kk2MIgdXMLBikBtnyZlqmUqbh a2gpmLExVTA2pqbyjM2m5JbpQv+FyU0r03g2khtf/1QT5agV7X1mapuc8hBtw/qxffL28rzz Mz1W8jboO2vqMtCsh9MhwjTrm5wFKU0zX+46ZGwmsXNmrp1Rf9AdjRw3t8Q8mBK4e/EcaTwF 34xXB650N3hgT4spLeEd5j1n0AIHB4UPVX12UDjwMViyEZgyyr224+Br4enUky4YApBQdLSq I7399fa8c31zdn7DFp6Ez1EFHpVI2uNnZKc/8F/P3zULKAAoRK0DNwYFg3cC+X9DIQEFs8RM hhAU+FYCW7OYZpT3Iq33r0os6pnGKrbXfy1deFJ/jD4beA/ydELcgJv1T3LFhd+3F+8651dn FydX/mRlEZaXWJYooH24hIgHYQaBVHkWW6s4cGgtLLaKd4FeBtUmGjyLVIBqaxWnWGRtS3pB x8Q+MaZtVQAae5XncXIp4MvEBplYMqnpvLkli+4ax27kkt+OnBahnExBYxxpOPC8IXoydGC+ U/0vSfoeT6h+353eDdzx6H+0PccZOrH6IAu3AFuKVdOJdUsR3WFdGVu46AnZFKKHErU3O+z9 H3fwpzO+l/aG49HDvtSSlP8rHR9LiviEtVXxFupyR09HqhStrTOI4DZqS4s1waqS9or3V1dH Ox8HGloRPbLsqXrOKd2Y4j4O7j2MJrvSyHnoeoPPdNuK8wB3YBXBqM/CNDybDGDp0YEAofeD 4dBldV+4cuACXwefHHrr6bT7Iv0vW27CO/cgWsXRwSfeDp6kD47nTN39w0XRc+zduG8hFENb Oi+GXji0cCQ9pYN0/EE6OEBl688WQSUmkVP7jxMe4XUcr73w+JqI+3qsZA+hOjkuUqClYnTI iA9U3IpjJdsK1Yk2QzSaTtLGlyMxkdbC84PAo407Dg7eM5G0ZcpAn1l4LtAyN18RtYA+vjwt 8JB21GEyzBzYTGLufLw77n0aOiPBqXjLTu8iiJ4XNleY3XXC59a74GcJ96ick5HeS+3bs9PO +/OTs/Mb/7gGWwYnZ0ctK1fDf1tOF/lvGf9t4aaX4vzn6YMhg/7DDz9iRBEZsqXBJSs8ls79 5u/nv5z//ZvX8PObB3bhx5MfzjuXWAp0c3LzK3yWvBDcFr8j/uG3+GH7/LZzdnkZ3ZG8EI5x cfXD6SkOQP8RXL45uYIb4TL7R3D55AYundzAnwCre0jNe9KHF+9xPGqph/LhGIKJo5Cth5CS RR8mrlPmzHtw58fxSLrugY8yJMX8jsjfyYakyrJMeZgz6s7PTl+6Gn+WJEWSze808zsQM32I JxtVMZuqakSxfMhBnAbGEAg7nuGGcvz3cHA37U5fMHBDwyt1H8CrAbL3uq40nkzGLpulglvp WLxHwReO/Z0e8A942pl60vjun7TxDvhqiAOl6xHO6nrOk0uH8feDQXjWncIXsJEGjtvMvqyL 3wgvE1zeC+bOgNuAe3rPj91PTvBNMP7Jaaf98W37di+Jrv34R4mr4R/Hu7uvgpZCFDbBW0Cg 8YQbXjyspURGscsTKjB6mNvMo4umIEV4we5sSI9xeb13ekqj4K+lW+xJhEchDCE0htdH63Jy 8QtuV6LT9Mi7u9lg2KcDO39MxlN25oh058C9jkQRwoRrR7H+f5Zw4ZtOXx6egWeZoQZPPsfo ezelyCL4d9AB/XfaGxw6h/Se/eCJw+LA+Ta6mrRBGUx9KyVvqDXOuEbF0JqqYUXmXjWMphod 7nznjN2DfT+oTxAP7GVv/3rvJ3AnF9dX+4fueDe89c0b4E6PCvUAWSo0QH84POzuhnenmRv7 987rvbuu61Bov44Jbz96+g1O6/j7tUGgP7bfdW7O2x8vb/deJyDAZ4ypAh9iM2gL3rzLKE8C 7LjhTWdOuGfqq+wNu68pJvcTNOBQ9wMGJHjxDzfX8ObUrTERmXZTtWJzoBW9Wg/4KYHnPn1/ dv6BaSqNUHwZ5r5661T6cdyfgSZLh4dHr/di+rILMmCjwPPsf0IM8B/zhZfDC67YbLOpBc2k kFmaDBei+DJRpHV51ZDCsG2HkY/1dC9uh9k9ZAJ8svPWuW5jG4Cr48ZwBClLg4J7Z+f013c/ X1ylP8En2LXhiP0Z0cFNQnCWjoQpSGh7Tk/b709uzs+SZgrMyvfXN9EnX0vt68DK0NTHHYBF AWufNtPS73ssNqTzOXB3f+x9tU+tJ/Bp5s66uN8TdLgJP4YSDPL+Q+vjL5HynL4/P/3h4urd Xvt6P83K9nUjSsjmsPJxcvDX+w8UDO3rY/gexqCD/Z3gyjjNMn/bPG4jCKRYMxbBX2C48E/m xFbPMgBfiD12GV5gMSv5Ib+KEX8s4Ff0pqGGDeR3du4HbJz26XWn/RMi+4zx9rjR60mtd1Lr hw8Xp/BzoFuG1LpzhhBo/zxstt4yL+TrBETI6LleeAP0X6TW2z627B3ABf85qXV5NHOnRyCe o0HX0IeG3kjRHg30gCMxeTZCRkQfD4OrETP+PzOkQqpNfgIA --zN+5Yck3deUF6VTH-- From mal@lemburg.com Fri Nov 10 10:40:01 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Nov 10 10:40:01 2000 Subject: [Distutils] Cygwin Python DLL and Shared Extension Patch References: <20001110093336.K209@dothill.com> Message-ID: <3A0C1519.D9A70332@lemburg.com> Jason Tishler wrote: > > Attached is a patch that builds Cygwin Python with its core as a DLL -- > similar to the way that one builds Win32 Python. Once Cygwin Python > is built as a "shared library" (i.e., DLL), one can build extensions > using the same procedure as on other UNIX platforms that support shared > libraries. It's as easy as copying Misc/Makefile.pre.in, creating a > Setup.in file, make -f Makefile.pre.in boot, make. I think our goal for distutils should be to provide a cygwin build target -- not encourage people to continue to use the old Makefile.pre.in method. Apart from that, I like the idea of being able to build Python using cygwin tools on Windows. This opens new possibilities for people who don't have access to a compiler on Windows. BTW, do the extensions build using cygwin also work with the stock Python 2.0 installation ? AFAIR there have been a few problems with this in the past. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Jason.Tishler@dothill.com Fri Nov 10 22:18:01 2000 From: Jason.Tishler@dothill.com (Jason Tishler) Date: Fri Nov 10 22:18:01 2000 Subject: [Distutils] Cygwin Python DLL and Shared Extension Patch In-Reply-To: <3A0C1519.D9A70332@lemburg.com>; from mal@lemburg.com on Fri, Nov 10, 2000 at 04:32:41PM +0100 References: <20001110093336.K209@dothill.com> <3A0C1519.D9A70332@lemburg.com> Message-ID: <20001110222102.A227@dothill.com> Marc-Andre, On Fri, Nov 10, 2000 at 04:32:41PM +0100, M.-A. Lemburg wrote: > I think our goal for distutils should be to provide a cygwin > build target -- not encourage people to continue to use the > old Makefile.pre.in method. Sorry for the inappropriate post. I'm really just a Cygwin person trying to get up to speed with Python. > Apart from that, I like the idea of being able to build Python > using cygwin tools on Windows. This opens new possibilities > for people who don't have access to a compiler on Windows. I agreed and hope that people find at least some of my patch useful. Any suggestions on how to move forward? Should I just redo the patch against Python CVS and submit it to the Patch Collector? I was hoping to get some feedback before doing so. > BTW, do the extensions build using cygwin also work with the > stock Python 2.0 installation ? AFAIR there have been a few > problems with this in the past. Some extensions built with Cygwin will, mine won't. My extensions are standard Cygwin DLLs not to be confused with extensions built with mingw or with Cygwin using the -mno-cygwin option. They are linked with a Cygwin Python import library and not the stock Win32 Python one. They are also dependent on the Cygwin POSIX emulation DLL, cygwin1.dll. Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corporation Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com From gward@python.net Fri Nov 10 22:32:05 2000 From: gward@python.net (Greg Ward) Date: Fri Nov 10 22:32:05 2000 Subject: [Distutils] Distutils 1.0.1 releasee In-Reply-To: ; from calvin@cs.uni-sb.de on Wed, Nov 08, 2000 at 02:50:40PM +0100 References: <20001107213237.A678@beelzebub> Message-ID: <20001110222909.A1107@beelzebub> [Bastian's approach to writing config data] > class MyDistribution(Distribution): > def __init__(self, attrs=None): > Distribution.__init__(self, attrs=attrs) > self.config_file = self.get_name()+"Conf.py" > > def create_conf_file(self, directory, data=[]): > """generate a configuration file with all metadata the data > supplied in the 'data' argument""" > data.insert(0, "# this file is automatically created by setup.py") > filename = os.path.join(directory, self.config_file) > # add metadata > metanames = dir(self.metadata) + \ > ['fullname', 'contact', 'contact_email'] > for name in metanames: > method = "get_" + name > cmd = "%s = %s" % (name, `getattr(self.metadata, method)()`) > data.append(cmd) > util.execute(write_file, (filename, data), > "creating %s" % filename, self.verbose>=1,self.dry_run) > > So create_conf_file generates a file Conf.py. You can call the > function from any place in your code (or you can call it never). > I call in two places: > 1) If I need to store some configuration values, my custom > "config" command creates this file with the config values in the > 'data' list. > 2) When installing. This way the Conf.py is installed as a > module and my program has runtime information by importing the module. OK, I think I see what you're getting at here. The fact that participation is voluntary seems nice at first, but doing it that way fails to guarantee a standard way to figure out whether package X is installed on the current system, and which version of X is installed. And the fact that it's "completely general", and can be used for any kind of configuration info, also seems nice at first. But I still think that's wrong: distribution meta-data (name, version, files installed) is different from application configuration data. I think the difference boils down to this: meta-data is fixed, both determined and interpreted by the Distutils, while application config data is (by definition!) entirely application-dependent. The major corollary of this is that end-users might edit application config data, but they had bloody well better not edit installation meta-data. This alone is sufficient justification for keeping them rigidly separated. Also, I *still* don't like Python as a configuration language. It just seems wrong, despite the obvious simplicity of ADMIN_EMAIL = "gward@python.net" FAVOURITE_COLOUR = "greenish-blue" as a config file. I think I'll write up a proposal for storing distribution meta-data. Been mulling it over for long enough, time to write something down. Connected to but independent of this is the need for a standard way to specify, install, and find application-dependent configuration data. The first two are obviously the Distutils' domain; I don't think applications should be dependent on the Distutils at run-time, but we can certainly provide sample code, and make the standard installation location simple and easy so that the boilerplate code to find application config data is simple and easy. Greg -- Greg Ward - programmer-at-large gward@python.net http://starship.python.net/~gward/ God made machine language; all the rest is the work of man. From mal@lemburg.com Sat Nov 11 05:48:01 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat Nov 11 05:48:01 2000 Subject: [Distutils] Cygwin Python DLL and Shared Extension Patch References: <20001110093336.K209@dothill.com> <3A0C1519.D9A70332@lemburg.com> <20001110222102.A227@dothill.com> Message-ID: <3A0D21E0.48C60787@lemburg.com> [This discussion doesn't really belong here... perhaps python-dev would be a better place ?!] Jason Tishler wrote: > > > I like the idea of being able to build Python > > using cygwin tools on Windows. This opens new possibilities > > for people who don't have access to a compiler on Windows. > > I agreed and hope that people find at least some of my patch useful. > Any suggestions on how to move forward? Should I just redo the patch > against Python CVS and submit it to the Patch Collector? I was hoping > to get some feedback before doing so. If the patch allows compiling Python with cygwin tools, I think this would be a valuable addition to the Python supported compiler backends. However a couple of things need to be tested: * Does Python compile without warnings ? * Does the patch interfere with any other compiler backends on the targetted platforms ? * Does the compiled Python version pass the regression suite ? * Are there any issues to be considered, e.g. wrt to licensing ? * Is there enough documentation to allow the average user with some C background to setup a compiler environment which then compiles Python out of the box ? More specifically: * Since we already have a compiler backend on Windows, are there ways to enable/disable compiling a version which works together with MS VC compiled extensions ? Anyway, I don't see any reason why not to upload the patches to SF -- they will get more visibility there than in this forum. > > BTW, do the extensions build using cygwin also work with the > > stock Python 2.0 installation ? AFAIR there have been a few > > problems with this in the past. > > Some extensions built with Cygwin will, mine won't. My extensions are > standard Cygwin DLLs not to be confused with extensions built with > mingw or with Cygwin using the -mno-cygwin option. They are linked > with a Cygwin Python import library and not the stock Win32 Python one. > They are also dependent on the Cygwin POSIX emulation DLL, cygwin1.dll. Ok. So there's a gotcha in there which needs to be highlighted. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Jason.Tishler@dothill.com Mon Nov 13 08:40:01 2000 From: Jason.Tishler@dothill.com (Jason Tishler) Date: Mon Nov 13 08:40:01 2000 Subject: [Distutils] Cygwin Python DLL and Shared Extension Patch In-Reply-To: <3A0D21E0.48C60787@lemburg.com>; from mal@lemburg.com on Sat, Nov 11, 2000 at 11:39:28AM +0100 References: <20001110093336.K209@dothill.com> <3A0C1519.D9A70332@lemburg.com> <20001110222102.A227@dothill.com> <3A0D21E0.48C60787@lemburg.com> Message-ID: <20001113083908.A327@dothill.com> Marc-Andre, On Sat, Nov 11, 2000 at 11:39:28AM +0100, M.-A. Lemburg wrote: > [This discussion doesn't really belong here... perhaps python-dev > would be a better place ?!] I will heed the above suggestion and move this discussion to a more appropriate forum. Also, I will attempt to address your issues there. I apologize for the noise. Anyway, I do really appreciate the time that you have taken to respond to my posts. Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corporation Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com From jack@oratrix.nl Tue Nov 14 17:25:01 2000 From: jack@oratrix.nl (Jack Jansen) Date: Tue Nov 14 17:25:01 2000 Subject: [Distutils] ccompiler.py for an IDE Message-ID: <20001114222438.CF4521301EC@oratrix.oratrix.nl> I'm putting together a mwerksccompiler.py module for distutils, for the MetroWerks CodeWarrior compiler on the macintosh. However, I'm running into a bit of a problem: the distutils architecture seems based on calling the compiler and linker and such all by itself, not through an IDE or Makefile or something. Even for MSVC it doesn't generate a project file but calls all the executables by hand. This isn't an option for CodeWarrior (or, at least, it would mean an extraordinary amount of work), as the compilers and such are merely plugins for the IDE, and everything is driven from the projectfile. The solution I'm now thinking of is to let compile() simply stash away the sourcefiles and include dirs and such and do all the work in link(): generate the project file and build it. Is this a feasible idea? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From Moshe Zadka Wed Nov 15 02:00:01 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed Nov 15 02:00:01 2000 Subject: [Distutils] ccompiler.py for an IDE In-Reply-To: <20001114222438.CF4521301EC@oratrix.oratrix.nl> Message-ID: On Tue, 14 Nov 2000, Jack Jansen wrote: > This isn't an option for CodeWarrior (or, at least, it would mean an > extraordinary amount of work), as the compilers and such are merely > plugins for the IDE, and everything is driven from the projectfile. Couldn't you generate a lot of "small project files" each of which would compile a single c into a single o, and then one project file for the link stage? Or is that the extaordinary amount of work? (On the face of it, it shouldn't be very different then generating a command line, but then again, I haven't seen a Mac for a few millions of years). Another option would seem to be to use the Apple version of COM (sorry, I forgot how they call it) to talk with a persistent IDE. Wouldn't that work? Or would that be too hard? > The solution I'm now thinking of is to let compile() simply stash away > the sourcefiles and include dirs and such and do all the work in > link(): generate the project file and build it. > > Is this a feasible idea? It's probably all right if nothing better comes along, but the problem is that errors would come up in the wrong place if there are any. -- Moshe Zadka -- 95855124 http://advogato.org/person/moshez From jack@oratrix.nl Wed Nov 15 04:29:01 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed Nov 15 04:29:01 2000 Subject: [Distutils] ccompiler.py for an IDE In-Reply-To: Message by Moshe Zadka , Wed, 15 Nov 2000 08:59:04 +0200 (IST) , Message-ID: <20001115092712.870EA35BAF6@snelboot.oratrix.nl> > On Tue, 14 Nov 2000, Jack Jansen wrote: > > > This isn't an option for CodeWarrior (or, at least, it would mean an > > extraordinary amount of work), as the compilers and such are merely > > plugins for the IDE, and everything is driven from the projectfile. > > Couldn't you generate a lot of "small project files" each of which > would compile a single c into a single o, and then one project > file for the link stage? Or is that the extaordinary amount of work? > (On the face of it, it shouldn't be very different then generating > a command line, but then again, I haven't seen a Mac for a few millions > of years). Another option would seem to be to use the Apple version > of COM (sorry, I forgot how they call it) to talk with a persistent > IDE. Wouldn't that work? Or would that be too hard? This is both a lot of work, and possibly hard as well (I don't think there is anything corresponding to the ".obj" file in the normal course of events, so I would have to find some sort of a hack there). > It's probably all right if nothing better comes along, but the problem > is that errors would come up in the wrong place if there are any. I'm not sure I understand this. Errors from the compiler will always come up in a window, there's no such thing as standard error on the Mac. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Wed Nov 15 04:33:01 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed Nov 15 04:33:01 2000 Subject: [Distutils] Distutils filenames Message-ID: <20001115093204.5B1F735BAF6@snelboot.oratrix.nl> Another problem I ran into with distutils is that while most pathnames follow the local machine convention so do not. More precisely, the source files and such that the package developer put in their setup.py file are passed along unmodified. For now I've put in a heuristic that will convert pathnames from unix-format to mac-format if they contain a / and do not contain a :, but in the long run it's probably better if it's specified in what form pathnames in setup.py should be, and have the core of distutils convert them. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From Moshe Zadka Wed Nov 15 04:38:01 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed Nov 15 04:38:01 2000 Subject: [Distutils] ccompiler.py for an IDE In-Reply-To: <20001115092712.870EA35BAF6@snelboot.oratrix.nl> Message-ID: [Moshe] > > It's probably all right if nothing better comes along, but the problem > > is that errors would come up in the wrong place if there are any. [Jack Jansen] > I'm not sure I understand this. Errors from the compiler will always come up > in a window, there's no such thing as standard error on the Mac. We're having a dimensiinal misunderstanding here: I meant the wrong place in the time dimension. I wouldn't presume to think the Mac has something as ordinary as stderr . -- Moshe Zadka -- 95855124 http://advogato.org/person/moshez From jack@oratrix.nl Wed Nov 15 04:47:01 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed Nov 15 04:47:01 2000 Subject: [Distutils] ccompiler.py for an IDE In-Reply-To: Message by Moshe Zadka , Wed, 15 Nov 2000 11:37:10 +0200 (IST) , Message-ID: <20001115094528.9997E35BAF6@snelboot.oratrix.nl> > > I'm not sure I understand this. Errors from the compiler will always come up > > in a window, there's no such thing as standard error on the Mac. > > We're having a dimensiinal misunderstanding here: I meant the > wrong place in the time dimension. I wouldn't presume to think > the Mac has something as ordinary as stderr . No, of course not! Who needs stderr when you can have translucent pulsating buttons, really? :-) But seriously: my intention was to have link() do buth the generation of the project file and the actual build, so the errors would come up at that time (which seems to be the same time as they would come up on other platforms, no?). After the build distutils will take over again to do the install or whatever else it wants to do. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From R.Liebscher@gmx.de Wed Nov 15 05:50:01 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Wed Nov 15 05:50:01 2000 Subject: [Distutils] Distutils filenames References: <20001115093204.5B1F735BAF6@snelboot.oratrix.nl> Message-ID: <3A126A08.CB4FA8C1@gmx.de> Jack Jansen wrote: > > Another problem I ran into with distutils is that while most pathnames follow > the local machine convention so do not. More precisely, the source files and > such that the package developer put in their setup.py file are passed along > unmodified. > > For now I've put in a heuristic that will convert pathnames from unix-format > to mac-format if they contain a / and do not contain a :, but in the long run > it's probably better if it's specified in what form pathnames in setup.py > should be, and have the core of distutils convert them. There is already a function for this purpose. util.py, line 63 convert_path() You should check if it does the same what your function is supposed to do. And it might be a good idea to use it in the Extension class constructor to convert all paths in the format you need. (This would also mean, all paths have to specified as unix paths.) kind regards Rene Liebscher From R.Liebscher@gmx.de Wed Nov 15 09:12:01 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Wed Nov 15 09:12:01 2000 Subject: [Distutils] get_platform(), patch for AIX Message-ID: <3A129930.1A8AC827@gmx.de> This is a multi-part message in MIME format. --------------7D25F63D8B25E024A6D30BC0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The platform string which is build by get_platform() doesnt make much sense. Therefore I provide here a patch which brings up a better string. (eg. for AIX 4.3 -> aix-4.3 not aix-3-XXXXXXXXXXXX , machine seems to be a hardware id ? ) kind regards Rene Liebscher --------------7D25F63D8B25E024A6D30BC0 Content-Type: text/plain; charset=us-ascii; name="aix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="aix.patch" diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/util.py distutils.patchedx/distutils/util.py --- distutils.orig/distutils/util.py Mon Oct 16 11:37:39 2000 +++ distutils.patchedx/distutils/util.py Wed Nov 15 16:21:24 2000 @@ -54,6 +54,8 @@ # fall through to standard osname-release-machine representation elif osname[:4] == "irix": # could be "irix64"! return "%s-%s" % (osname, release) + elif osname[:3] == "aix": + return "%s-%s.%s" % (osname, version, release) return "%s-%s-%s" % (osname, release, machine) --------------7D25F63D8B25E024A6D30BC0-- From vanandel@ucar.edu Wed Nov 15 18:20:01 2000 From: vanandel@ucar.edu (Joe Van Andel) Date: Wed Nov 15 18:20:01 2000 Subject: [Distutils] distutils 1.0.1 - bdist_rpm- MANIFEST.in recursive-include broken? Message-ID: <3A131A00.96B875F7@atd.ucar.edu> Using distutils 1.0.1 with Python 1.5.2 on Redhat 6.2: I'm trying to build an RPM for my package using distutils. I tried to create 'MANIFEST.in', containing: recursive-include *.py recursive-include *.h recursive-include *.hh recursive-include *.cc recursive-include *.c graft examples prune test global-exclude *~ However, the resulting MANIFEST is missing the include files (*.h), so the necessary files aren't copied to the temporary build directories, and the RPM related compilations fail. I finally built an explicit MANIFEST file that contained all my source code files, and then setup.py bdist_rpm worked. (Of course having to manually build 'MANIFEST' is extra work.) Is there another snapshot in the works, or should I try the CVS version? -- Joe VanAndel National Center for Atmospheric Research http://www.atd.ucar.edu/~vanandel/ Internet: vanandel@ucar.edu From calvin@cs.uni-sb.de Wed Nov 15 18:26:09 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Wed Nov 15 18:26:09 2000 Subject: [Distutils] distutils 1.0.1 - bdist_rpm- MANIFEST.in recursive-include broken? In-Reply-To: <3A131A00.96B875F7@atd.ucar.edu> Message-ID: >I'm trying to build an RPM for my package using distutils. I tried to >create 'MANIFEST.in', containing: > >recursive-include *.py You can try "recursive-include . *.py". I think the second param must be a directory name. Bastian From vanandel@ucar.edu Wed Nov 15 18:37:06 2000 From: vanandel@ucar.edu (Joe Van Andel) Date: Wed Nov 15 18:37:06 2000 Subject: [Distutils] distutils 1.0.1 - bdist_rpm- MANIFEST.in recursive-includebroken? References: Message-ID: <3A131DF5.DB82E91F@atd.ucar.edu> Bastian Kleineidam wrote: > You can try "recursive-include . *.py". I think the second param must > be a directory name. I just tried your suggestion, and the include files (*.h) still aren't added to the MANIFEST, so the compilations fail. -- Joe VanAndel National Center for Atmospheric Research http://www.atd.ucar.edu/~vanandel/ Internet: vanandel@ucar.edu From R.Liebscher@gmx.de Thu Nov 16 03:54:01 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Thu Nov 16 03:54:01 2000 Subject: [Distutils] distutils 1.0.1 - bdist_rpm- MANIFEST.in recursive-includebroken? References: <3A131DF5.DB82E91F@atd.ucar.edu> Message-ID: <3A13A011.DB69F350@gmx.de> Joe Van Andel wrote: > > Bastian Kleineidam wrote: > > > You can try "recursive-include . *.py". I think the second param must > > be a directory name. > > I just tried your suggestion, and the include files (*.h) still aren't > added to the MANIFEST, so the compilations fail. Using a dot as directory might not yield the results you think. filelist.py works string-based, and files in the current directory are stored in its internal list as "xxxx.h". So it can't find a prefix '.' anywhere. Instead "recursive-include . *.h" you should use "global-include *.h". kind regards Rene Liebscher BTW: It might be a good idea to debug MANIFEST.in files line by line. (You can create the MANIFEST file with "python setup.py sdist -o".) (Greg: Either we document that MANIFEST.in doesn't accept any relative paths (containing '.' or '..') or we send all files/dirs from the template and all files that form filelist's base list through normpath() or even better for Windows normcase().) From mal@lemburg.com Thu Nov 16 04:08:01 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu Nov 16 04:08:01 2000 Subject: [Distutils] distutils 1.0.1 - bdist_rpm- MANIFEST.in recursive-includebroken? References: <3A131DF5.DB82E91F@atd.ucar.edu> <3A13A011.DB69F350@gmx.de> Message-ID: <3A13A13E.2B20DEE0@lemburg.com> Rene Liebscher wrote: > (Greg: Either we document that MANIFEST.in doesn't accept any relative > paths (containing '.' or '..') or we send all files/dirs from the > template > and all files that form filelist's base list through normpath() or even > better for Windows normcase().) I think accepting relative paths is a good idea to ease the work of developers. Instead of normpath(), I'd use abspath() though since this turns relative paths into absolute ones. After having done that you may also want to strip the current dir from the absolute names to get ones relative to the current work dir. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas.heller@ion-tof.com Thu Nov 16 11:13:00 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Nov 16 11:13:00 2000 Subject: [Distutils] bdist_winexe command Message-ID: <013801c04fe8$0189d0f0$e000a8c0@thomasnotebook> I'm currently writing (it is nearly finished) a bdist_wininst command, which is modeled after Gordon's windows installer. This command will create standalone executable exe-files for the win32 platform from the scripts which are specified in the setup script. The exe-file contains all the python modules needed by the script as well as the script itself in a zip-archive appended to a small stub program. The only other file needed is pythonxx.dll in the same directory as the exe-file itself. There is no need that the normal python distribution is installed on the system. Note: In case the script needs extension modules (*.dll or *.pyd files) these are needed as separate files as well, because they cannot be packed into the zip-archive. (Well, they could be packed, but they would have to be extracted before starting the script. This is in fact what Gordon's installer does.) Another note: There will be an option to use another stub, which contains the extensions distributed with python as separate pyd's: _sre, socket, zlib, ... So far, so good. Now for the problems: 1. I intend to distribute this command as a distutils extension. Unfortunately, it's a shame that we cannot use distutils to distribute itself (or additional commands). Distutils would install itself (in windows speak) in c:\Python20\distutils, whereas the stock distutils is located in c:\Python20\lib\distutils. Should there be a special hack in the setup script? 2. Should this command be integrated into distutils? Perhaps it is far too early for this question. 3. I would like to avoid the mistake I made in bdist_wininst, that the stub program's bytes are appended to the text of the bdist_wininst.py file, base64 encoded. So there would be one (or more) binary file winstub.exe somewhere on the file system. Where? distutils\commands\winstub.exe distutils\data\winstub.exe ? Thomas From jack@oratrix.nl Fri Nov 17 09:04:01 2000 From: jack@oratrix.nl (Jack Jansen) Date: Fri Nov 17 09:04:01 2000 Subject: [Distutils] Looking for packages to test on the Mac Message-ID: <20001117140307.AAACF35BAF6@snelboot.oratrix.nl> Can someone point me to a disutils-based packages that I can try to install with my new Mac distutils code? I'm now so far that I can install various toy packages and one serious one (Numeric), but I'd like to get a few more test points... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From thomas.heller@ion-tof.com Fri Nov 17 09:18:01 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Fri Nov 17 09:18:01 2000 Subject: [Distutils] Looking for packages to test on the Mac References: <20001117140307.AAACF35BAF6@snelboot.oratrix.nl> Message-ID: <027901c050a1$2e14b680$e000a8c0@thomasnotebook> > Can someone point me to a disutils-based packages that I can try to install > with my new Mac distutils code? I'm now so far that I can install various toy > packages and one serious one (Numeric), but I'd like to get a few more test > points... I have used the xml-package and linkchecker http://pyxml.sourceforge.net/ http://linkchecker.sourceforge.net/ Thomas From thomas.heller@ion-tof.com Fri Nov 17 09:59:01 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Fri Nov 17 09:59:01 2000 Subject: [Distutils] Patch for msvccompiler.py Message-ID: <02f401c050a6$c962ea30$e000a8c0@thomasnotebook> This is a multi-part message in MIME format. ------=_NextPart_000_02F1_01C050AF.2B11F570 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit The attached patch converts filenames to absolute paths before they are compiled. This make debugging easier, because the debugger is able to find the source files without asking the user. Thomas ------=_NextPart_000_02F1_01C050AF.2B11F570 Content-Type: text/plain; name="diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="diff.txt" Index: msvccompiler.py =================================================================== RCS file: /cvsroot/python/distutils/distutils/msvccompiler.py,v retrieving revision 1.42 diff -c -r1.42 msvccompiler.py *** msvccompiler.py 2000/09/27 02:08:14 1.42 --- msvccompiler.py 2000/11/17 14:53:06 *************** *** 305,313 **** self.mkpath (os.path.dirname (obj)) if ext in self._c_extensions: ! input_opt = "/Tc" + src elif ext in self._cpp_extensions: ! input_opt = "/Tp" + src elif ext in self._rc_extensions: # compile .RC to .RES file input_opt = src --- 305,313 ---- self.mkpath (os.path.dirname (obj)) if ext in self._c_extensions: ! input_opt = "/Tc" + os.path.abspath(src) elif ext in self._cpp_extensions: ! input_opt = "/Tp" + os.path.abspath(src) elif ext in self._rc_extensions: # compile .RC to .RES file input_opt = src ------=_NextPart_000_02F1_01C050AF.2B11F570-- From mfletch@tpresence.com Fri Nov 17 11:00:02 2000 From: mfletch@tpresence.com (Mike Fletcher) Date: Fri Nov 17 11:00:02 2000 Subject: [Distutils] Looking for packages to test on the Mac Message-ID: For a likely-to-fail one, PyOpenGL 1.5.6a2 at http://sourceforge.net/project/showfiles.php?group_id=5988 (it's likely to fail since there was an entire branch of code dedicated to the Mac that hasn't been touched since 1.5.5 (Rene ported us to distutils between 1.5.5 and 1.5.6)). Enjoy, Mike -----Original Message----- From: Jack Jansen [mailto:jack@oratrix.nl] Sent: Friday, November 17, 2000 9:03 AM To: distutils-sig@python.org Subject: [Distutils] Looking for packages to test on the Mac Can someone point me to a disutils-based packages that I can try to install with my new Mac distutils code? I'm now so far that I can install various toy packages and one serious one (Numeric), but I'd like to get a few more test points... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://www.python.org/mailman/listinfo/distutils-sig From Mike.Olson@fourthought.com Fri Nov 17 17:17:01 2000 From: Mike.Olson@fourthought.com (Mike Olson) Date: Fri Nov 17 17:17:01 2000 Subject: [Distutils] Looking for packages to test on the Mac References: <20001117140307.AAACF35BAF6@snelboot.oratrix.nl> Message-ID: <3A15AE42.ACFE58EC@FourThought.com> Jack Jansen wrote: > > Can someone point me to a disutils-based packages that I can try to install > with my new Mac distutils code? I'm now so far that I can install various toy > packages and one serious one (Numeric), but I'd like to get a few more test > points... Have a try at 4suite. http://4Suite.org/download.epy Mike > -- > Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ > www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://www.python.org/mailman/listinfo/distutils-sig -- Mike Olson Principal Consultant mike.olson@fourthought.com (303)583-9900 x 102 Fourthought, Inc. http://Fourthought.com Software-engineering, knowledge-management, XML, CORBA, Linux, Python From jack@oratrix.nl Sun Nov 19 17:33:01 2000 From: jack@oratrix.nl (Jack Jansen) Date: Sun Nov 19 17:33:01 2000 Subject: [Distutils] Installing package include files Message-ID: <20001119223215.603691301E4@oratrix.oratrix.nl> Something that slightly bothers me with distutils is that if you run Python from source it installs package include files into the Python Include directory. This is a bit of an annoyance for me (as it means I have to clean out the cruft before I create a MacPython source distribution) but I'm really more worried about the elegance of it. Shouldn't there be a site-Include, along the line of the site-packages, so that package include files can't collide with standard Python include files? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From jack@oratrix.nl Sun Nov 19 18:02:01 2000 From: jack@oratrix.nl (Jack Jansen) Date: Sun Nov 19 18:02:01 2000 Subject: [Distutils] Thanks for the help! Message-ID: <20001119230100.008981301E4@oratrix.oratrix.nl> Folks, thanks for the help on distutils-based packages to try. Numeric and PyXML now install flawlessly on the Mac, I'll be mailing the diffs to Greg tomorrow. If someone else wants to play with distutils on the Mac please let me know: I've also had to fix a few bugs in the mkcwproject module, so unless you're using MacPython from the CVS server you'll need to get a newer copy from me. Oh yes: PyOpenGL and Linkchecker, which were also suggested as test cases, were too much work initially. PyOpenGL has "if sys.platform == win32" all over the place and expects that anything that isn't win32 is unix and it expects that a tcl/tk source distribution is available, Linkchecker uses absolute unix pathnames and uses various tricks from the distutils config stuff, which aren't implemented yet (and which may actually be rather difficult to implement). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ From calvin@cs.uni-sb.de Sun Nov 19 18:55:01 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Sun Nov 19 18:55:01 2000 Subject: [Distutils] bdist_rpm and compressed man pages Message-ID: Hello, I have a man page in my data files specified. It seems that the compression of man pages confuses the bdist_rpm command. When I am executing python setup.py bdist_rpm the man page is copied and then compressed with the brp-compress script: [...] creating /var/tmp/LinkChecker-buildroot/usr/man creating /var/tmp/LinkChecker-buildroot/usr/man/man1 copying linkchecker.1 -> /var/tmp/LinkChecker-buildroot/usr/man/man1 writing list of installed files to 'INSTALLED_FILES' [...] + /usr/lib/rpm/brp-compress + /usr/lib/rpm/brp-strip + /usr/lib/rpm/brp-strip-comment-note Processing files: LinkChecker-1.2.8-1 File not found: /var/tmp/LinkChecker-buildroot/usr/man/man1/linkchecker.1 Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.69025 [...] Provides: linkchecker error: command 'rpm' failed with exit status 1 Does anyone know how to fix this? Greetings from Bastian From jack@oratrix.nl Mon Nov 20 05:04:02 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon Nov 20 05:04:02 2000 Subject: [Distutils] Mac mods for distutils Message-ID: <20001120100307.115C435BAF6@snelboot.oratrix.nl> This is a multipart MIME message. --==_Exmh_11048233920 Content-Type: text/plain; charset=us-ascii [Hmm, my address for Greg, gward@python.net, appears outdated. So I'm sending it here in stead] Greg, here are two diffs and a new file for distutils on the mac. The ccompiler.py diff adds support for the MetroWerks compiler, the dist.py diff moves the Mac argument dialog code to a different place (apparently a few things have changed, it didn't work anymore in the old place). There's also a new file mwerkscompiler.py which is the compiler.py implementation for Metrowerks Codewarrior. Oh yes: the diffs are against the Python CVS tree, not the distutils cvs tree. Let me know if that's a problem and I'll convert them to the other one. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++ --==_Exmh_11048233920 Content-Type: text/plain ; name="distutils.diff"; charset=us-ascii Content-Description: distutils.diff Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="distutils.diff" Y3ZzIC16OSBkaWZmIGNjb21waWxlci5weSAoaW4gZGlyZWN0b3J5IE1hY2ludG9zaCBIRDpT V2RldjpKYWNrOlB5dGhvbjpMaWI6ZGlzdHV0aWxzOikKSW5kZXg6IGNjb21waWxlci5weQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09ClJDUyBmaWxlOiAvY3Zzcm9vdC9weXRob24vcHl0aG9uL2Rpc3Qvc3Jj L0xpYi9kaXN0dXRpbHMvY2NvbXBpbGVyLnB5LHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjM1 CmRpZmYgLWMgLXIxLjM1IGNjb21waWxlci5weQoqKiogY2NvbXBpbGVyLnB5CTIwMDAvMDkv MjcgMDI6MjQ6MjEJMS4zNQotLS0gY2NvbXBpbGVyLnB5CTIwMDAvMTEvMTkgMjI6NDk6MzIK KioqKioqKioqKioqKioqCioqKiA4MzgsODQzICoqKioKLS0tIDgzOCw4NDQgLS0tLQogICMg dGhhdCBwbGF0Zm9ybS4KICBkZWZhdWx0X2NvbXBpbGVyID0geyAncG9zaXgnOiAndW5peCcs CiAgICAgICAgICAgICAgICAgICAgICAgJ250JzogJ21zdmMnLAorICAgICAgICAgICAgICAg ICAgICAgICdtYWMnOiAnbXdlcmtzJywKICAgICAgICAgICAgICAgICAgICAgfQogIAogICMg TWFwIGNvbXBpbGVyIHR5cGVzIHRvIChtb2R1bGVfbmFtZSwgY2xhc3NfbmFtZSkgcGFpcnMg LS0gaWUuIHdoZXJlIHRvCioqKioqKioqKioqKioqKgoqKiogODUzLDg1OCAqKioqCi0tLSA4 NTQsODYxIC0tLS0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIk1pbmd3MzIg cG9ydCBvZiBHTlUgQyBDb21waWxlciBmb3IgV2luMzIiKSwKICAgICAgICAgICAgICAgICAg ICAgJ2JjcHAnOiAgICAoJ2JjcHBjb21waWxlcicsICdCQ1BQQ29tcGlsZXInLAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAiQm9ybGFuZCBDKysgQ29tcGlsZXIiKSwKKyAg ICAgICAgICAgICAgICAgICAgJ213ZXJrcyc6ICAoJ213ZXJrc2NvbXBpbGVyJywgJ01XZXJr c0NvbXBpbGVyJywKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIk1ldHJvV2Vy a3MgQ29kZVdhcnJpb3IiKSwKICAgICAgICAgICAgICAgICAgIH0KICAKICBkZWYgc2hvd19j b21waWxlcnMoKToKCioqKioqQ1ZTIGV4aXRlZCBub3JtYWxseSB3aXRoIGNvZGUgMSoqKioq CgpjdnMgLXo5IGRpZmYgZGlzdC5weSAoaW4gZGlyZWN0b3J5IE1hY2ludG9zaCBIRDpTV2Rl djpKYWNrOlB5dGhvbjpMaWI6ZGlzdHV0aWxzOikKSW5kZXg6IGRpc3QucHkKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQpSQ1MgZmlsZTogL2N2c3Jvb3QvcHl0aG9uL3B5dGhvbi9kaXN0L3NyYy9MaWIvZGlz dHV0aWxzL2Rpc3QucHksdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNDIKZGlmZiAtYyAtcjEu NDIgZGlzdC5weQoqKiogZGlzdC5weQkyMDAwLzExLzExIDAyOjQ3OjExCTEuNDIKLS0tIGRp c3QucHkJMjAwMC8xMS8xOSAyMjo0OTo1MAoqKioqKioqKioqKioqKioKKioqIDE3MiwxODMg KioqKgogICAgICAgICAgIyBvcGVyYXRpb25zLCB3ZSBqdXN0IGNoZWNrIHRoZSAnaGF2ZV9y dW4nIGRpY3Rpb25hcnkgYW5kIGNhcnJ5IG9uLgogICAgICAgICAgIyBJdCdzIG9ubHkgc2Fm ZSB0byBxdWVyeSAnaGF2ZV9ydW4nIGZvciBhIGNvbW1hbmQgY2xhc3MgdGhhdCBoYXMKICAg ICAgICAgICMgYmVlbiBpbnN0YW50aWF0ZWQgLS0gYSBmYWxzZSB2YWx1ZSB3aWxsIGJlIGlu c2VydGVkIHdoZW4gdGhlCi0gICAgICAgICBpZiBzeXMucGxhdGZvcm0gPT0gJ21hYyc6Ci0g ICAgICAgICAgICAgaW1wb3J0IEVhc3lEaWFsb2dzCi0gICAgICAgICAgICAgY21kbGlzdCA9 IHNlbGYuZ2V0X2NvbW1hbmRfbGlzdCgpCi0gICAgICAgICAgICAgc2VsZi5zY3JpcHRfYXJn cyA9IEVhc3lEaWFsb2dzLkdldEFyZ3YoCi0gICAgICAgICAgICAgICAgIHNlbGYuZ2xvYmFs X29wdGlvbnMgKyBzZWxmLmRpc3BsYXlfb3B0aW9ucywgY21kbGlzdCkKLSAKICAgICAgICAg ICMgY29tbWFuZCBvYmplY3QgaXMgY3JlYXRlZCwgYW5kIHJlcGxhY2VkIHdpdGggYSB0cnVl IHZhbHVlIHdoZW4KICAgICAgICAgICMgdGhlIGNvbW1hbmQgaXMgc3VjY2Vzc2Z1bGx5IHJ1 bi4gIFRodXMgaXQncyBwcm9iYWJseSBiZXN0IHRvIHVzZQogICAgICAgICAgIyAnLmdldCgp JyByYXRoZXIgdGhhbiBhIHN0cmFpZ2h0IGxvb2t1cC4KLS0tIDE3MiwxNzcgLS0tLQoqKioq KioqKioqKioqKioKKioqIDM3NSwzODAgKioqKgotLS0gMzY5LDM4NCAtLS0tCiAgICAgICAg ICBleGVjdXRlIGNvbW1hbmRzIChjdXJyZW50bHksIHRoaXMgb25seSBoYXBwZW5zIGlmIHVz ZXIgYXNrcyBmb3IKICAgICAgICAgIGhlbHApLgogICAgICAgICAgIiIiCisgICAgICAgICAj CisgICAgICAgICAjIFdlIG5vdyBoYXZlIGVub3VnaCBpbmZvcm1hdGlvbiB0byBzaG93IHRo ZSBNYWNpbnRvc2ggZGlhbG9nIHRoYXQgYWxsb3dzCisgICAgICAgICAjIHRoZSB1c2VyIHRv IGludGVyYWN0aXZlbHkgc3BlY2lmeSB0aGUgImNvbW1hbmQgbGluZSIuCisgICAgICAgICAj CisgICAgICAgICBpZiBzeXMucGxhdGZvcm0gPT0gJ21hYyc6CisgICAgICAgICAgICAgaW1w b3J0IEVhc3lEaWFsb2dzCisgICAgICAgICAgICAgY21kbGlzdCA9IHNlbGYuZ2V0X2NvbW1h bmRfbGlzdCgpCisgICAgICAgICAgICAgc2VsZi5zY3JpcHRfYXJncyA9IEVhc3lEaWFsb2dz LkdldEFyZ3YoCisgICAgICAgICAgICAgICAgIHNlbGYuZ2xvYmFsX29wdGlvbnMgKyBzZWxm LmRpc3BsYXlfb3B0aW9ucywgY21kbGlzdCkKKyAgCiAgICAgICAgICAjIFdlIGhhdmUgdG8g cGFyc2UgdGhlIGNvbW1hbmQgbGluZSBhIGJpdCBhdCBhIHRpbWUgLS0gZ2xvYmFsCiAgICAg ICAgICAjIG9wdGlvbnMsIHRoZW4gdGhlIGZpcnN0IGNvbW1hbmQsIHRoZW4gaXRzIG9wdGlv bnMsIGFuZCBzbyBvbiAtLQogICAgICAgICAgIyBiZWNhdXNlIGVhY2ggY29tbWFuZCB3aWxs IGJlIGhhbmRsZWQgYnkgYSBkaWZmZXJlbnQgY2xhc3MsIGFuZAoKKioqKipDVlMgZXhpdGVk IG5vcm1hbGx5IHdpdGggY29kZSAxKioqKioKCg== --==_Exmh_11048233920 Content-Type: text/plain ; name="mwerkscompiler.py"; charset=us-ascii Content-Description: mwerkscompiler.py Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mwerkscompiler.py" IiIiZGlzdHV0aWxzLm13ZXJrc2NvbXBpbGVyCgpDb250YWlucyBNV2Vya3NDb21waWxlciwg YW4gaW1wbGVtZW50YXRpb24gb2YgdGhlIGFic3RyYWN0IENDb21waWxlciBjbGFzcwpmb3Ig TWV0cm9XZXJrcyBDb2RlV2FycmlvciBvbiB0aGUgTWFjaW50b3NoLiBOZWVkcyB3b3JrIHRv IHN1cHBvcnQgQ1cgb24KV2luZG93cy4iIiIKCmltcG9ydCBzeXMsIG9zLCBzdHJpbmcKZnJv bSB0eXBlcyBpbXBvcnQgKgpmcm9tIGRpc3R1dGlscy5lcnJvcnMgaW1wb3J0IFwKICAgICBE aXN0dXRpbHNFeGVjRXJyb3IsIERpc3R1dGlsc1BsYXRmb3JtRXJyb3IsIFwKICAgICBDb21w aWxlRXJyb3IsIExpYkVycm9yLCBMaW5rRXJyb3IKZnJvbSBkaXN0dXRpbHMuY2NvbXBpbGVy IGltcG9ydCBcCiAgICAgQ0NvbXBpbGVyLCBnZW5fcHJlcHJvY2Vzc19vcHRpb25zLCBnZW5f bGliX29wdGlvbnMKaW1wb3J0IGRpc3R1dGlscy51dGlsCmltcG9ydCBkaXN0dXRpbHMuZGly X3V0aWwKaW1wb3J0IG1rY3dwcm9qZWN0CgpjbGFzcyBNV2Vya3NDb21waWxlciAoQ0NvbXBp bGVyKSA6CiAgICAiIiJDb25jcmV0ZSBjbGFzcyB0aGF0IGltcGxlbWVudHMgYW4gaW50ZXJm YWNlIHRvIE1pY3Jvc29mdCBWaXN1YWwgQysrLAogICAgICAgYXMgZGVmaW5lZCBieSB0aGUg Q0NvbXBpbGVyIGFic3RyYWN0IGNsYXNzLiIiIgoKICAgIGNvbXBpbGVyX3R5cGUgPSAnbXdl cmtzJwoKICAgICMgSnVzdCBzZXQgdGhpcyBzbyBDQ29tcGlsZXIncyBjb25zdHJ1Y3RvciBk b2Vzbid0IGJhcmYuICBXZSBjdXJyZW50bHkKICAgICMgZG9uJ3QgdXNlIHRoZSAnc2V0X2V4 ZWN1dGFibGVzKCknIGJ1cmVhdWNyYWN5IHByb3ZpZGVkIGJ5IENDb21waWxlciwKICAgICMg YXMgaXQgcmVhbGx5IGlzbid0IG5lY2Vzc2FyeSBmb3IgdGhpcyBzb3J0IG9mIHNpbmdsZS1j b21waWxlciBjbGFzcy4KICAgICMgV291bGQgYmUgbmljZSB0byBoYXZlIGEgY29uc2lzdGVu dCBpbnRlcmZhY2Ugd2l0aCBVbml4Q0NvbXBpbGVyLAogICAgIyB0aG91Z2gsIHNvIGl0J3Mg d29ydGggdGhpbmtpbmcgYWJvdXQuCiAgICBleGVjdXRhYmxlcyA9IHt9CgogICAgIyBQcml2 YXRlIGNsYXNzIGRhdGEgKG5lZWQgdG8gZGlzdGluZ3Vpc2ggQyBmcm9tIEMrKyBzb3VyY2Ug Zm9yIGNvbXBpbGVyKQogICAgX2NfZXh0ZW5zaW9ucyA9IFsnLmMnXQogICAgX2NwcF9leHRl bnNpb25zID0gWycuY2MnLCAnLmNwcCcsICcuY3h4J10KICAgIF9yY19leHRlbnNpb25zID0g WycuciddCiAgICBfZXhwX2V4dGVuc2lvbiA9ICcuZXhwJwoKICAgICMgTmVlZGVkIGZvciB0 aGUgZmlsZW5hbWUgZ2VuZXJhdGlvbiBtZXRob2RzIHByb3ZpZGVkIGJ5IHRoZQogICAgIyBi YXNlIGNsYXNzLCBDQ29tcGlsZXIuCiAgICBzcmNfZXh0ZW5zaW9ucyA9IChfY19leHRlbnNp b25zICsgX2NwcF9leHRlbnNpb25zICsKICAgICAgICAgICAgICAgICAgICAgIF9yY19leHRl bnNpb25zKQogICAgcmVzX2V4dGVuc2lvbiA9ICcucnNyYycKICAgIG9ial9leHRlbnNpb24g PSAnLm9iaicgIyBOb3QgdXNlZCwgcmVhbGx5CiAgICBzdGF0aWNfbGliX2V4dGVuc2lvbiA9 ICcubGliJwogICAgc2hhcmVkX2xpYl9leHRlbnNpb24gPSAnLnNsYicKICAgIHN0YXRpY19s aWJfZm9ybWF0ID0gc2hhcmVkX2xpYl9mb3JtYXQgPSAnJXMlcycKICAgIGV4ZV9leHRlbnNp b24gPSAnJwoKCiAgICBkZWYgX19pbml0X18gKHNlbGYsCiAgICAgICAgICAgICAgICAgIHZl cmJvc2U9MCwKICAgICAgICAgICAgICAgICAgZHJ5X3J1bj0wLAogICAgICAgICAgICAgICAg ICBmb3JjZT0wKToKCiAgICAgICAgQ0NvbXBpbGVyLl9faW5pdF9fIChzZWxmLCB2ZXJib3Nl LCBkcnlfcnVuLCBmb3JjZSkKICAgICAgICAKICAgICAgICAKICAgIGRlZiBjb21waWxlIChz ZWxmLAogICAgICAgICAgICAgICAgIHNvdXJjZXMsCiAgICAgICAgICAgICAgICAgb3V0cHV0 X2Rpcj1Ob25lLAogICAgICAgICAgICAgICAgIG1hY3Jvcz1Ob25lLAogICAgICAgICAgICAg ICAgIGluY2x1ZGVfZGlycz1Ob25lLAogICAgICAgICAgICAgICAgIGRlYnVnPTAsCiAgICAg ICAgICAgICAgICAgZXh0cmFfcHJlYXJncz1Ob25lLAogICAgICAgICAgICAgICAgIGV4dHJh X3Bvc3RhcmdzPU5vbmUpOgogICAgICAgICBzZWxmLl9fc291cmNlcyA9IHNvdXJjZXMKICAg ICAgICAgc2VsZi5fX21hY3JvcyA9IG1hY3JvcwogICAgICAgICBzZWxmLl9faW5jbHVkZV9k aXJzID0gaW5jbHVkZV9kaXJzCiAgICAgICAgICMgRG9uJ3QgbmVlZCBleHRyYV9wcmVhcmdz IGFuZCBleHRyYV9wb3N0YXJncyBmb3IgQ1cKICAgICAgICAgCiAgICBkZWYgbGluayAoc2Vs ZiwKICAgICAgICAgICAgICB0YXJnZXRfZGVzYywKICAgICAgICAgICAgICBvYmplY3RzLAog ICAgICAgICAgICAgIG91dHB1dF9maWxlbmFtZSwKICAgICAgICAgICAgICBvdXRwdXRfZGly PU5vbmUsCiAgICAgICAgICAgICAgbGlicmFyaWVzPU5vbmUsCiAgICAgICAgICAgICAgbGli cmFyeV9kaXJzPU5vbmUsCiAgICAgICAgICAgICAgcnVudGltZV9saWJyYXJ5X2RpcnM9Tm9u ZSwKICAgICAgICAgICAgICBleHBvcnRfc3ltYm9scz1Ob25lLAogICAgICAgICAgICAgIGRl YnVnPTAsCiAgICAgICAgICAgICAgZXh0cmFfcHJlYXJncz1Ob25lLAogICAgICAgICAgICAg IGV4dHJhX3Bvc3RhcmdzPU5vbmUsCiAgICAgICAgICAgICAgYnVpbGRfdGVtcD1Ob25lKToK ICAgICAgICAjIEZpcnN0IGV4YW1pbmUgYSBjb3VwbGUgb2Ygb3B0aW9ucyBmb3IgdGhpbmdz IHRoYXQgYXJlbid0IGltcGxlbWVudGVkIHlldAogICAgICAgIGlmIG5vdCB0YXJnZXRfZGVz YyBpbiAoc2VsZi5TSEFSRURfTElCUkFSWSwgc2VsZi5TSEFSRURfT0JKRUNUKToKICAgICAg ICAgICAgcmFpc2UgRGlzdHV0aWxzUGxhdGZvcm1FcnJvciwgJ0NhbiBvbmx5IG1ha2UgU0hB UkVEX0xJQlJBUlkgb3IgU0hBUkVEX09CSkVDVCB0YXJnZXRzIG9uIHRoZSBNYWMnCiAgICAg ICAgaWYgcnVudGltZV9saWJyYXJ5X2RpcnM6CiAgICAgICAgICAgIHJhaXNlIERpc3R1dGls c1BsYXRmb3JtRXJyb3IsICdSdW50aW1lIGxpYnJhcnkgZGlycyBub3QgaW1wbGVtZW50ZWQg eWV0JwogICAgICAgIGlmIGV4dHJhX3ByZWFyZ3Mgb3IgZXh0cmFfcG9zdGFyZ3M6CiAgICAg ICAgICAgIHJhaXNlIERpc3R1dGlsc1BsYXRmb3JtRXJyb3IsICdSdW50aW1lIGxpYnJhcnkg ZGlycyBub3QgaW1wbGVtZW50ZWQgeWV0JwogICAgICAgIGlmIGxlbihleHBvcnRfc3ltYm9s cykgIT0gMToKICAgICAgICAgICAgcmFpc2UgRGlzdHV0aWxzUGxhdGZvcm1FcnJvciwgJ05l ZWQgZXhhY3RseSBvbmUgZXhwb3J0IHN5bWJvbCcKICAgICAgICAjIE5leHQgdGhlcmUgYXJl IHZhcmlvdXMgdGhpbmdzIGZvciB3aGljaCB3ZSBuZWVkIGFic29sdXRlIHBhdGhuYW1lcy4K ICAgICAgICAjIFRoaXMgaXMgYmVjYXVzZSB3ZSAodXN1YWxseSkgY3JlYXRlIHRoZSBwcm9q ZWN0IGluIGEgc3ViZGlyZWN0b3J5IG9mCiAgICAgICAgIyB3aGVyZSB3ZSBhcmUgbm93LCBh bmQga2VlcGluZyB0aGUgcGF0aHMgcmVsYXRpdmUgaXMgdG9vIG11Y2ggd29yayByaWdodAog ICAgICAgICMgbm93LgogICAgICAgIHNvdXJjZXMgPSBtYXAoc2VsZi5fZmlsZW5hbWVfdG9f YWJzLCBzZWxmLl9fc291cmNlcykKICAgICAgICBpbmNsdWRlX2RpcnMgPSBtYXAoc2VsZi5f ZmlsZW5hbWVfdG9fYWJzLCBzZWxmLl9faW5jbHVkZV9kaXJzKQogICAgICAgIGlmIG9iamVj dHM6CiAgICAgICAgICAgIG9iamVjdHMgPSBtYXAoc2VsZi5fZmlsZW5hbWVfdG9fYWJzLCBv YmplY3RzKQogICAgICAgIGVsc2U6CiAgICAgICAgICAgIG9iamVjdHMgPSBbXQogICAgICAg IGlmIGJ1aWxkX3RlbXA6CiAgICAgICAgICAgIGJ1aWxkX3RlbXAgPSBzZWxmLl9maWxlbmFt ZV90b19hYnMoYnVpbGRfdGVtcCkKICAgICAgICBlbHNlOgogICAgICAgICAgICBidWlsZF90 ZW1wID0gb3MuY3VyZGlyKCkKICAgICAgICBpZiBvdXRwdXRfZGlyOgogICAgICAgICAgICBv dXRwdXRfZmlsZW5hbWUgPSBvcy5wYXRoLmpvaW4ob3V0cHV0X2Rpciwgb3V0cHV0X2ZpbGVu YW1lKQogICAgICAgICMgVGhlIG91dHB1dCBmaWxlbmFtZSBuZWVkcyBzcGVjaWFsIGhhbmRs aW5nOiBzcGxpdHRpbmcgaXQgaW50byBkaXIgYW5kCiAgICAgICAgIyBmaWxlbmFtZSBwYXJ0 LiBBY3R1YWxseSBJJ20gbm90IHN1cmUgdGhpcyBpcyByZWFsbHkgbmVlZGVkLCBidXQgaXQK ICAgICAgICAjIGNhbid0IGh1cnQuCiAgICAgICAgb3V0cHV0X2ZpbGVuYW1lID0gc2VsZi5f ZmlsZW5hbWVfdG9fYWJzKG91dHB1dF9maWxlbmFtZSkKICAgICAgICBvdXRwdXRfZGlyLCBv dXRwdXRfZmlsZW5hbWUgPSBvcy5wYXRoLnNwbGl0KG91dHB1dF9maWxlbmFtZSkKICAgICAg ICAjIE5vdyB3ZSBuZWVkIHRoZSBzaG9ydCBuYW1lcyBvZiBhIGNvdXBsZSBvZiB0aGluZ3Mg Zm9yIHB1dHRpbmcgdGhlbQogICAgICAgICMgaW50byB0aGUgcHJvamVjdC4KICAgICAgICBp ZiBvdXRwdXRfZmlsZW5hbWVbLTg6XSA9PSAnLnBwYy5zbGInOgogICAgICAgICAgICBiYXNl bmFtZSA9IG91dHB1dF9maWxlbmFtZVs6LThdCiAgICAgICAgZWxzZToKICAgICAgICAgICAg YmFzZW5hbWUgPSBvcy5wYXRoLnN0cmlwKG91dHB1dF9maWxlbmFtZSlbMF0KICAgICAgICBw cm9qZWN0bmFtZSA9IGJhc2VuYW1lICsgJy5tY3AnCiAgICAgICAgdGFyZ2V0bmFtZSA9IGJh c2VuYW1lCiAgICAgICAgeG1sbmFtZSA9IGJhc2VuYW1lICsgJy54bWwnCiAgICAgICAgZXhw b3J0bmFtZSA9IGJhc2VuYW1lICsgJy5tY3AuZXhwJwogICAgICAgIHByZWZpeG5hbWUgPSAn bXdlcmtzXyVzX2NvbmZpZy5oJyViYXNlbmFtZQogICAgICAgICMgQ3JlYXRlIHRoZSBkaXJl Y3RvcmllcyB3ZSBuZWVkCiAgICAgICAgZGlzdHV0aWxzLmRpcl91dGlsLm1rcGF0aChidWls ZF90ZW1wLCBzZWxmLnZlcmJvc2UsIHNlbGYuZHJ5X3J1bikKICAgICAgICBkaXN0dXRpbHMu ZGlyX3V0aWwubWtwYXRoKG91dHB1dF9kaXIsIHNlbGYudmVyYm9zZSwgc2VsZi5kcnlfcnVu KQogICAgICAgICMgQW5kIG9uIHRvIGZpbGxpbmcgaW4gdGhlIHBhcmFtZXRlcnMgZm9yIHRo ZSBwcm9qZWN0IGJ1aWxkZXIKICAgICAgICBzZXR0aW5ncyA9IHt9CiAgICAgICAgc2V0dGlu Z3NbJ21hY19leHBvcnRuYW1lJ10gPSBleHBvcnRuYW1lCiAgICAgICAgc2V0dGluZ3NbJ21h Y19vdXRwdXRkaXInXSA9IG91dHB1dF9kaXIKICAgICAgICBzZXR0aW5nc1snbWFjX2RsbG5h bWUnXSA9IG91dHB1dF9maWxlbmFtZQogICAgICAgIHNldHRpbmdzWydtYWNfdGFyZ2V0bmFt ZSddID0gdGFyZ2V0bmFtZQogICAgICAgIHNldHRpbmdzWydzeXNwcmVmaXgnXSA9IHN5cy5w cmVmaXgKICAgICAgICBzZXR0aW5nc1snbWFjX3N5c3ByZWZpeHR5cGUnXSA9ICdBYnNvbHV0 ZScKICAgICAgICBzb3VyY2VmaWxlbmFtZXMgPSBbXQogICAgICAgIHNvdXJjZWZpbGVkaXJz ID0gW10KICAgICAgICBmb3IgZmlsZW5hbWUgaW4gc291cmNlcyArIG9iamVjdHM6CiAgICAg ICAgICAgIGRpcm5hbWUsIGZpbGVuYW1lID0gb3MucGF0aC5zcGxpdChmaWxlbmFtZSkKICAg ICAgICAgICAgc291cmNlZmlsZW5hbWVzLmFwcGVuZChmaWxlbmFtZSkKICAgICAgICAgICAg aWYgbm90IGRpcm5hbWUgaW4gc291cmNlZmlsZWRpcnM6CiAgICAgICAgICAgICAgICBzb3Vy Y2VmaWxlZGlycy5hcHBlbmQoZGlybmFtZSkKICAgICAgICBzZXR0aW5nc1snc291cmNlcydd ID0gc291cmNlZmlsZW5hbWVzCiAgICAgICAgc2V0dGluZ3NbJ2V4dHJhc2VhcmNoZGlycydd ID0gc291cmNlZmlsZWRpcnMgKyBpbmNsdWRlX2RpcnMgKyBsaWJyYXJ5X2RpcnMKICAgICAg ICBpZiBzZWxmLmRyeV9ydW46CiAgICAgICAgICAgIHByaW50ICdDQUxMSU5HIExJTktFUiBJ TicsIG9zLmdldGN3ZCgpCiAgICAgICAgICAgIGZvciBrZXksIHZhbHVlIGluIHNldHRpbmdz Lml0ZW1zKCk6CiAgICAgICAgICAgICAgICBwcmludCAnJTIwLjIwcyAlcyclKGtleSwgdmFs dWUpCiAgICAgICAgICAgIHJldHVybgogICAgICAgICMgQnVpbGQgdGhlIGV4cG9ydCBmaWxl CiAgICAgICAgZXhwb3J0ZmlsZW5hbWUgPSBvcy5wYXRoLmpvaW4oYnVpbGRfdGVtcCwgZXhw b3J0bmFtZSkKICAgICAgICBpZiBzZWxmLnZlcmJvc2U6CiAgICAgICAgICAgIHByaW50ICdc dENyZWF0ZSBleHBvcnQgZmlsZScsIGV4cG9ydGZpbGVuYW1lCiAgICAgICAgZnAgPSBvcGVu KGV4cG9ydGZpbGVuYW1lLCAndycpCiAgICAgICAgZnAud3JpdGUoJyVzXG4nJWV4cG9ydF9z eW1ib2xzWzBdKQogICAgICAgIGZwLmNsb3NlKCkKICAgICAgICAjIEdlbmVyYXRlIHRoZSBw cmVmaXggZmlsZSwgaWYgbmVlZGVkLCBhbmQgcHV0IGl0IGluIHRoZSBzZXR0aW5ncwogICAg ICAgIGlmIHNlbGYuX19tYWNyb3M6CiAgICAgICAgICAgIHByZWZpeGZpbGVuYW1lID0gb3Mu cGF0aC5qb2luKG9zLmdldGN3ZCgpLCBvcy5wYXRoLmpvaW4oYnVpbGRfdGVtcCwgcHJlZml4 bmFtZSkpCiAgICAgICAgICAgIGZwID0gb3BlbihwcmVmaXhmaWxlbmFtZSwgJ3cnKQogICAg ICAgICAgICBmcC53cml0ZSgnI2luY2x1ZGUgIm13ZXJrc19wbHVnaW5fY29uZmlnLmgiXG4n KQogICAgICAgICAgICBmb3IgbmFtZSwgdmFsdWUgaW4gc2VsZi5fX21hY3JvczoKICAgICAg ICAgICAgICAgIGlmIHZhbHVlIGlzIE5vbmU6CiAgICAgICAgICAgICAgICAgICAgZnAud3Jp dGUoJyNkZWZpbmUgJXNcbiclbmFtZSkKICAgICAgICAgICAgICAgIGVsc2U6CiAgICAgICAg ICAgICAgICAgICAgZnAud3JpdGUoJyNkZWZpbmUgJXMgIiVzIlxuJyUobmFtZSwgdmFsdWUp KQogICAgICAgICAgICBmcC5jbG9zZSgpCiAgICAgICAgICAgIHNldHRpbmdzWydwcmVmaXhu YW1lJ10gPSBwcmVmaXhuYW1lCgogICAgICAgICMgQnVpbGQgdGhlIFhNTCBmaWxlLiBXZSBu ZWVkIHRoZSBmdWxsIHBhdGhuYW1lIChvbmx5IGxhdGVyb24sIHJlYWxseSkKICAgICAgICAj IGJlY2F1c2Ugd2UgcGFzcyB0aGlzIHBhdGhuYW1lIHRvIENvZGVXYXJyaW9yIGluIGFuIEFw cGxlRXZlbnQsIGFuZCBDVwogICAgICAgICMgZG9lc24ndCBoYXZlIGEgY2x1ZSBhYm91dCBv dXIgd29ya2luZyBkaXJlY3RvcnkuCiAgICAgICAgeG1sZmlsZW5hbWUgPSBvcy5wYXRoLmpv aW4ob3MuZ2V0Y3dkKCksIG9zLnBhdGguam9pbihidWlsZF90ZW1wLCB4bWxuYW1lKSkKICAg ICAgICBpZiBzZWxmLnZlcmJvc2U6CiAgICAgICAgICAgIHByaW50ICdcdENyZWF0ZSBYTUwg ZmlsZScsIHhtbGZpbGVuYW1lCiAgICAgICAgeG1sYnVpbGRlciA9IG1rY3dwcm9qZWN0LmN3 eG1sZ2VuLlByb2plY3RCdWlsZGVyKHNldHRpbmdzKQogICAgICAgIHhtbGJ1aWxkZXIuZ2Vu ZXJhdGUoKQogICAgICAgIHhtbGRhdGEgPSBzZXR0aW5nc1sndG1wX3Byb2plY3R4bWxkYXRh J10KICAgICAgICBmcCA9IG9wZW4oeG1sZmlsZW5hbWUsICd3JykKICAgICAgICBmcC53cml0 ZSh4bWxkYXRhKQogICAgICAgIGZwLmNsb3NlKCkKICAgICAgICAjIEdlbmVyYXRlIHRoZSBw cm9qZWN0LiBBZ2FpbiBhIGZ1bGwgcGF0aG5hbWUuCiAgICAgICAgcHJvamVjdGZpbGVuYW1l ID0gb3MucGF0aC5qb2luKG9zLmdldGN3ZCgpLCBvcy5wYXRoLmpvaW4oYnVpbGRfdGVtcCwg cHJvamVjdG5hbWUpKQogICAgICAgIGlmIHNlbGYudmVyYm9zZToKICAgICAgICAgICAgcHJp bnQgJ1x0Q3JlYXRlIHByb2plY3QgZmlsZScsIHByb2plY3RmaWxlbmFtZQogICAgICAgIG1r Y3dwcm9qZWN0Lm1ha2Vwcm9qZWN0KHhtbGZpbGVuYW1lLCBwcm9qZWN0ZmlsZW5hbWUpCiAg ICAgICAgIyBBbmQgYnVpbGQgaXQKICAgICAgICBpZiBzZWxmLnZlcmJvc2U6CiAgICAgICAg ICAgIHByaW50ICdcdEJ1aWxkIHByb2plY3QnCiAgICAgICAgbWtjd3Byb2plY3QuYnVpbGRw cm9qZWN0KHByb2plY3RmaWxlbmFtZSkKICAgICAgICAKICAgIGRlZiBfZmlsZW5hbWVfdG9f YWJzKHNlbGYsIGZpbGVuYW1lKToKICAgICAgICAjIFNvbWUgZmlsZW5hbWVzIHNlZW0gdG8g YmUgdW5peC1saWtlLiBDb252ZXJ0IHRvIE1hYyBuYW1lcy4KIyMgICAgICAgIGlmICcvJyBp biBmaWxlbmFtZSBhbmQgJzonIGluIGZpbGVuYW1lOgojIyAgICAgICAgICAgcmFpc2UgRGlz dHV0aWxzUGxhdGZvcm1FcnJvciwgJ0ZpbGVuYW1lIG1heSBiZSBVbml4IG9yIE1hYyBzdHls ZTogJXMnJWZpbGVuYW1lCiMjICAgICAgICBpZiAnLycgaW4gZmlsZW5hbWU6CiMjICAgICAg ICAgICBmaWxlbmFtZSA9IG1hY3VybDJwYXRoKGZpbGVuYW1lKQogICAgICAgIGZpbGVuYW1l ID0gZGlzdHV0aWxzLnV0aWwuY29udmVydF9wYXRoKGZpbGVuYW1lKQogICAgICAgIGlmIG5v dCBvcy5wYXRoLmlzYWJzKGZpbGVuYW1lKToKICAgICAgICAgICBjdXJkaXIgPSBvcy5nZXRj d2QoKQogICAgICAgICAgIGZpbGVuYW1lID0gb3MucGF0aC5qb2luKGN1cmRpciwgZmlsZW5h bWUpCiAgICAgICAgcmV0dXJuIGZpbGVuYW1lCiAgICAgICAgCiAgICAgICAgCg== --==_Exmh_11048233920-- From hoel@germanlloyd.org Tue Nov 21 08:34:02 2000 From: hoel@germanlloyd.org (Berthold =?iso-8859-1?q?H=F6llmann?=) Date: Tue Nov 21 08:34:02 2000 Subject: [Distutils] distutil or setup problem? Message-ID: Hello, Trying to use distutils 1.0.1 to build an extension module and an accompanying library I have some problems. First, when I call > python setup.py build I get cg error (as) : cannot open output file "build/temp.solaris-2.7-sun4u-1.5/../mtxobj_spooles.o" under solaris and a similar message under WIN32. My library files are in the parent directory to the directory where setup.py is. So in the definitions for the library build i use "../mtxobj_spooles.c" which leads distutils not to generate the "build/temp.*" directory. But this is a minor problem compared to my second problem. I can't belive it is a general distutils problem, but have no clue what else can be wrong. After having made "build/temp.win32-1.5" by hand, compiling the windows version fails with "unresolved external symbol" errors like these: spsolve.obj : error LNK2001: unresolved external symbol _PyErr_SetFromErrno spsolve.obj : error LNK2001: unresolved external symbol _PyCObject_FromVoidPtr spsolve.obj : error LNK2001: unresolved external symbol _PyArg_ParseTuple spsolve.obj : error LNK2001: unresolved external symbol _PyCObject_AsVoidPtr spsolve.obj : error LNK2001: unresolved external symbol _PyErr_SetString spsolve.obj : error LNK2001: unresolved external symbol __imp__PyExc_TypeError spsolve.obj : error LNK2001: unresolved external symbol __imp__PyCObject_Type spsolve.obj : error LNK2001: unresolved external symbol _Py_BuildValue spsolve.obj : error LNK2001: unresolved external symbol __imp__PyExc_ValueError spsolve.obj : error LNK2001: unresolved external symbol __imp___Py_NoneStruct spsolve.obj : error LNK2001: unresolved external symbol _PyDict_GetItemString spsolve.obj : error LNK2001: unresolved external symbol _PyModule_GetDict spsolve.obj : error LNK2001: unresolved external symbol _PyImport_ImportModule spsolve.obj : error LNK2001: unresolved external symbol _Py_InitModule4 now that seems strange to me though i thought the distutils take care to link python15.lib to avoid these error messages. Could that be a configuration problem on my side or is this a 1.0.1 bug? Greetings Berthold -- email: hoel@GermanLloyd.org ) tel. : +49 (40) 3 61 49 - 73 74 ( C[_] These opinions might be mine, but never those of my employer. From thomas.heller@ion-tof.com Tue Nov 21 09:50:01 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue Nov 21 09:50:01 2000 Subject: [Distutils] distutil or setup problem? References: Message-ID: <02fb01c053ca$4bc7d320$e000a8c0@thomasnotebook> > Hello, > > Trying to use distutils 1.0.1 to build an extension module and an > accompanying library I have some problems. First, when I call > > > python setup.py build > > I get > > cg error (as) : cannot open output file "build/temp.solaris-2.7-sun4u-1.5/../mtxobj_spooles.o" > > under solaris and a similar message under WIN32. My library files are > in the parent directory to the directory where setup.py is. So in the > definitions for the library build i use "../mtxobj_spooles.c" which > leads distutils not to generate the "build/temp.*" directory. > > But this is a minor problem compared to my second problem. I can't > belive it is a general distutils problem, but have no clue what else > can be wrong. After having made "build/temp.win32-1.5" by hand, > compiling the windows version fails with "unresolved external symbol" > errors like these: > > spsolve.obj : error LNK2001: unresolved external symbol _PyErr_SetFromErrno > spsolve.obj : error LNK2001: unresolved external symbol _PyCObject_FromVoidPtr > spsolve.obj : error LNK2001: unresolved external symbol _PyArg_ParseTuple > spsolve.obj : error LNK2001: unresolved external symbol _PyCObject_AsVoidPtr > spsolve.obj : error LNK2001: unresolved external symbol _PyErr_SetString > spsolve.obj : error LNK2001: unresolved external symbol __imp__PyExc_TypeError > spsolve.obj : error LNK2001: unresolved external symbol __imp__PyCObject_Type > spsolve.obj : error LNK2001: unresolved external symbol _Py_BuildValue > spsolve.obj : error LNK2001: unresolved external symbol __imp__PyExc_ValueError > spsolve.obj : error LNK2001: unresolved external symbol __imp___Py_NoneStruct > spsolve.obj : error LNK2001: unresolved external symbol _PyDict_GetItemString > spsolve.obj : error LNK2001: unresolved external symbol _PyModule_GetDict > spsolve.obj : error LNK2001: unresolved external symbol _PyImport_ImportModule > spsolve.obj : error LNK2001: unresolved external symbol _Py_InitModule4 > > now that seems strange to me though i thought the distutils take care > to link python15.lib to avoid these error messages. Could that be a > configuration problem on my side or is this a 1.0.1 bug? Can you post or send the output of 'python setup.py build' ? Thomas From hoel@germanlloyd.org Tue Nov 21 09:59:01 2000 From: hoel@germanlloyd.org (Berthold =?iso-8859-1?q?H=F6llmann?=) Date: Tue Nov 21 09:59:01 2000 Subject: [Distutils] distutil or setup problem? In-Reply-To: "Thomas Heller"'s message of "Tue, 21 Nov 2000 15:49:45 +0100" References: <02fb01c053ca$4bc7d320$e000a8c0@thomasnotebook> Message-ID: "Thomas Heller" writes: > > Can you post or send the output of 'python setup.py build' ? Here the comes the requested: C:\hoel\solver\python>python C:\hoel\solver\python\setup.py build running build running build_clib building 'mtxobj' library C:\Programme\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD /W3 /GX -I.. -If:/data/fbf/fi/devel/include -If:/data/fbf/fi/devel/include/pthreads -If:/data/fbf/fi/devel/include/spooles /Tc../mtxobj_spooles.c /Fobuild\temp.win32-1.5\../mtxobj_spooles.obj mtxobj_spooles.c C:\Programme\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD /W3 /GX -I.. -If:/data/fbf/fi/devel/include -If:/data/fbf/fi/devel/include/pthreads -If:/data/fbf/fi/devel/include/spooles /Tc../mtxfile_mtxobj.c /Fobuild\temp.win32-1.5\../mtxfile_mtxobj.obj mtxfile_mtxobj.c C:\Programme\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD /W3 /GX -I.. -If:/data/fbf/fi/devel/include -If:/data/fbf/fi/devel/include/pthreads -If:/data/fbf/fi/devel/include/spooles /Tc../mtxPobj_spooles.c /Fobuild\temp.win32-1.5\../mtxPobj_spooles.obj mtxPobj_spooles.c ../mtxPobj_spooles.c(177) : warning C4101: 'ierr' : unreferenced local variable ../mtxPobj_spooles.c(176) : warning C4101: 'max_row' : unreferenced local variable ../mtxPobj_spooles.c(176) : warning C4101: 'min_row' : unreferenced local variable C:\Programme\Microsoft Visual Studio\VC98\BIN\lib.exe build\temp.win32-1.5\../mtxobj_spooles.obj build\temp.win32-1.5\../mtxfile_mtxobj.obj build\temp.win32-1.5\../mtxPobj_spooles.obj /OUT:build\temp.win32-1.5\mtxobj.lib Microsoft (R) Library Manager Version 6.00.8168 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. running build_ext building '_spsolve' extension creating build\temp.win32-1.5\Release C:\Programme\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD /W3 /GX -DVISUAL_CPLUSPLUS -DDebug -If:\data\fbf\fi\devel\include -IG:\bin\Python\include\python1.5/Numeric -Ic:\devl\include -IG:\bin\Python\Include /Tcspsolve.c /Fobuild\temp.win32-1.5\Release\spsolve.obj spsolve.c spsolve.c(232) : warning C4013: 'mtxPobj_symbFacPermute' undefined; assuming extern returning int spsolve.c(259) : warning C4013: 'mtxPobj_numFac' undefined; assuming extern returning int spsolve.c(305) : warning C4018: '!=' : signed/unsigned mismatch spsolve.c(369) : warning C4018: '!=' : signed/unsigned mismatch spsolve.c(392) : warning C4018: '!=' : signed/unsigned mismatch spsolve.c(347) : warning C4101: 'tmp' : unreferenced local variable spsolve.c(468) : warning C4018: '!=' : signed/unsigned mismatch spsolve.c(472) : warning C4018: '!=' : signed/unsigned mismatch spsolve.c(426) : warning C4101: 'Pobj' : unreferenced local variable spsolve.c(427) : warning C4101: 'tmp' : unreferenced local variable spsolve.c(519) : warning C4101: 'd' : unreferenced local variable creating build\lib.win32-1.5 C:\Programme\Microsoft Visual Studio\VC98\BIN\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:c:\devl\bin /LIBPATH:f:\data\fbf\fi\devel\lib /LIBPATH:lib /LIBPATH:G:\bin\Python\libs /LIBPATH:build\temp.win32-1.5 mtxfile.lib spooles.lib cvwmpi.lib mtxobj.lib /EXPORT:init_spsolve build\temp.win32-1.5\Release\spsolve.obj /OUT:build\lib.win32-1.5\_spsolve.pyd /IMPLIB:build\temp.win32-1.5\Release\_spsolve.lib /nodefaultlib:libc spooles.lib(dll.obj) : error LNK2005: _DllMain@12 already defined in MSVCRT.lib(dllmain.obj) spooles.lib(dll.obj) : warning LNK4006: _DllMain@12 already defined in MSVCRT.lib(dllmain.obj); second definition ignored Creating library build\temp.win32-1.5\Release\_spsolve.lib and object build\temp.win32-1.5\Release\_spsolve.exp spsolve.obj : error LNK2001: unresolved external symbol _PyErr_SetFromErrno spsolve.obj : error LNK2001: unresolved external symbol _PyCObject_FromVoidPtr spsolve.obj : error LNK2001: unresolved external symbol _PyArg_ParseTuple spsolve.obj : error LNK2001: unresolved external symbol _PyCObject_AsVoidPtr spsolve.obj : error LNK2001: unresolved external symbol _PyErr_SetString spsolve.obj : error LNK2001: unresolved external symbol __imp__PyExc_TypeError spsolve.obj : error LNK2001: unresolved external symbol __imp__PyCObject_Type spsolve.obj : error LNK2001: unresolved external symbol _Py_BuildValue spsolve.obj : error LNK2001: unresolved external symbol __imp__PyExc_ValueError spsolve.obj : error LNK2001: unresolved external symbol __imp___Py_NoneStruct spsolve.obj : error LNK2001: unresolved external symbol _PyDict_GetItemString spsolve.obj : error LNK2001: unresolved external symbol _PyModule_GetDict spsolve.obj : error LNK2001: unresolved external symbol _PyImport_ImportModule spsolve.obj : error LNK2001: unresolved external symbol _Py_InitModule4 ... build\lib.win32-1.5\_spsolve.pyd : fatal error LNK1120: 31 unresolved externals error: command '"C:\Programme\Microsoft Visual Studio\VC98\BIN\link.exe"' failed with exit status 1120 C:\hoel\solver\python> -- email: hoel@GermanLloyd.org ) tel. : +49 (40) 3 61 49 - 73 74 ( C[_] These opinions might be mine, but never those of my employer. From paulp@ActiveState.com Wed Nov 22 18:27:01 2000 From: paulp@ActiveState.com (Paul Prescod) Date: Wed Nov 22 18:27:01 2000 Subject: [Distutils] Installation questions Message-ID: <3A1C56CA.91CF4364@activestate.com> I'm a distutils newbie so I'm just trying to find my way around. I notice that even though (e.g.) numpy is built using distutils, the windows binary zipfile does not come with a setup.py for installation. The setup is pretty brain-dead (just unzip to a particular location) but I'm thinking of a future where Python binaries on a particular platform have a known structure so that they can be installed in a generic way. In other words, I'd like it to be more brain-dead: more like an RPM or MSI where the internal binary distribution structure is well-known. I tried to implement this for a few packages as an experiment (first not using distutils, and then using distutils). I decided that all of the packages would have a top-level "install.py". I was writing small tools to find the Python lib directory, copy the files and so forth but then I realized that I was duplicating some of the work of distutils (which does have an install option, after all). So then I started to use distutils and the "setup.py" convention. The structure of my modules is /foo/__init__.py /foo/bar/__init__.py /foo/bar/something.pyd Installing the ".py"s is easy because of "packages=". But distutils misses the .pyd. Is it doing the right thing? Or should it blindly copy .pyd's as part of a package. Also, is distutil install supposed to do anything with documentation? It would be nice if there were a standard place for Python module documentation. Paul From thomas.heller@ion-tof.com Thu Nov 23 02:45:01 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Nov 23 02:45:01 2000 Subject: [Distutils] Installation questions References: <3A1C56CA.91CF4364@activestate.com> Message-ID: <008901c05521$35a71d00$e000a8c0@thomasnotebook> > I'm a distutils newbie so I'm just trying to find my way around. > > I notice that even though (e.g.) numpy is built using distutils, the > windows binary zipfile does not come with a setup.py for installation. > The setup is pretty brain-dead (just unzip to a particular location) but > I'm thinking of a future where Python binaries on a particular platform > have a known structure so that they can be installed in a generic way. > In other words, I'd like it to be more brain-dead: more like an RPM or > MSI where the internal binary distribution structure is well-known. Have you tried the bdist_wininst command? 'python setup.py bdist_wininst' or 'python setup.py bdist --formats=wininst' should do exactly what you are asking for. Thomas From Alexandre.Fayolle@logilab.fr Tue Nov 28 13:14:01 2000 From: Alexandre.Fayolle@logilab.fr (Alexandre Fayolle) Date: Tue Nov 28 13:14:01 2000 Subject: [Distutils] problem with bdist_rpm --doc-files Message-ID: Hello, I could not find the answer in the archive (but them being non searchable makes this difficult...). I'm trying to build a rpm package using distutils 1.0.1 on a redahat 6.2 box (python 1.5.2). I have a script that should go in site-packages, a utility library called lib (maybe not the best choice, I've told the author), and some documentation in 3 directories (doc, dtd anx examples). My setup.py looks like: #!/usr/bin/env python from distutils.core import setup setup(name="pygantt", version= "0.6.0", description = "generates Gantt diagrams from XML specification", author = "Nicolas Chauvat", author_email="Nicolas.Chauvat@logilab.fr", url = "http://www.logilab.org/pygantt", #package_dir = {'':'.'}, #packages = ['lib'], py_modules = ['pygantt','lib.HTMLRenderer','lib.Task','lib.common'], ) and the setup.cfg file is: [bdist_rpm] doc_files = doc/TODO doc/index.html dtd/project.dtd examples/project.html examples/project.dtd packager = Alexandre Fayolle Now, when I run setup.py bdist_rpm, this is what I get: python setup.py bdist_rpm running bdist_rpm creating build creating build/bdist.linux-i686 creating build/bdist.linux-i686/rpm creating build/bdist.linux-i686/rpm/SOURCES creating build/bdist.linux-i686/rpm/SPECS creating build/bdist.linux-i686/rpm/BUILD creating build/bdist.linux-i686/rpm/RPMS creating build/bdist.linux-i686/rpm/SRPMS writing 'build/bdist.linux-i686/rpm/SPECS/pygantt.spec' running sdist warning: sdist: manifest template 'MANIFEST.in' does not exist (using default fi le list) warning: sdist: standard file not found: should have one of README, README.txt writing manifest file 'MANIFEST' creating pygantt-0.6.0 creating pygantt-0.6.0/lib making hard links in pygantt-0.6.0... hard linking pygantt.py -> pygantt-0.6.0 hard linking setup.cfg -> pygantt-0.6.0 hard linking setup.py -> pygantt-0.6.0 hard linking lib/HTMLRenderer.py -> pygantt-0.6.0/lib hard linking lib/Task.py -> pygantt-0.6.0/lib hard linking lib/__init__.py -> pygantt-0.6.0/lib hard linking lib/common.py -> pygantt-0.6.0/lib creating dist tar -cf dist/pygantt-0.6.0.tar pygantt-0.6.0 gzip -f9 dist/pygantt-0.6.0.tar removing 'pygantt-0.6.0' (and everything under it) copying dist/pygantt-0.6.0.tar.gz -> build/bdist.linux-i686/rpm/SOURCES building RPMs Processing files: pygantt-0.6.0-1 Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.33791 + umask 022 + cd /home/alf/pygantt/build/bdist.linux-i686/rpm/BUILD + cd pygantt-0.6.0 + DOCDIR=/var/tmp/pygantt-buildroot/usr/doc/pygantt-0.6.0 + export DOCDIR + rm -rf /var/tmp/pygantt-buildroot/usr/doc/pygantt-0.6.0 + /bin/mkdir -p /var/tmp/pygantt-buildroot/usr/doc/pygantt-0.6.0 + cp -pr doc/TODO doc/index.html dtd/project.dtd examples/project.html examples/ project.dtd /var/tmp/pygantt-buildroot/usr/doc/pygantt-0.6.0 cp: doc/TODO: No such file or directory cp: doc/index.html: No such file or directory cp: dtd/project.dtd: No such file or directory cp: examples/project.html: No such file or directory cp: examples/project.dtd: No such file or directory Bad exit status from /var/tmp/rpm-tmp.33791 (%doc) What am I missing? Is it forbidden to put subdirectories in --doc-files? Thanks for your support. Alexandre Fayolle -- http://www.logilab.com Narval is the first software agent available as free software (GPL). LOGILAB, Paris (France). From cm@bldigital.com Wed Nov 29 08:20:01 2000 From: cm@bldigital.com (Ben Allfree) Date: Wed Nov 29 08:20:01 2000 Subject: [Distutils] PureMingw32CCompiler (cygwinccompiler.py addition) Message-ID: <3A250266.B431D941@bldigital.com> This is a multi-part message in MIME format. --------------437FC20D6156B791E5FEAA83 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all, I just discovered the fantastic work done for abstract compilers. What great stuff! I downloaded the CVS snapshot today and added a PureMingw32CCompiler class to show the correct command line to build DLLs and import libraries for MinGW32 2.95.2-1 (the current beta). Maybe somebody could see how to better integrate the changes? Included in my attachment is the changed distutils/cygwinccompiler.py and some test programs. The test programs came from the MinGW32 instructions at: ftp://ftp.nanotech.wisc.edu/pub/khan/gnu-win32/mingw32/snapshots/gcc-2.95.2-1/README For those that do not know, the current MinGW32 beta supports the `-shared' directive and an `--out-implib,libxxx.a' directive. DEF files are no longer needed when building DLLs from object files. As far as I know, we still have to use `dlltool' to build import libraries from DEF files when the DLL's object files are not available. But, I'm not even sure that's supposed to be a compiler function. Take care, Ben Allfree --------------437FC20D6156B791E5FEAA83 Content-Type: application/x-zip-compressed; name="PureMingw32CCompiler.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="PureMingw32CCompiler.zip" UEsDBBQAAAAIALm6fClLWUv0PwAAAEMAAAAKAAAAZGxsaGVsbG8uY1POzEvOKU1JVVBKyclJ Sy7Ry1Di4srMK1HITczMU9DQ5KrmUlBQKCkuSSvNSwbyrUHcotSS0iKgrAGQW8sFAFBLAwQU AAAACACQunwp7LPzF4MAAADOAAAACAAAAGRsbGZjdC5ojc2xCsIwEMbxPU9xkKWd8gBuUgch oIiCW8DeFwzEpDSn9PFtiN0dD37/73TwDE/729EObrBWGUPyBHGMhGXKsxSlVxES6HA/ny5X co4xxjJh7FbVUK80YsFWYwGF1x91Q7VOHLyqvX+nUUJOJJke2wzYtEdg9Rv65MAkRaqnrl79 7gtQSwMEFAAAAAgArbp8KVNkU0JWAAAAXQAAAAgAAABkbGxmY3QuY1POzEvOKU1JVbApLknJ zNfLsONShgkppeTkpCWX6GUocXG5RgT4B4UolOVnpiiUFJekleYlK2iAeJpc1VwKCgoFRZl5 JWkKGkoeqTk5+TF5SprWXLUAUEsDBBQAAAAIAL1AfSkP+Hyg0hUAACFNAAASAAAAY3lnd2lu Y2NvbXBpbGVyLnB57Tz7k9s2c7/rr0B4n4eUj+Q96jRfrrmk9sVx3MR2xo8mnbNHpUhIYo4i OQRpWf3ru7t4ECCp8zlOv7Yz4fghEcBise9dAPI8L8tF27V5IeJ0v97lZZpW2zoveDOb/dJU 7/OMC9ZuOLui1qsr1crSIhEiZAkT3ZI+s2rF3pT5h75Lu0na2SYps8KBweqqabE3vnry/A27 YqkZUrFf8zKrdiJm7GnLkkJU0Fq2SV6KGQ54lpfr3T+dDxBhu02ebpg92VZ2NLM9ubpigUi2 nCViJtfK4E9ZRerLtsr4PJ55njebHbG6qZYF34qL2RF8u8/yFdtXHesEjGdb8T7VSGes3reb qmTveSNy+D84i7+Mz+cwirGzmEZtkvcc1waL4IBNwhYLWPjVYsEET1schMi0Ape6ytfxhgaf u4PXvORN0uL8+ZZWVeTLJmn2bFU1NDorChoIT8TShsvOGV9FK0CUuklcv/sunu47ANwJIKLu ph4Y2FZVwaIIPpVITwnz7EuEia/5ynoFX94OIPRPFFVdW3dtBBPipGZYQlRnQB4uZWDTtvXF yYlok0Zs8jqWPeOStyeA/O7khjdlc6J4fvK8armIN+22UNz7FbDsWsY/4PIWYr9dVoVAovfk AVkuM5ZVpd8Sl2n+KJJDoqQoIj1sydMEe+QtdOcCB+yq5gYkoeFFnoDYIGRRbTnBAFRaaJOs 7YCDwG8Q74cwm4ZUgcA2bCcl32iDoKUTjJIDBOiUN0xjIWqe5quc3ucC5BiI1eRVJ7ToxrT2 ydkvCChRRgn/Ok1B3r4G0f3qpMjwY/zgBPi5a5Kancbn8QNao5BkCZJVCwjXSZtugOSK3X4v v0RLlLer42OihFoi2Jeiy0AUYX1i/mexGJahtV2tAxTwLssoMsNB0dUk+pHYJA3PQsCa7ThJ gho/nyaZmersNP761Eymvqvpymon5UnrKfWxpSdE9jYgOcB1tuzWKELLvCTTrIEpPRpRrOqa FIgBaIPFjUF8TrbFicTy5Pz09DQ6/eeTrVifnp1/9UCTDHEh9aZ1RFvUXTBPLU+ySfxAOoEd HRKoBSFKjewqpEAZ2iZH21uBJpc3LFmjzW4RmDCQpQg7VgbGxCx4uurhrEAPpA1HpFZ5I9p4 rpof7ZXg7xF1jcuOjFvKGTBiOD/CGU4YaqxJdeCPVj2AV2ZJk5H8SoaANAD7mi1YgD18kABL DgQXaCK1Omr0S424iOnV/fv3WVXCUHytXQS4o3/rSs6QOUxscGZoBmJqr8PQBUmrnFGvk9Mv 4U/IXoITYD/nfCnSDfroxaLh73MECs7kknl/e5pdsIEnB00K34Mr+ruC9PXJ+Vfs9Pzi9O8X Zw/YeofrffyhZn8Dx6coVYlQ7EWYVvV+tmqqLbPCBOOsVV/wS4u64YA60mRR1WRiQnoPFNcv hnA6iBVGsJwAYjgCjcYCP+reuyZv+QJfD7vypqnAfqp+3+v3jz/w9DE2hUxNor69KW9ARcsf 9JvZTIYVw6gncBCcX8xmyHS9ikW7rzlwwZcM8KmxWv6+4B9aXhLngUVx5VGDlF0ikdueqHYy RBPtIFwjCCuU0Bab4ds9cU+MYPQ9+mb+gQ9gwxtqomZ03otFXuYtCFcgeLEK6b37gFAvK8Ev T6cas2a/aLpyupF09vJUkxEfh77xYHI9VajBhhLEvB8fIE06kL6MQ8xYiDmsCjQlvVlI17TY BHPTGYFChALWFgQ4L9vA+0U7MowWJagLdk+wQIHDL3OP3ZtYzCEE+ukghJSNjPx1y65ePP/h 6ZPFj4sXP104EAkx0MsyGE3Uo2h8rXFhnG/R/GlXBsFjY2QT4mmPHY/ABd5LnoiqxIXFsLCe buO+nuQLGt5tAlEn9OsjmBXrSpCXvMSA2FgDiAC2SdpUALung8UsXCf4n4UyjKFceZENXiiH pN8iU9866K15qxvFbQymF666HjPvgnzgPWAa+A/8TzvAe+Jt+RFuj1ZwuPN4cR/rO1q3JelH rIfEvgXdVUGChw6lg4VQiLAEB4YBKYgFOet+9NjtAw/VhFa3F0UGdk+9F5CMQL9dn+yU3XYJ H0PwiDvoV5UQAeBE6O0sKCrvotcNRKQ4l4luAokqoDy3hgwDKdAZ4ON676iTS1CHDBcudWVX CAyA77ho6AkU8EwfXgg+oYTuCIWTZ3PhR3CfUQq5I9kMrQ+Y+/qYliatCTIgggBmQAwVW8N/ ++03hh5ym/8XxeYhQ70HHROMt2msmQl8TDvRVtgN+NlDICwFiD9Y7rRrsVEEWsIvfcllFbFG L1j0K2DhTxlj6zEKIqohBBKYu8JRxAPMXDB3HAezBz4Y3+Hs0u35t+nl4Bmwcu6okQKOEZ/O IijdyvLVCgLAEg1rS+UNEz/2oqWF0DIB7JKkkHIpzxUpM5nkKhptmgrrCU0bgoC3Js7WYSS8 gEWnTSI2A1gB0lRPqiacQ8rKat5sUFkx8WopQSOxY+hM86RQkjYWdphuYdZ4ee1JtLx3B3zT 2HyBh4BQAg1GV6+bJMOpwfIkyjpY4S/qXq/tB5RvgE+PB304smITxdAjcqvbLt1Y3FOVJiXU DElSZRioO7FGqAAQC/iwYkMpLAgQFzrC3+ZZVpDfy1tMFtXwnSw0yMyBJVlSYwRvLTxX2n+E OQ9235F+p2gcFIrBXE+yTMCUqEpb3qquWSXRUWBcpmL2KDiEBpC+5Fse9hnOZk8GCD5mYKUJ w1hyAMM8TZ1DUZ7KMSdaZAVnkeXN5XMAPNFDRgCHWlVJAAEc7EMufDKGhOi1STD9SJr1weGq U4WlBdXLjjmDfgmhQjZ00BrHGySekHl8WCjCLRDyHSBZky5/52kL7eImrxeKvjiThI0x1KLn iiK/RW3Hhv2AtR3OtN1QKRdVYCzZp2hwi4YORbn3IXWNSZqAuadzORbcvhawfbT8SwPpmF37 Uer3Ggt2kpjoarkaeH1x+g4Gw5C1O8Th7m1DnY4TEBTrUfqR+y6oQR9A5J1NW2UhSHskH2T5 inw8aDAYGbDjvAAXXlK+vtxbo32Hk8Hcj3Wb6UTlW1T5JinXwOyCl4bj8/nALjYpiohsvM7f sX/BBBNeKXGCV8O1QWMAAXidtJtY1AWkzPAuAEDz+fWZ2xu9mSWN19DpnTs/PiSgSVlWXQm0 CDwcUqOpx0QJ/nZ11FZRBrTAVImmChE/KxXCZ2z0DfDtDWLbow3iRpXmYAwFH8ln9Lt+3EBg APTsv3Phj2fBR4bA6H+F6kcxgARhivvgAyRpFdO/+OKLSWhts5+eBh8ZpNUJBM7BtYfFJpjO C70o90KkjhdVXgjTvBuvDR/+IeX1dBljK9aHp22SHPyHW+mAAaP+xAmgBwqirNPKtepA/ioy BuTz1u6mXxDzHxvbMU43h881yZEfVT5J07s7DHE1+x9DXEv3X/K2a0p2HyzHfVuKUJYxZYJY 5fdOlSgpc4JwgF4su7ywsoRGwlEqrkMd4xzAE9Ar9ONU+px04kgCSBMyLtJhk3ZFw9fS12iM DzQfcvx94Ha4dX/Y6zddiQHM4qMd3T2dyS4HwoePxw4TgcOwC7IqW7R8W+u4QrdYgoCKJHid 0PZdWtVUgpYbDGlCO4/5SlaICxDD3oE5GGIlq6r3Mf4TuC2gt9eW7ejzFHtI/3bQXbHf6azf Dbrqx1rbwyzLMUpIin7eMSYxlRmzYBzXO3GM3MBVPDW19eVe1sIpkzEbdtYwzJmYlQDLqJfK 7nL/hTqAucedmkSoBNMAAP8RBMO9QVmiI56iX3BIEFjKxL5QIdvj3x5fvXn98NHPj5Fqo+qB KjgMHTrkAa+J79jTlPIgxk/KvczdADupaohT71vjAZhXVZ8i4DYCEGLPlrxt5bY6FUER1g4r MHIzg6vNw3AACnMgGTrmQiZD2TAXAte/wWgF5koamR0PgLjZldpQyQ1hdzJ4YrukbOM5mw1G qxacFldOc0qnpFIjqiiBUQAprZq9ri0NoDieO2l4aKmrofWGFzXljEMUzPYP2WcLlNMRYaF1 whjMDVe0El2fDjQI0lTEXtbbaGs/fy9nQVyM+zXLpDQQh7hCiGpEhhnB9HX8uYWJjvfGdWTd A2FLZF1rb9dI8Dnqzx8gXsaN6RxD8AnagKoSQAuj36u8DDTNJOZEjGPc2OArbxAjfqg/BQB0 HwCgnY9bAfjQxYfRDqCkBzOgwhNNBTra4NghfPCsCi/JmF6PaO79/PTRy4cv/wMCZQyMP8qC cSrrPf7tlxcvX78a1GSQB2C4UDdcMzYOXzSCcVLXZJD3W5diZLikLeVBv8MW4h7ISn3UQCYw NI+HY2VWIPcV5OCRWJUYqidZ5iSt5swKmY2qN//DndwhNF01Bo8r7BqQgg0pW6n8gDPQ1JJd g63rvWMyOv5XO7frI8+caEFRDLX4fqTe2T+efSLGC7X03nH8hKOWQb2milXYkgeZaC8dPLek zx1X6dEZHy80PB2ZN3VwQjlcaUfLjGKdJdg0LFXAe/AE317SGY2zU1frJzPDI+c8wgVbrrJF WlQwDxn1t3EcvwWCraoqTi7Y0/J9UuQoVbwZlzsJ3qHV/VqExIYIhA0AhlKANS8OElmtluq2 Wnxz+5wO+Chw6irDclwTY+PESjkPracT+nME7y8+LXgxB7GcCOabbz8ngrnTY2Gw21Tk24WJ 71A2ErZF4mDMD/EZItfosGcQ7KkdEVhykad5C4GMgPAu3SjK49kZPMoH4Z89K1F9hykbCGfB W60TyDLRNnktvfzkjMELiNH3WNCDgAwy5bPTnx6xb+SwmmfSwXzDvvvu7BRbHGp3pdvtcjDs mHaAfnpkDwrw3eX5lw9IrhLW7us8BS1VBw17Tz93NiKQ5bLI5kqTK+dKnrxIeNZw88HdgEf2 H9z4N88tqaXzHMgz3T63J51TfdGN39atP/bz8V4y0by141RmeusAShuBr66ShiiIEOfLoBiy +64ZpzYTD3H41vkcft+lp8pvb+3aB86DjfwjVXMwWzBRxJ7lIuVFkZQczyPKHRcBDXd8NKTq PagsRiC6QsLomI91wrg/7NCkZEYaLqI+DsUQTQqdEShx+CCLfmT1sx9xa19UZqqBTJ5w0Y9V K/F9y36a3I4yCF2dtt9dMt833fEskVwEFan1awr/mlSGr3T01F3AMONE34xH2lLMK4CG2+RG eWVZ/AQ8VIoovyNh0bj48csr34EVYOwaohxNZR19AVfPFmg0B1VcVcHFSXJdJ8SuxtTJLQXE JpS12ncTXkiW5IZnucLB3k3/eJ3sSvae0WkQ/57wWUBihh+pgH1oOBZhQkP40YKMaIwRpYTu cpQASHJOUsbUst3idjpR2z5S6ZhM7+kIyKFq9misETDlJnoOYtbk7m/dZi1GD634mDA/lpGF cy7uTlsDn4DcH8HtVqz6EqxEwZiokXWZ09HNqdODM2wxST1Eg+owQF10cq8e0yBdS8NiIRhO 3gh1FHF08SEYgD94GlGdavD7KvE/+FDfANG7H+vTAMyHI/aQTJM5qaFTAi3s6nAwlglN8gd/ mz2rQUba0IKEVS7FAXV4wrkPElEQKbeHcqsYP3Xi45uDJz5o7gXNjayIIonM4vuieJbk5b+e nfcGdSz1g9F+T9I7Hfvp77Z8xskfC8hnHv4xkO5+/kce/xmhoI59o62+s6bfU26lz2hCm76W rh+xZ8l+SYmCfZROGZ1o225ABDMhj+uAPpeqIlbmYsPtXIuO75BkJqXM+hD7gGR3e3ZK92Xw MP8zI8ypsNEIzFwX7JWKc+SLSCQrrrauUACpbo71Efj8nwqcP1eAptSorGxj028NILaArytn n3QORxu/ob2a6Uc2/wLhxtikDd9oK/K/YLSGqHyG1bpVWXtV+2OK9QnKRLPII+EfUZz5FGcN J/7aZPxrk/H/7SYj+G+79nWpdu9e/fjw5ePvF6pC77jhT9/h+aStmU/divkjOzF/7jbIHy6c 2kz4q1o1/fxVrfpIzz+rWnUwUsHQZGY/R+yROdaP6qVdN+0pY/ahb9dyOlc8vqFDqrfcAyCg WdIVbWgHly0reCJaOvhPKg0zNagiG9pAkLc0E9aVZMJzCDGP9InieDazLhGBdnvVjde/ev7i tXyLyua0vHl+9fjl64dPn2MrnuNr8Iq9N5vRYeDBhSkVFXmed6VPEdCp0q6h/Equl66RQPhC my0QHchtDzzXvA8NJSQ3UKkTpN4WtEbdTiGO4UKtkg+d2nhydRUzdZQKTze3Xa1EbnTVKlR7 9r5soEIWVg3VCfBVVRTVDucAdPCmZ2sqYxYRjbyo09I7jpnCGuLlDV6SoX0syf/hWKK2Ga4z 06KqbmB4lQ27GxaYIcglKsNFEXBbUwbjfUNA6uurBfvytvCm2yZlhN1oCNadiI51ASylI/hY c8jbjlgTS2bi/Wls0Eccdrgps6fruzCXvKXtvfjJu2A8p9TFF3sRK7HzmflNBoRF8OWsHrDL YwE6gL2cWl+AUVKyS4Q83ma4C2yTjotgKSkCTfL0mj0zmzOT/g0FL9bSqYsyuKMCSpNyOfMK 5JuEUv6aBIow7j2Z1eDZel/umCHsFLeUEgXKRoJkH1ij9NY6ZAM8QvOfxbGirnsdVe9aw5wS nFypeknLweu2akosMPTI9WvH60WUbdY9JU1hD4mpxkM/fdyGD0xQf5lICaoqU5brGC9dBzZR iJNz3KE97aMhVQYLLH0JmWejCyott9p9GO+r+EHSBG+YGhLE6IO1iTEOVN3dcw6UHuEPgRw8 10TagRay0Bc0sAoE5iXd2NesHslrHdqD0dEwEHP1qw85na1aoRHmZdWtN32EscKQCWKQYFX2 rgTD2FWMU1uXDVcx7UYHA4+jzpc+faGK0fDdXps8kQUBOpiKRl6RR1RyPGYhG0guk71CctdU 5doa39rH++VVIfiGms/AFMM7efXHQMW64zYX9MMeGsqIq8Y0jZ0sKIS6uUTYYpH8Qh3xABLR 8mIQKbqArQNXt7DlKpWWbshQvKN8JRN9pdi0C23uMIl8mxeJc2rPkd2wtwhDscVnWnSp3t/L rIbg43psjo9rcyN4ZP41SLT+8jKShD0BeiadrXt19ULbMva62aMo49rMvQ7dT92govuq9Ksl ci+7F/inMr6GWEnk9HskrcJX7jCpX4zpDSf+P7hCrxVamalXZBn/Xb6c6i+PeKveiLVV7bDt XdPHi/QB66jQEzXKHRRQdWOu7ZTq1zMBiSLTGdJPDeeY+SzKum2tfVXoN/7cHrVQHuQSvwy1 GF8N9bjhAmI26N/wWJqWwA/eZsdvY/3P3A97wP1AQFuOdUXHuSzoUjaQ/eN1U3V1cDa/TQJd MMjXCW070KnIDhG9yHqay14HSa6AEMXf/x+ks3Uz+DPI7EA5QOXpPkotD1FaNffktvofpLkN kwgf/c/KOfscBmhk/wQujEEdYMUtHbXJdu7r2/fxB2Pns/8GUEsDBBQAAAAIAMdAfSn7jXi0 sQAAACwBAAAKAAAAY29tcGlsZS5weX2OsQ6CMBRF935F0wkS0gSdXYTFBBMXJ0IaeFR8Wihp i+jf2ypu6vZyc+65D/tRG0dbtG5yqKyAm+Xw6GYcAHQ/opKGEAC6+c/ww2TkHoduXq+ybAmj NCZENxfr2wB8YaOStUqdwHFgVUIZS2gZse1xV+QiLwqWpHEVk9Hg4Ggo+3WucLgKe66NbIXC Jgq5r749LP41cpZK6TDz1SfvEiZXN55efC+eLT997FW4uXc8AVBLAQIUABQAAAAIALm6fClL WUv0PwAAAEMAAAAKAAAAAAAAAAEAIAC2gQAAAABkbGxoZWxsby5jUEsBAhQAFAAAAAgAkLp8 Keyz8xeDAAAAzgAAAAgAAAAAAAAAAQAgALaBZwAAAGRsbGZjdC5oUEsBAhQAFAAAAAgArbp8 KVNkU0JWAAAAXQAAAAgAAAAAAAAAAQAgALaBEAEAAGRsbGZjdC5jUEsBAhQAFAAAAAgAvUB9 KQ/4fKDSFQAAIU0AABIAAAAAAAAAAQAgALaBjAEAAGN5Z3dpbmNjb21waWxlci5weVBLAQIU ABQAAAAIAMdAfSn7jXi0sQAAACwBAAAKAAAAAAAAAAEAIAC2gY4XAABjb21waWxlLnB5UEsF BgAAAAAFAAUAHAEAAGcYAAAAAA== --------------437FC20D6156B791E5FEAA83-- From Alexandre.Fayolle@logilab.fr Wed Nov 29 10:01:01 2000 From: Alexandre.Fayolle@logilab.fr (Alexandre Fayolle) Date: Wed Nov 29 10:01:01 2000 Subject: [Distutils] distutils extensions In-Reply-To: <200011282037.VAA00756@loewis.home.cs.tu-berlin.de> Message-ID: [discussing distutils on xml-sig, since this is becoming distutil-specific, I swich lists. I'm not sure whether Martin von Loewis has subscribed to distutils-sig, though...] > > use doc_files in your setup.cfg file, or --doc_files filelist on the > > command line. > > Thanks, I will try that. 2 remarks: * I typo'ed, it's '--doc-files' (with a dash) * this option does not handle directories, which really is sad. The 4Suite team has overcome this by providing an extension. I'm looking at their code right now, and it looks as if their extension package was really interesting. Is there any chance that it could be incorporated to a future distutils release, or released as a 4Suite spinoff from the fourthought site? Alexandre Fayolle -- http://www.logilab.com Narval is the first software agent available as free software (GPL). LOGILAB, Paris (France). From Alexandre.Fayolle@logilab.fr Wed Nov 29 11:07:01 2000 From: Alexandre.Fayolle@logilab.fr (Alexandre Fayolle) Date: Wed Nov 29 11:07:01 2000 Subject: [Distutils] distutils extensions In-Reply-To: Message-ID: On Wed, 29 Nov 2000, Alexandre Fayolle wrote: > > > use doc_files in your setup.cfg file, or --doc_files filelist on the > > > command line. > > > > Thanks, I will try that. > > 2 remarks: > > * I typo'ed, it's '--doc-files' (with a dash) > > * this option does not handle directories, which really is sad. The OK, so once again I goofed... Sorry about that. If you put a list of directories, it will handle them properly. Alexandre Fayolle -- http://www.logilab.com Narval is the first software agent available as free software (GPL). LOGILAB, Paris (France). From hoel@germanlloyd.org Thu Nov 30 03:24:01 2000 From: hoel@germanlloyd.org (Berthold =?iso-8859-1?q?H=F6llmann?=) Date: Thu Nov 30 03:24:01 2000 Subject: [Distutils] distutil or setup problem? In-Reply-To: hoel@germanlloyd.org's message of "27 Nov 2000 17:57:01 +0100" References: <02fb01c053ca$4bc7d320$e000a8c0@thomasnotebook> <00d601c05522$e7a98730$e000a8c0@thomasnotebook> <02f901c05880$e477ab80$e000a8c0@thomasnotebook> Message-ID: hoel@germanlloyd.org (Berthold H=F6llmann) writes: > "Thomas Heller" writes: >=20 > > As you can see from the comments, 'python15.lib' SHOULD be included by = some > > pragma inside 'config.h', which is #included be 'Python.h'. > > May be there is something wrong with the include files? > > Or has this something to do with the fact (IIRC from your first posting= ), > > that your source code does not reside in some subdirectories? >=20 > Thomas, >=20 > Thanks for your help. It led me to the right direction. I was using > another library that which had anther config.h in it's include > directories, which prevented the python config.h to be used > correctly. After some fiddeling with include pathes, I now can > successfully compile my module. Ahh, I'm wrong. Distutils 1.0.1 do not work with Python 1.5.2 on Win32 because the 1.5.2 config.h for Win does *not* contain the neccesarry #pragma definitions for the library inclusion (at least in my copy). So I guess get_libraries in distutils/command/build_ext.py should be changed to something like def get_libraries (self, ext): """Return the list of libraries to link against when building a shared extension. On most platforms, this is just 'ext.libraries'; on Windows, we add the Python library (eg. python20.dll). """ # The python library is always needed on Windows. For MSVC, this # is redundant, since the library is mentioned in a pragma in # config.h that MSVC groks. The other Windows compilers all seem # to need it mentioned explicitly, though, so that's what we do. # Append '_d' to the python import library on debug builds. from distutils.msvccompiler import MSVCCompiler if sys.platform =3D=3D "win32" and \ (not isinstance(self.compiler, MSVCCompiler) or sys.version[:5] =3D=3D 1.5.2): template =3D "python%d%d" if self.debug: template =3D template + '_d' pythonlib =3D (template % (sys.hexversion >> 24, (sys.hexversion >> 16) & 0xff)) # don't extend ext.libraries, it may be shared with other # extensions, it is a reference to the original list return ext.libraries + [pythonlib] else: return ext.libraries to make building extension modules work with 1.5.2. Greetings Berthold --=20 email: hoel@GermanLloyd.org ) tel. : +49 (40) 3 61 49 - 73 74 ( C[_] These opinions might be mine, but never those of my employer. From thomas.heller@ion-tof.com Thu Nov 30 06:49:02 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu Nov 30 06:49:02 2000 Subject: [Distutils] distutil or setup problem? References: <02fb01c053ca$4bc7d320$e000a8c0@thomasnotebook><00d601c05522$e7a98730$e000a8c0@thomasnotebook><02f901c05880$e477ab80$e000a8c0@thomasnotebook> Message-ID: <016c01c05ac3$71637580$e000a8c0@thomasnotebook> hoel@germanlloyd.org (Berthold Höllmann) writes: > > Ahh, I'm wrong. Distutils 1.0.1 do not work with Python 1.5.2 on Win32 > because the 1.5.2 config.h for Win does *not* contain the neccesarry > #pragma definitions for the library inclusion (at least in my copy). > This is from 1.5.2 config.h: #ifdef MS_WIN32 #ifndef USE_DL_EXPORT /* So nobody needs to specify the .lib in their Makefile any more */ #ifdef _DEBUG #pragma comment(lib,"python15_d.lib") #else #pragma comment(lib,"python15.lib") #endif #endif /* USE_DL_EXPORT */ So, it *should* work... And it *does* work, just checked it out. > So I guess get_libraries in distutils/command/build_ext.py should be > changed to something like [snip] It has been debated on distutils-sig in the past whether build_ext should special-case MSVCCompiler or not. Maybe we should remove this special case completely. Anyway, I would be interrested why it does not work for you. Thomas From hoel@germanlloyd.org Thu Nov 30 09:43:01 2000 From: hoel@germanlloyd.org (Berthold =?iso-8859-1?q?H=F6llmann?=) Date: Thu Nov 30 09:43:01 2000 Subject: [Distutils] distutil or setup problem? In-Reply-To: "Thomas Heller"'s message of "Thu, 30 Nov 2000 12:48:23 +0100" References: <02fb01c053ca$4bc7d320$e000a8c0@thomasnotebook> <00d601c05522$e7a98730$e000a8c0@thomasnotebook> <02f901c05880$e477ab80$e000a8c0@thomasnotebook> <016c01c05ac3$71637580$e000a8c0@thomasnotebook> Message-ID: "Thomas Heller" writes: > hoel@germanlloyd.org (Berthold H=F6llmann) writes: > > > > Ahh, I'm wrong. Distutils 1.0.1 do not work with Python 1.5.2 on Win32 > > because the 1.5.2 config.h for Win does *not* contain the neccesarry > > #pragma definitions for the library inclusion (at least in my copy). > > > This is from 1.5.2 config.h: > #ifdef MS_WIN32 >=20 > #ifndef USE_DL_EXPORT > /* So nobody needs to specify the .lib in their Makefile any more */ > #ifdef _DEBUG > #pragma comment(lib,"python15_d.lib") > #else > #pragma comment(lib,"python15.lib") > #endif > #endif /* USE_DL_EXPORT */ >=20 > So, it *should* work... > And it *does* work, just checked it out. >=20 > > So I guess get_libraries in distutils/command/build_ext.py should be > > changed to something like > [snip] >=20 > It has been debated on distutils-sig in the past whether build_ext > should special-case MSVCCompiler or not. Maybe we should remove this > special case completely. > Anyway, I would be interrested why it does not work for you. OK, my boss needed 1.5.2. He made a local install and copied the file to our file server, but only the executables, not the header files, so they are still from 1.5. Now I replaced them with the new ones and it all works better now. Thanks for your help. Greetings Berthold --=20 email: hoel@GermanLloyd.org ) tel. : +49 (40) 3 61 49 - 73 74 ( C[_] These opinions might be mine, but never those of my employer.