From Mike.Olson@fourthought.com Sun Oct 1 14:04:01 2000 From: Mike.Olson@fourthought.com (Mike Olson) Date: Sun Oct 1 13:04:01 2000 Subject: [Distutils] setup.py for a wrapper extension? References: <005d01c028ae$ac7fa180$f73f93cd@visionart.com> Message-ID: <39D76D9B.6FF80FDB@FourThought.com> Pete Shinners wrote: Pete, We actually just ran into the same question. So I'd like to hear anyones answer as well. For now what we did is before the call to setup() we modify our list of Extensions. If we are on linux we do it one way, on windows another. Not pretty but it works. We have a little easier situation then you though because our "other library" is a python .so so we just import it to find the path.... Mike > > i've got a python extension that is simply a wrapping > around another C library. (not an uncommon case :]) > > i cannot figure out the 'right' way to check for and > link/include this dependency into my distutils > setup.py script. > > under linux, it's pretty easy to assume the correct > header and shared library will be somewhere in the > standard include and library directories > /usr/local/include, /usr/local/lib, etc > > my main concern is getting it working with windows > (and keeping it crossplatform happy for linux). my best > bet in windows seems to be walk around the parent directory > tree trying to find directories for the dependency?? > if that is the best way, it would probably be nice for > the linux version to use this method or look in the > standard compiler directories ??????? > > i'm hoping someone out there has an example doing just > this sort of stuff i could look at. the documentation doesn't > mention anything about this sort of stuff. (except for > adding library and include info to the Extensions() call > > thanks for any help and/or guidance. the distutils have > just amazed me. > > (please help, i couldn't get any responses on c.l.python) > > _______________________________________________ > 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 Mike.Olson@fourthought.com Sun Oct 1 14:05:01 2000 From: Mike.Olson@fourthought.com (Mike Olson) Date: Sun Oct 1 13:05:01 2000 Subject: [Distutils] setup.py for a wrapper extension? References: <005d01c028ae$ac7fa180$f73f93cd@visionart.com> Message-ID: <39D76DCD.B78E7F7D@FourThought.com> Pete Shinners wrote: Just thought of something else that is probably cleaner. Add som command line options and have the user specify where the library and header files are.... Mike > > i've got a python extension that is simply a wrapping > around another C library. (not an uncommon case :]) > > i cannot figure out the 'right' way to check for and > link/include this dependency into my distutils > setup.py script. > > under linux, it's pretty easy to assume the correct > header and shared library will be somewhere in the > standard include and library directories > /usr/local/include, /usr/local/lib, etc > > my main concern is getting it working with windows > (and keeping it crossplatform happy for linux). my best > bet in windows seems to be walk around the parent directory > tree trying to find directories for the dependency?? > if that is the best way, it would probably be nice for > the linux version to use this method or look in the > standard compiler directories ??????? > > i'm hoping someone out there has an example doing just > this sort of stuff i could look at. the documentation doesn't > mention anything about this sort of stuff. (except for > adding library and include info to the Extensions() call > > thanks for any help and/or guidance. the distutils have > just amazed me. > > (please help, i couldn't get any responses on c.l.python) > > _______________________________________________ > 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 Mike.Olson@fourthought.com Sun Oct 1 17:06:02 2000 From: Mike.Olson@fourthought.com (Mike Olson) Date: Sun Oct 1 16:06:02 2000 Subject: [Distutils] Does the SWIG support work? References: <20000929214347.A2128@beelzebub> Message-ID: <39D79911.5F4B844D@FourThought.com> Greg Ward wrote: > > Hi all -- > > some months ago, I added completely experimental and untested support > for compiling SWIG extensions to the Distutils. I even documented it! > But I have been unable to verify for myself that it works, since I have > been unable to build SWIG on my home PC. I haven't heard any reports of > success, and the first reports of failure were from 4Thought last week. > > So: can anyone vouch for whether the Distutils SWIG support works at > all, does the "right thing", etc? What's broken about it, what works? > Should it even be documented? I can't vouch for everyone, but I usually run SWIG with the -shadow option. This generates .c and .py files. In this case the swig support is broken. I currently have swig1.1 installed. Until the problem of multiple output files is solved from extension modules I think it should stay hidden. Its a pretty simple fix to get multiple output files from an extension. I wrote it once then canned it. Basically you need should ask the Extension class for a list of outputs instead of just using its name. The extension class can then check to see if any of the source files end in .i Mike > > Greg > -- > Greg Ward gward@python.net > http://starship.python.net/~gward/ > > _______________________________________________ > 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 gward@python.net Sun Oct 1 20:52:06 2000 From: gward@python.net (Greg Ward) Date: Sun Oct 1 19:52:06 2000 Subject: [Distutils] Re: distutils bug with PyXML 0.6.1, Python 2.0b2 (CVS) In-Reply-To: <39D7C6D4.FBF17094@per.dem.csiro.au>; from m.favas@per.dem.csiro.au on Mon, Oct 02, 2000 at 07:20:52AM +0800 References: <39D7C6D4.FBF17094@per.dem.csiro.au> Message-ID: <20001001195018.A11937@beelzebub> On 02 October 2000, Mark Favas said: > With the current (Oct 2) CVS versions of PyXML and Python (2), running > "python setup.py install" produces the following glitch: copies all the > relevant files to /usr/local/lib/python2.0/site-packages/_xmlplus and > then tries to compile them all. Unfortunatley, it tries to byte-compile > sgmlop.so, leading to the traceback below. Is this a PyXML mis-setup of > setup.py or a distutils (Python core version) bug? D'ohh! That's a Distutils bug, introduced last night. Just checked in a fix -- thanks for the quick report! BTW, it doesn't matter if you follow the Python CVS or the Distutils CVS, you'll get my latest code either way. Greg -- Greg Ward gward@python.net http://starship.python.net/~gward/ From gward@python.net Sun Oct 1 21:00:01 2000 From: gward@python.net (Greg Ward) Date: Sun Oct 1 20:00:01 2000 Subject: [Distutils] setup.py for a wrapper extension? In-Reply-To: <39D76DCD.B78E7F7D@FourThought.com>; from Mike.Olson@fourthought.com on Sun, Oct 01, 2000 at 11:01:01AM -0600 References: <005d01c028ae$ac7fa180$f73f93cd@visionart.com> <39D76DCD.B78E7F7D@FourThought.com> Message-ID: <20001001195832.A12022@beelzebub> On 01 October 2000, Mike Olson said: > Just thought of something else that is probably cleaner. Add som > command line options and have the user specify where the library and > header files are.... And easier still is to use the Setup file hack: just have the user edit this file to specify where the headers are. Sure, making users edit files sucks, but this sucks no less than the old Makefile.pre.in way. Until we have real auto-configuration in the Distutils, it'll have to do. (And I suspect it'll remain a fallback for people who install important libraries to /opt/weird/path/ instead of the de facto standard /usr/local. Never mind Windows and Mac OS, which should make auto-conf'ing *real* fun...) Greg From gward@python.net Sun Oct 1 23:32:01 2000 From: gward@python.net (Greg Ward) Date: Sun Oct 1 22:32:01 2000 Subject: [Distutils] One last snapshot Message-ID: <20001001223014.A12527@beelzebub> Hi all -- I just finished hacking up the bytecode compilation stuff. Turns out that was a lot more fun than working on the test suite. Anyways, this is the last non-bug-fix that's going to get into Distutils 1.0, which I plan on releasing tomorrow (Monday) night. After that, I won't be available until Oct 12, so the code I release tomorrow night will almost certainly be what goes out with Python 2.0 So, obviously, I need all your help to beat up on this code snapshot! You know the routine by now: please give this snapshot a workout on your favourite Python module distribution on a variety of platforms. You can download it from the usual place: http://www.python.org/sigs/distutils-sig/download.html Thanks! Greg -- Greg Ward gward@python.net http://starship.python.net/~gward/ From mal@lemburg.com Mon Oct 2 15:31:24 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Oct 2 14:31:24 2000 Subject: [Distutils] Byte-compilation revisited References: <20000930165104.A1413@beelzebub> Message-ID: <39D8D41C.E8A6A9BA@lemburg.com> Greg Ward wrote: > > Hi all -- > > based on and inspired by recent patches from Marc-Andre Lemburg and Rene > Liebscher, I've finally started tackling the byte-compilation problem in > earnest. Here's the approach I'm taking: > * new function 'byte_compile()' in distutils.util: this is the all- > singing, all-dancing wrapper around py_compile that will do all > the real work > * reduce the 'bytecompile()' method in the install_lib command to > a simple wrapper around 'util.byte_compile()', that does the Right > Thing with respect to optimization and claimed source filename > written to the .py{c,o} file > * add similar functionality to the build_py command, so that you > may optionally do byte-compilation at build time rather than > install time. > > The first two steps are done and checked in, except that install_lib's > 'bytecompile()' method doesn't yet take advantage of the fancy features > in the new 'byte_compile()' -- it doesn't rewrite filenames or do > optimization. > > The default will continue to be doing compilation at install time rather > than build time. I'm still leaning towards build-time compilation, but > it's too late in the Distutils 1.0 release cycle to change things like > this. However, I want to have the *option* to do compilation at build > time, so people can experiment with it, see if it works, figure out what > other features are needed so it really works, etc. The idea is that > developers could put settings in their setup.cfg that control when to do > byte-compilation; I suspect developers who want to distribute > closed-source modules will have to do build-time compilation. Probably > the "install" command will need some sort of "don't install source" > option, or maybe the build command should have a "blow away source after > compiling it" option. The latter is not very useful, IMHO. I will definitely need the "compile at build time and don't argue about not finding the sources at install time" option ;-) > Here's my 'byte_compile()' function: as usual, it works for me. Please > review it, and if you're following CVS, try it out. (Should be enough > to install any module distribution containing pure Python modules.) Looks ok , except that I would pass the Python filenames through os.path.abspath() before writing any externally run scripts... both to work around possible security problems and to make sure the shell finds the right files. > ------------------------------------------------------------------------ > def byte_compile (py_files, > optimize=0, force=0, > prefix=None, base_dir=None, > verbose=1, dry_run=0, > direct=None): > ... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From thomas.heller@ion-tof.com Mon Oct 2 16:26:18 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Mon Oct 2 15:26:18 2000 Subject: [Distutils] Automatically detect wrong lib-format for borland compiler? References: <04f601c02983$7d877da0$4500a8c0@thomasnb> <39D47F9B.4518D61C@gmx.de> Message-ID: <007d01c02c9e$10112d70$4500a8c0@thomas> Also see the recent thread in c.l.p (which says, as I understand it: using the MSVC import libraries with borland-compiled extensions is at least dangerous, because the wrong C-runtime library may be used for stdoi) Thomas From gward@python.net Tue Oct 3 00:09:01 2000 From: gward@python.net (Greg Ward) Date: Mon Oct 2 23:09:01 2000 Subject: [Distutils] Byte-compilation revisited In-Reply-To: <39D8D41C.E8A6A9BA@lemburg.com>; from mal@lemburg.com on Mon, Oct 02, 2000 at 08:29:48PM +0200 References: <20000930165104.A1413@beelzebub> <39D8D41C.E8A6A9BA@lemburg.com> Message-ID: <20001002230658.A786@beelzebub> [I propose a way to deal with closed-source distribution] > The idea is that developers could put settings in their setup.cfg that > control when to do byte-compilation; I suspect developers who want to > distribute closed-source modules will have to do build-time > compilation. Probably the "install" command will need some sort of > "don't install source" option, or maybe the build command should have > a "blow away source after compiling it" option. [Marc-Andre comments] > The latter is not very useful, IMHO. I will definitely need the > "compile at build time and don't argue about not finding the sources > at install time" option ;-) The latter option -- "blow away source after compiling it" -- was proposed because it would be easier to implement than "don't install source". The "install_*" commands generally boil down to a recursive copy from the build tree to some installation director(y|ies). The less work done there, the better, as figuring out the installation dirs is hard enough. (Hence my preference for compiling at build-time.) If we do things this way: * copy source into build/lib * byte-compile source * blow it away * install it then the install commands remain fairly simple. If not, we have to do something to exclude .py files from the "install" recursive copy. > Looks ok , except that I would pass the Python filenames through > os.path.abspath() before writing any externally run scripts... > both to work around possible security problems and to make sure > the shell finds the right files. Hmmm, that's probably wise. [ ... far too much time passes ... ] No wait, it breaks the "dfile" argument in certain circumstances, so that .pyc files created at build time have the wrong source filename encoded in them. Bother. This will be tricky to fix, so I'm gonna punt on it. Greg -- Greg Ward gward@python.net http://starship.python.net/~gward/ From gward@python.net Tue Oct 3 01:11:06 2000 From: gward@python.net (Greg Ward) Date: Tue Oct 3 00:11:06 2000 Subject: [Distutils] ANNOUNCE: Distutils 1.0 Message-ID: <20001003000845.A1812@beelzebub> Python Distribution Utilities release 1.0 October 2, 2000 The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python modules. (It is intended that ultimately the Distutils will grow up into a system for distributing and installing whole Python applications, but for now their scope is limited to module distributions.) The Distutils are a standard part of Python 1.6 and 2.0; if you are running 1.6 or 2.0, you don't need to install the Distutils separately. (However, you might want to upgrade if you're running Python 1.6.) This release is primarily so that you can add the Distutils to a Python 1.5.2 installation -- you will then be able to install modules that require the Distutils, or use the Distutils to distribute your own modules. Distutils 1.0 is the version that will be released with Python 2.0 (unless last-minute bugs pop up). More information is available at the Distutils web page: http://www.python.org/sigs/distutils-sig/ and in the README.txt included in the Distutils source distribution. You can download the Distutils from http://www.python.org/sigs/distutils-sig/download.html Trivial patches can be sent to me (Greg Ward) at gward@python.net. Larger patches should be discussed on the Distutils mailing list: distutils-sig@python.org. Greg -- Greg Ward gward@python.net http://starship.python.net/~gward/ And now for something completely different. From mal@lemburg.com Tue Oct 3 08:04:01 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue Oct 3 07:04:01 2000 Subject: [Distutils] Byte-compilation revisited References: <20000930165104.A1413@beelzebub> <39D8D41C.E8A6A9BA@lemburg.com> <20001002230658.A786@beelzebub> Message-ID: <39D9BCDE.327D86D4@lemburg.com> Greg Ward wrote: > > [I propose a way to deal with closed-source distribution] > > The idea is that developers could put settings in their setup.cfg that > > control when to do byte-compilation; I suspect developers who want to > > distribute closed-source modules will have to do build-time > > compilation. Probably the "install" command will need some sort of > > "don't install source" option, or maybe the build command should have > > a "blow away source after compiling it" option. > > [Marc-Andre comments] > > The latter is not very useful, IMHO. I will definitely need the > > "compile at build time and don't argue about not finding the sources > > at install time" option ;-) > > The latter option -- "blow away source after compiling it" -- was > proposed because it would be easier to implement than "don't install > source". The "install_*" commands generally boil down to a recursive > copy from the build tree to some installation director(y|ies). The less > work done there, the better, as figuring out the installation dirs is > hard enough. (Hence my preference for compiling at build-time.) If we > do things this way: > * copy source into build/lib > * byte-compile source > * blow it away > * install it > > then the install commands remain fairly simple. If not, we have to do > something to exclude .py files from the "install" recursive copy. Uhm, I only wanted to prevent the install command from producing errors in case it cannot find the .py files to install (it should suffice just being able to copy the .pyc/o files). Basically, the .py files should be in the source archive and be used to build the binaries. The binaries should then optionally only include the .pyc/o files and the install command or RPM shouldn't care much about not finding .py files... > > Looks ok , except that I would pass the Python filenames through > > os.path.abspath() before writing any externally run scripts... > > both to work around possible security problems and to make sure > > the shell finds the right files. > > Hmmm, that's probably wise. [ ... far too much time passes ... ] > No wait, it breaks the "dfile" argument in certain circumstances, > so that .pyc files created at build time have the wrong source > filename encoded in them. Bother. This will be tricky to fix, > so I'm gonna punt on it. Ok... but please make sure that the temporary script uses an absolute name and that the name of that file cannot be guessed. Otherwise, you'd open up a /tmp security problem here which could be used to trick distutils into executing code which wasn't generated by it. Perhaps you should pipe the program text to a Python interpreter instead... this would be the most secure option. We really need a sys.set/getoptimization() API in 2.1... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gward@python.net Tue Oct 3 23:08:02 2000 From: gward@python.net (Greg Ward) Date: Tue Oct 3 22:08:02 2000 Subject: [Distutils] Byte-compilation revisited In-Reply-To: <39D9BCDE.327D86D4@lemburg.com>; from mal@lemburg.com on Tue, Oct 03, 2000 at 01:02:55PM +0200 References: <20000930165104.A1413@beelzebub> <39D8D41C.E8A6A9BA@lemburg.com> <20001002230658.A786@beelzebub> <39D9BCDE.327D86D4@lemburg.com> Message-ID: <20001003220539.A805@beelzebub> On 03 October 2000, M.-A. Lemburg said: > Uhm, I only wanted to prevent the install command from producing > errors in case it cannot find the .py files to install (it should > suffice just being able to copy the .pyc/o files). OK -- *poof!* -- it works. Time machine. It's *always* been like that; the "install" command just installs whatever it finds in the various subdirectories of build/. If you delete the .py files in build, and then install *without building* again, then you have a no-source-code installation. Example, from my distutils development dir: rm -rf /usr/lib/python1.5/site-packages/distutils python setup.py clean -a python setup.py build_py --compile build rm `find build/ -name '*.py'` python setup.py install --skip-build That works: I now have a closed source Distutils installation. If I provoke a traceback (by setting DISTUTILS_DEBUG=1 and providing a bad directory), I get: Traceback (innermost last): File "setup.py", line 55, in ? ['Src/arrayfnsmodule.c']) File "./distutils/core.py", line 138, in setup File "./distutils/dist.py", line 829, in run_commands File "./distutils/dist.py", line 849, in run_command File "./distutils/command/build.py", line 106, in run File "/usr/lib/python1.5/cmd.py", line 328, in run_command File "./distutils/dist.py", line 849, in run_command File "./distutils/command/build_py.py", line 104, in run File "./distutils/command/build_py.py", line 371, in build_packages File "./distutils/command/build_py.py", line 333, in build_module File "/usr/lib/python1.5/cmd.py", line 358, in mkpath File "./distutils/dir_util.py", line 80, in mkpath distutils.errors.DistutilsFileError: could not create '/foo': Permission denied The filenames in the .pyc files are less than helpful (they're relative to build/lib in my development tree), but who cares? there're no source files installed here anyways! Is it obvious? Not really. Does it work? You bet! Could you sit down right now and churn out a closed-source RPM? I don't think so -- bdist_rpm doesn't let you supply arbitrary options to the "install" or "build" commands, and I don't think it should. You'd have to extend bdist_rpm to do this. Is this the right way to do closed source distributions? Well, to do it cleanly would require a "--remove-source" option to "build_py", and then support from bdist_{rpm,wininst,...}. Not impossible by any stretch. Who else out there wants this functionality? Should the ability to distribute closed-source module distributions be standard? Or should people who want it be required to extend bdist_{rpm,wininst,...} if they need it? trying-so-hard-not-to-say-"greedy closed source bastards!"-because- you-know-I-don't-really-mean-it, Greg -- Greg Ward gward@python.net http://starship.python.net/~gward/ From gward@python.net Tue Oct 3 23:47:02 2000 From: gward@python.net (Greg Ward) Date: Tue Oct 3 22:47:02 2000 Subject: [Distutils] Distutils 1.0 code freeze: Oct 1 In-Reply-To: <02af01c0296e$40cf1b30$4500a8c0@thomasnb>; from thomas.heller@ion-tof.com on Thu, Sep 28, 2000 at 07:05:02PM +0200 References: <20000926205312.A1470@beelzebub> <02af01c0296e$40cf1b30$4500a8c0@thomasnb> Message-ID: <20001003224522.H646@beelzebub> On 28 September 2000, Thomas Heller said: > Will report this on sourceforge, although I doubt Greg will be able > to fix this... > > Distutils code freeze: Greg, I have some time next week to work on > this. Do you give me permission to check it in if I find a solution? Gee, I never replied to this, did I! Did the bug get fixed? Or is it still there in 1.0? Since I'm going to be off the 'net from now until well after Python 2.0 is released, I'm very reluctant to say, "Go ahead, check it in!" -- I don't mind if Python 2.0 goes out with Distutils 1.0.1 (as opposed to 1.0), but I do mind if I'm not there to manage the 1.0.1 release. Tell you what: I'll try to login and check my mail sometime this weekend (Oct 7-8). If there is a clear, obvious, well-understood, well-tested, and approved-by-Thomas (and preferably at least one other Windows-based Distutils hacker) fix for this bug, then I will do my damndest to put together Distutils 1.0.1. If there are any other glaring, show-stopping bugs in Distutils 1.0, they are also be subject to this ruling. (If you have to stand on your hands and hit escape-meta-alt-control-shift-F13 while staring at the screen cross-eyed to get a traceback, the bug probably *won't* be fixed.) If I'm unable to get a couple of uninterrupted hours this weekend, then Python 2.0 will go out with Distutils 1.0 as-is. This is the likely scenario, given my plans for the weekend. ;-) Greg -- Greg Ward gward@python.net http://starship.python.net/~gward/ From gward@python.net Wed Oct 4 09:28:01 2000 From: gward@python.net (Greg Ward) Date: Wed Oct 4 08:28:01 2000 Subject: [Distutils] ANNOUNCE: Distutils 1.0 Message-ID: Python Distribution Utilities release 1.0 October 2, 2000 The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python modules. (It is intended that ultimately the Distutils will grow up into a system for distributing and installing whole Python applications, but for now their scope is limited to module distributions.) The Distutils are a standard part of Python 1.6 and 2.0; if you are running 1.6 or 2.0, you don't need to install the Distutils separately. (However, you might want to upgrade if you're running Python 1.6.) This release is primarily so that you can add the Distutils to a Python 1.5.2 installation -- you will then be able to install modules that require the Distutils, or use the Distutils to distribute your own modules. Distutils 1.0 is the version that will be released with Python 2.0 (unless last-minute bugs pop up). More information is available at the Distutils web page: http://www.python.org/sigs/distutils-sig/ and in the README.txt included in the Distutils source distribution. You can download the Distutils from http://www.python.org/sigs/distutils-sig/download.html Trivial patches can be sent to me (Greg Ward) at gward@python.net. Larger patches should be discussed on the Distutils mailing list: distutils-sig@python.org. Greg -- Greg Ward gward@python.net http://starship.python.net/~gward/ And now for something completely different. From Joerg.Baumann@stud.informatik.uni-erlangen.de Fri Oct 6 08:24:02 2000 From: Joerg.Baumann@stud.informatik.uni-erlangen.de (Joerg Baumann) Date: Fri Oct 6 07:24:02 2000 Subject: [Distutils] Better SWIG C++ support Message-ID: Hi, I had troubles with distutils 1.0 and the way I use SWIG. I couldn't find any support for the -shadow option and no way to pass an extra include dir to swig (like it=B4s possible for the c compiler) Therefore I wrote a patch. It adds an extra_swig_args (list of string) option to Extension. All the strings are passed to swig without modification, but if extra_swig_args contains "-c++" or "-shadow" there is some special action: "-c++": behaves like build_ext --swig-cpp "-shadow": Normally swig generates a file: foo.c -> foo.so=20 In this case SWIG generates two files: foo.py (python shadow classes, imports fooc) fooc.c -> fooc.so With this patch build_ext can handle this und generates for foo.i (foo.py, fooc.c) compiles them and installs them.=20 =20 Below is the diff against disutils 1.0, apply in your Distutils-1.0 directory with: patch -p5 < file I hope it doesn=B4t break anything, isn=B4t against distutils design principles and is so useful that it might become part of distutils. Please answer me directly, because I didn=B4t not subscribe ths list. Regards=20 joerg =20 Joerg Baumann joerg.baumann@stud.informatik.uni-erlangen.de +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Beware of bugs in the above code; I have only proved it correct,=20 not tried it. Don Knuth=20 diff -r -C 2 -x *pyc /home/jgbauman/download/Distutils-1.0/distutils/comman= d/build_ext.py ./command/build_ext.py *** /home/jgbauman/download/Distutils-1.0/distutils/command/build_ext.py=09= Sat Sep 30 20:27:54 2000 --- ./command/build_ext.py=09Fri Oct 6 01:23:08 2000 *************** *** 386,390 **** # SWIG on 'em to create .c files, and modify the sources list # accordingly. ! sources =3D self.swig_sources(sources) =20 # Next, compile the source code to object files. --- 386,398 ---- # SWIG on 'em to create .c files, and modify the sources list # accordingly. ! sources,extra_modules =3D self.swig_sources(sources,ext.extra= _swig_args) ! =20 ! # if there are extra_modules after running swig due to -shado= w option ! # copy them to build/lib.xxx ! for module in extra_modules: ! outfile =3D os.path.join(self.build_lib,os.path.basename(= module)) ! dir =3D os.path.dirname(outfile) ! self.mkpath(dir) ! self.copy_file(module, outfile, preserve_mode=3D0) =20 # Next, compile the source code to object files. *************** *** 444,448 **** =20 =20 ! def swig_sources (self, sources): =20 """Walk the list of source files in 'sources', looking for SWIG --- 452,456 ---- =20 =20 ! def swig_sources (self, sources, extra_swig_args): =20 """Walk the list of source files in 'sources', looking for SWIG *************** *** 453,456 **** --- 461,465 ---- =20 new_sources =3D [] + new_modules =3D [] swig_sources =3D [] swig_targets =3D {} *************** *** 461,464 **** --- 470,479 ---- # the temp dir. =20 + if "-c++" in extra_swig_args:=20 + self.swig_cpp=3D1 + if "-shadow" in extra_swig_args:=20 + shadow=3D1 + else: + shadow=3DNone if self.swig_cpp: target_ext =3D '.cpp' *************** *** 469,473 **** (base, ext) =3D os.path.splitext(source) if ext =3D=3D ".i": # SWIG interface file ! new_sources.append(base + target_ext) swig_sources.append(source) swig_targets[source] =3D new_sources[-1] --- 484,492 ---- (base, ext) =3D os.path.splitext(source) if ext =3D=3D ".i": # SWIG interface file ! if shadow:=20 ! new_modules.append(base + ".py") ! new_sources.append(base + "c" + target_ext) ! else: ! new_sources.append(base + target_ext) swig_sources.append(source) swig_targets[source] =3D new_sources[-1] *************** *** 476,480 **** =20 if not swig_sources: ! return new_sources =20 swig =3D self.find_swig() --- 495,499 ---- =20 if not swig_sources: ! return new_sources,new_modules =20 swig =3D self.find_swig() *************** *** 482,486 **** if self.swig_cpp: swig_cmd.append("-c++") !=20 for source in swig_sources: target =3D swig_targets[source] --- 501,507 ---- if self.swig_cpp: swig_cmd.append("-c++") ! for arg in extra_swig_args: ! swig_cmd.append(arg) ! =20 for source in swig_sources: target =3D swig_targets[source] *************** *** 488,492 **** self.spawn(swig_cmd + ["-o", target, source]) =20 ! return new_sources =20 # swig_sources () --- 509,513 ---- self.spawn(swig_cmd + ["-o", target, source]) =20 ! return new_sources,new_modules =20 # swig_sources () diff -r -C 2 -x *pyc /home/jgbauman/download/Distutils-1.0/distutils/comman= d/install_lib.py ./command/install_lib.py *** /home/jgbauman/download/Distutils-1.0/distutils/command/install_lib.py= =09Tue Oct 3 05:32:37 2000 --- ./command/install_lib.py=09Fri Oct 6 01:11:21 2000 *************** *** 90,94 **** =20 # (Optionally) compile .py to .pyc ! if outfiles is not None and self.distribution.has_pure_modules(): self.byte_compile(outfiles) =20 --- 90,94 ---- =20 # (Optionally) compile .py to .pyc ! if outfiles is not None: self.byte_compile(outfiles) =20 diff -r -C 2 -x *pyc /home/jgbauman/download/Distutils-1.0/distutils/extens= ion.py ./extension.py *** /home/jgbauman/download/Distutils-1.0/distutils/extension.py=09Sun Sep = 17 02:45:18 2000 --- ./extension.py=09Fri Oct 6 01:18:12 2000 *************** *** 74,78 **** extensions, which typically export exactly one symbol: "init" + extension_name. ! """ =20 def __init__ (self, name, sources, --- 74,84 ---- extensions, which typically export exactly one symbol: "init" + extension_name. ! extra_swig_args : [string] ! any additional options for the swig tool. Unknown options will ! be passed unchanged. ! Known options: ! -c++: enable swig=B4s C++ support ! -shadow: generate shadow classes in python ! """ =20 def __init__ (self, name, sources, *************** *** 87,90 **** --- 93,97 ---- extra_link_args=3DNone, export_symbols=3DNone, + extra_swig_args=3DNone, ): =20 *************** *** 106,109 **** --- 113,117 ---- self.extra_link_args =3D extra_link_args or [] self.export_symbols =3D export_symbols or [] + self.extra_swig_args =3D extra_swig_args or [] =20 # class Extension =20 From Joerg.Baumann@stud.informatik.uni-erlangen.de Fri Oct 6 08:25:28 2000 From: Joerg.Baumann@stud.informatik.uni-erlangen.de (Joerg Baumann) Date: Fri Oct 6 07:25:28 2000 Subject: [Distutils] Better SWIG C++ support (fwd) Message-ID: Hi, I had troubles with distutils 1.0 and the way I use SWIG. I couldn't find any support for the -shadow option and no way to pass an extra include dir to swig (like it=B4s possible for the c compiler) Therefore I wrote a patch. It adds an extra_swig_args (list of string) option to Extension. All the strings are passed to swig without modification, but if extra_swig_args contains "-c++" or "-shadow" there is some special action: "-c++": behaves like build_ext --swig-cpp "-shadow": Normally swig generates a file: foo.c -> foo.so=20 In this case SWIG generates two files: foo.py (python shadow classes, imports fooc) fooc.c -> fooc.so With this patch build_ext can handle this und generates for foo.i (foo.py, fooc.c) compiles them and installs them.=20 =20 Below is the diff against disutils 1.0, apply in your Distutils-1.0 directory with: patch -p5 < file I hope it doesn=B4t break anything, isn=B4t against distutils design principles and is so useful that it might become part of distutils. Please answer me directly, because I didn=B4t not subscribe ths list. Regards=20 joerg =20 Joerg Baumann joerg.baumann@stud.informatik.uni-erlangen.de +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Beware of bugs in the above code; I have only proved it correct,=20 not tried it. Don Knuth=20 diff -r -C 2 -x *pyc /home/jgbauman/download/Distutils-1.0/distutils/comman= d/build_ext.py ./command/build_ext.py *** /home/jgbauman/download/Distutils-1.0/distutils/command/build_ext.py=09= Sat Sep 30 20:27:54 2000 --- ./command/build_ext.py=09Fri Oct 6 01:23:08 2000 *************** *** 386,390 **** # SWIG on 'em to create .c files, and modify the sources list # accordingly. ! sources =3D self.swig_sources(sources) =20 # Next, compile the source code to object files. --- 386,398 ---- # SWIG on 'em to create .c files, and modify the sources list # accordingly. ! sources,extra_modules =3D self.swig_sources(sources,ext.extra= _swig_args) ! =20 ! # if there are extra_modules after running swig due to -shado= w option ! # copy them to build/lib.xxx ! for module in extra_modules: ! outfile =3D os.path.join(self.build_lib,os.path.basename(= module)) ! dir =3D os.path.dirname(outfile) ! self.mkpath(dir) ! self.copy_file(module, outfile, preserve_mode=3D0) =20 # Next, compile the source code to object files. *************** *** 444,448 **** =20 =20 ! def swig_sources (self, sources): =20 """Walk the list of source files in 'sources', looking for SWIG --- 452,456 ---- =20 =20 ! def swig_sources (self, sources, extra_swig_args): =20 """Walk the list of source files in 'sources', looking for SWIG *************** *** 453,456 **** --- 461,465 ---- =20 new_sources =3D [] + new_modules =3D [] swig_sources =3D [] swig_targets =3D {} *************** *** 461,464 **** --- 470,479 ---- # the temp dir. =20 + if "-c++" in extra_swig_args:=20 + self.swig_cpp=3D1 + if "-shadow" in extra_swig_args:=20 + shadow=3D1 + else: + shadow=3DNone if self.swig_cpp: target_ext =3D '.cpp' *************** *** 469,473 **** (base, ext) =3D os.path.splitext(source) if ext =3D=3D ".i": # SWIG interface file ! new_sources.append(base + target_ext) swig_sources.append(source) swig_targets[source] =3D new_sources[-1] --- 484,492 ---- (base, ext) =3D os.path.splitext(source) if ext =3D=3D ".i": # SWIG interface file ! if shadow:=20 ! new_modules.append(base + ".py") ! new_sources.append(base + "c" + target_ext) ! else: ! new_sources.append(base + target_ext) swig_sources.append(source) swig_targets[source] =3D new_sources[-1] *************** *** 476,480 **** =20 if not swig_sources: ! return new_sources =20 swig =3D self.find_swig() --- 495,499 ---- =20 if not swig_sources: ! return new_sources,new_modules =20 swig =3D self.find_swig() *************** *** 482,486 **** if self.swig_cpp: swig_cmd.append("-c++") !=20 for source in swig_sources: target =3D swig_targets[source] --- 501,507 ---- if self.swig_cpp: swig_cmd.append("-c++") ! for arg in extra_swig_args: ! swig_cmd.append(arg) ! =20 for source in swig_sources: target =3D swig_targets[source] *************** *** 488,492 **** self.spawn(swig_cmd + ["-o", target, source]) =20 ! return new_sources =20 # swig_sources () --- 509,513 ---- self.spawn(swig_cmd + ["-o", target, source]) =20 ! return new_sources,new_modules =20 # swig_sources () diff -r -C 2 -x *pyc /home/jgbauman/download/Distutils-1.0/distutils/comman= d/install_lib.py ./command/install_lib.py *** /home/jgbauman/download/Distutils-1.0/distutils/command/install_lib.py= =09Tue Oct 3 05:32:37 2000 --- ./command/install_lib.py=09Fri Oct 6 01:11:21 2000 *************** *** 90,94 **** =20 # (Optionally) compile .py to .pyc ! if outfiles is not None and self.distribution.has_pure_modules(): self.byte_compile(outfiles) =20 --- 90,94 ---- =20 # (Optionally) compile .py to .pyc ! if outfiles is not None: self.byte_compile(outfiles) =20 diff -r -C 2 -x *pyc /home/jgbauman/download/Distutils-1.0/distutils/extens= ion.py ./extension.py *** /home/jgbauman/download/Distutils-1.0/distutils/extension.py=09Sun Sep = 17 02:45:18 2000 --- ./extension.py=09Fri Oct 6 01:18:12 2000 *************** *** 74,78 **** extensions, which typically export exactly one symbol: "init" + extension_name. ! """ =20 def __init__ (self, name, sources, --- 74,84 ---- extensions, which typically export exactly one symbol: "init" + extension_name. ! extra_swig_args : [string] ! any additional options for the swig tool. Unknown options will ! be passed unchanged. ! Known options: ! -c++: enable swig=B4s C++ support ! -shadow: generate shadow classes in python ! """ =20 def __init__ (self, name, sources, *************** *** 87,90 **** --- 93,97 ---- extra_link_args=3DNone, export_symbols=3DNone, + extra_swig_args=3DNone, ): =20 *************** *** 106,109 **** --- 113,117 ---- self.extra_link_args =3D extra_link_args or [] self.export_symbols =3D export_symbols or [] + self.extra_swig_args =3D extra_swig_args or [] =20 # class Extension =20 From robin@alldunn.com Sat Oct 7 17:08:02 2000 From: robin@alldunn.com (Robin Dunn) Date: Sat Oct 7 16:08:02 2000 Subject: [Distutils] Distutilizing wxPython Message-ID: <062b01c0309a$1a7fe4e0$0b01a8c0@ARES> I'm finally going to the effort to convert to using distutils for wxPython. So far, so good, I have the core extension module being built for win32. One problem that I ran into is that the resource compiler needs to have the -I and -D flags passed to it. The little patch below did the trick for me. One problem/question I have at this point is that the secondary extension modules need to link with the implib produced when linking the core extension module. Is there a way to determine before setup() is called where that library will be put so I can add that directory to the library_dirs for the other Extensions? (For example, "build/temp.win32-1.5/Release/src/") 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/10/07 20:00:47 *************** *** 313,319 **** input_opt = src output_opt = "/fo" + obj try: ! self.spawn ([self.rc] + [output_opt] + [input_opt]) except DistutilsExecError, msg: raise CompileError, msg --- 313,319 ---- input_opt = src output_opt = "/fo" + obj try: ! self.spawn ([self.rc] + pp_opts + [output_opt] + [input_opt]) except DistutilsExecError, msg: raise CompileError, msg -- Robin Dunn Software Craftsman robin@AllDunn.com http://wxPython.org Java give you jitters? http://wxPROs.com Relax with wxPython! From loewis@informatik.hu-berlin.de Sun Oct 8 10:56:24 2000 From: loewis@informatik.hu-berlin.de (Martin von Loewis) Date: Sun Oct 8 09:56:24 2000 Subject: [Distutils] bdist_wininst creates corrupt installation Message-ID: <200010081355.PAA09144@pandora.informatik.hu-berlin.de> I've created a PyXML distribution with recent distutils (0.93 and 1.0). When installing these distributions, the installer creates empty files only, see http://download.sourceforge.net/pyxml/PyXML-0.6.0.win32.exe for an example. I've tracked this down to usage of the zipfile module. If it does not find an external zip program (which I did not have), it then tries to use the zipfile module. Somehow, the installation program later cannot process the files created with that module. The problem is probably in the installer, since Winzip 7 is capable of reading the package, and extracts the files properly. I have solved the problem by installing infozip on my machine. However, I'd appreciate if somebody could look into the problem and let me know what the cause is. If you cannot reproduce the problem, please let me know as well. Regards, Martin From thomas.heller@ion-tof.com Mon Oct 9 11:01:01 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Mon Oct 9 10:01:01 2000 Subject: [Distutils] bdist_wininst creates corrupt installation References: <200010081355.PAA09144@pandora.informatik.hu-berlin.de> Message-ID: <007c01c031f9$1e925c60$4500a8c0@thomasnotebook> I'm looking into this problem. Thomas ----- Original Message ----- From: "Martin von Loewis" To: Sent: Sunday, October 08, 2000 3:55 PM Subject: [Distutils] bdist_wininst creates corrupt installation > I've created a PyXML distribution with recent distutils (0.93 and > 1.0). When installing these distributions, the installer creates empty > files only, see > > http://download.sourceforge.net/pyxml/PyXML-0.6.0.win32.exe > > for an example. > > I've tracked this down to usage of the zipfile module. If it does not > find an external zip program (which I did not have), it then tries to > use the zipfile module. Somehow, the installation program later cannot > process the files created with that module. > > The problem is probably in the installer, since Winzip 7 is capable of > reading the package, and extracts the files properly. > > I have solved the problem by installing infozip on my > machine. However, I'd appreciate if somebody could look into the > problem and let me know what the cause is. If you cannot reproduce the > problem, please let me know as well. > > Regards, > Martin > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://www.python.org/mailman/listinfo/distutils-sig From thomas.heller@ion-tof.com Mon Oct 9 13:20:15 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Mon Oct 9 12:20:15 2000 Subject: [Distutils] bdist_wininst creates corrupt installation References: <200010081355.PAA09144@pandora.informatik.hu-berlin.de> Message-ID: <014401c0320c$a12903f0$4500a8c0@thomasnotebook> This is a multi-part message in MIME format. ------=_NextPart_000_0141_01C0321D.61154C40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit [Martin von Loewis] > I've created a PyXML distribution with recent distutils (0.93 and > 1.0). When installing these distributions, the installer creates empty > files only, see > > http://download.sourceforge.net/pyxml/PyXML-0.6.0.win32.exe > > for an example. > > I've tracked this down to usage of the zipfile module. If it does not > find an external zip program (which I did not have), it then tries to > use the zipfile module. Somehow, the installation program later cannot > process the files created with that module. > > The problem is probably in the installer, since Winzip 7 is capable of > reading the package, and extracts the files properly. > > I have solved the problem by installing infozip on my > machine. However, I'd appreciate if somebody could look into the > problem and let me know what the cause is. If you cannot reproduce the > problem, please let me know as well. > The problem was that the windows installer was using zipfile datastructures which are not always set. The following patch fixes this problem. Since currently I cannot check in these changes, I'm posting them here so they do not get lost. Note that wininst.exe must be recompiled and bdist_wininst.py must be regenerated to complete the fix. Thomas ------=_NextPart_000_0141_01C0321D.61154C40 Content-Type: text/plain; name="diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="diff.txt" Index: misc/archive.h =================================================================== RCS file: /cvsroot/python/distutils/misc/archive.h,v retrieving revision 1.2 diff -c -r1.2 archive.h *** misc/archive.h 2000/09/07 07:36:40 1.2 --- misc/archive.h 2000/10/09 16:14:42 *************** *** 59,70 **** typedef int (*NOTIFYPROC)(int code, LPSTR text, ...); ! extern BOOL extract_file (char *dst, struct fhdr *phdr, char *src, ! NOTIFYPROC callback); extern BOOL unzip_archive (char *dirname, char *data, DWORD size, NOTIFYPROC callback); extern char *map_new_file (DWORD flags, char *filename, char ! *pathname_part, struct fhdr *pfhdr, NOTIFYPROC callback); extern BOOL ensure_directory (char *pathname, char *new_part, NOTIFYPROC callback); --- 59,71 ---- typedef int (*NOTIFYPROC)(int code, LPSTR text, ...); ! extern BOOL extract_file (char *dst, char *src, int method, int comp_size, ! int uncomp_size, NOTIFYPROC notify); extern BOOL unzip_archive (char *dirname, char *data, DWORD size, NOTIFYPROC callback); extern char *map_new_file (DWORD flags, char *filename, char ! *pathname_part, int size, ! WORD wFatDate, WORD wFatTime, NOTIFYPROC callback); extern BOOL ensure_directory (char *pathname, char *new_part, NOTIFYPROC callback); Index: misc/extract.c =================================================================== RCS file: /cvsroot/python/distutils/misc/extract.c,v retrieving revision 1.3 diff -c -r1.3 extract.c *** misc/extract.c 2000/09/29 11:20:55 1.3 --- misc/extract.c 2000/10/09 16:14:42 *************** *** 46,57 **** * uncomp_size and file_times instead of pfhdr! */ char *map_new_file (DWORD flags, char *filename, ! char *pathname_part, struct fhdr *pfhdr, NOTIFYPROC notify) { HANDLE hFile, hFileMapping; char *dst; - int size = pfhdr->uncomp_size; FILETIME ft; try_again: --- 46,57 ---- * uncomp_size and file_times instead of pfhdr! */ char *map_new_file (DWORD flags, char *filename, ! char *pathname_part, int size, ! WORD wFatDate, WORD wFatTime, NOTIFYPROC notify) { HANDLE hFile, hFileMapping; char *dst; FILETIME ft; try_again: *************** *** 98,105 **** if (notify) notify (FILE_CREATED, filename); ! DosDateTimeToFileTime (pfhdr->last_mod_file_date, ! pfhdr->last_mod_file_time, &ft); SetFileTime (hFile, &ft, &ft, &ft); --- 98,104 ---- if (notify) notify (FILE_CREATED, filename); ! DosDateTimeToFileTime (wFatDate, wFatTime, &ft); SetFileTime (hFile, &ft, &ft, &ft); *************** *** 136,153 **** BOOL ! extract_file (char *dst, struct fhdr *phdr, char *src, NOTIFYPROC notify) { z_stream zstream; int result; ! if (phdr->method == Z_DEFLATED) { int x; memset (&zstream, 0, sizeof (zstream)); zstream.next_in = src; ! zstream.avail_in = phdr->comp_size+1; zstream.next_out = dst; ! zstream.avail_out = phdr->uncomp_size; /* Apparently an undocumented feature of zlib: Set windowsize to negative values to supress the gzip header and be compatible with --- 135,153 ---- BOOL ! extract_file (char *dst, char *src, int method, int comp_size, ! int uncomp_size, NOTIFYPROC notify) { z_stream zstream; int result; ! if (method == Z_DEFLATED) { int x; memset (&zstream, 0, sizeof (zstream)); zstream.next_in = src; ! zstream.avail_in = comp_size+1; zstream.next_out = dst; ! zstream.avail_out = uncomp_size; /* Apparently an undocumented feature of zlib: Set windowsize to negative values to supress the gzip header and be compatible with *************** *** 170,177 **** notify (ZLIB_ERROR, "inflateEnd returns %d", x); result = FALSE; } ! } else if (phdr->method == 0) { ! memcpy(dst, src, phdr->uncomp_size); result = TRUE; } else result = FALSE; --- 170,177 ---- notify (ZLIB_ERROR, "inflateEnd returns %d", x); result = FALSE; } ! } else if (method == 0) { ! memcpy(dst, src, uncomp_size); result = TRUE; } else result = FALSE; *************** *** 233,241 **** strncat (pathname, fname, pfhdr->fname_length); fixpath (pathname); if (pathname[strlen(pathname)-1] != '\\') { ! dst = map_new_file (0, pathname, new_part, pfhdr, notify); if (dst) { ! if (!extract_file (dst, pfhdr, pcomp, notify)) return FALSE; } /* else ??? */ } --- 233,253 ---- strncat (pathname, fname, pfhdr->fname_length); fixpath (pathname); if (pathname[strlen(pathname)-1] != '\\') { ! /* ! * The local file header (pfhdr) does not always contain ! * the compressed and uncompressed sizes of the data ! * depending on bit 3 of the flags field. ! * So it seems better to use the data from the ! * central directory (pcdir). ! */ ! dst = map_new_file (0, pathname, new_part, ! pcdir->uncomp_size, ! pcdir->last_mod_file_date, ! pcdir->last_mod_file_time, notify); if (dst) { ! if (!extract_file (dst, pcomp, pfhdr->method, ! pcdir->comp_size, pcdir->uncomp_size, ! notify)) return FALSE; } /* else ??? */ } Index: misc/install.c =================================================================== RCS file: /cvsroot/python/distutils/misc/install.c,v retrieving revision 1.7 diff -c -r1.7 install.c *** misc/install.c 2000/09/29 11:28:41 1.7 --- misc/install.c 2000/10/09 16:14:43 *************** *** 356,362 **** /* read meta_data info */ struct meta_data_hdr *pmd = (struct meta_data_hdr *)&data[ofs]; - struct fhdr fhdr; char *src, *dst; char *ini_file; char tempdir[MAX_PATH]; --- 356,361 ---- *************** *** 381,388 **** return NULL; } ! fhdr.uncomp_size = pmd->uncomp_size; ! dst = map_new_file (CREATE_ALWAYS, ini_file, NULL, &fhdr, notify); if (!dst) return NULL; memcpy (dst, src, pmd->uncomp_size); --- 380,387 ---- return NULL; } ! dst = map_new_file (CREATE_ALWAYS, ini_file, NULL, pmd->uncomp_size, ! 0, 0, notify); if (!dst) return NULL; memcpy (dst, src, pmd->uncomp_size); ------=_NextPart_000_0141_01C0321D.61154C40-- From thomas.heller@ion-tof.com Mon Oct 9 14:06:26 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Mon Oct 9 13:06:26 2000 Subject: [Distutils] Distutilizing wxPython References: <062b01c0309a$1a7fe4e0$0b01a8c0@ARES> Message-ID: <017e01c03212$ebd48ef0$4500a8c0@thomasnotebook> > I'm finally going to the effort to convert to using distutils for wxPython. > So far, so good, I have the core extension module being built for win32. > One problem that I ran into is that the resource compiler needs to have > the -I and -D flags passed to it. The little patch below did the trick for > me. There should probably be separate flags for the C-compiler and the resource compiler. > > One problem/question I have at this point is that the secondary extension > modules need to link with the implib produced when linking the core > extension module. Is there a way to determine before setup() is called > where that library will be put so I can add that directory to the > library_dirs for the other Extensions? (For example, > "build/temp.win32-1.5/Release/src/") Yes, I also had this problem with a setup script for Mark's win32all modules. IMHO, the import libraries should go into "build/temp.win32-1.5". There is no use in different directories for Release and Debug builds, because the file names are already different. Retrieving the name of this directory (from the build_ext command) is more difficult. The previous 'solutions' are known to the distutils crowd as the "build_ext hack for MSVC". (Although it is not a MSVC problem, it is a windows problem. AFAIK there are no import libraries on unix) Thomas From calvin@cs.uni-sb.de Tue Oct 10 07:07:03 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Tue Oct 10 06:07:03 2000 Subject: [Distutils] Patch to config::check_lib() In-Reply-To: <20001005114024.A25460@vanderbilt.edu> Message-ID: Hi, this is a patch to make check_lib more like AC_CHECK_LIB. Sometimes you need additional libraries to compile programs. Bastian diff -BurN --exclude=*.pyc distutils/distutils/command/config.py distutils.patched/distutils/command/config.py --- distutils/distutils/command/config.py Mon Oct 9 23:28:37 2000 +++ distutils.patched/distutils/command/config.py Tue Oct 10 11:07:17 2000 @@ -310,7 +310,7 @@ # check_func () def check_lib (self, library, library_dirs=None, - headers=None, include_dirs=None): + headers=None, include_dirs=None, other_libraries=[]): """Determine if 'library' is available to be linked against, without actually checking that any particular symbols are provided by it. 'headers' will be used in constructing the source file to @@ -319,7 +319,8 @@ """ self._check_compiler() return self.try_link("int main (void) { }", - headers, include_dirs, [library], library_dirs) + headers, include_dirs, + [library]+other_libraries, library_dirs) def check_header (self, header, include_dirs=None, library_dirs=None, lang="c"): From Roy Dragseth Thu Oct 12 04:37:01 2000 From: Roy Dragseth (Roy Dragseth) Date: Thu Oct 12 03:37:01 2000 Subject: [Distutils] Bug/problem in v1.0 with python 1.6. Message-ID: <200010120736.JAA29270@paiute.cc.uit.no> Hi, I'm trying to build an extension written in c on a system with the following characteristics: OS: HP-UX 10.20 Python: v1.6 Distutils: v1.0 gcc: v2.95.2 with hp-ux ld (not gnu ld) Python is built with gcc, and the problem is that gcc --shared doesn't work (ok, this is probably me messing up gcc). Python seems to be aware of this as it builds the shared modules using ld -b directly, shouldn't distutils do the same thing? It used to, I had no problem building this extension with python 1.5.2 and distutils 0.8.2. Any hints greatly appreciated, Roy. The Computer Center, University of Tromsø, N-9037 TROMSØ, Norway. phone:+47 77 64 41 07, fax:+47 77 64 41 00 Roy Dragseth, High Perfomance Computing System Administrator Direct call: +47 77 64 62 56. email: royd@cc.uit.no From Roy Dragseth Thu Oct 12 05:43:01 2000 From: Roy Dragseth (Roy Dragseth) Date: Thu Oct 12 04:43:01 2000 Subject: [Distutils] Bug/problem in v1.0 with python 1.6. In-Reply-To: Your message of Thu, 12 Oct 2000 09:36:02 +0200 Message-ID: <200010120842.KAA29426@paiute.cc.uit.no> Err, the reported problem wasn't in distutils. It's our software distribution system called store that overwrote the Makefile for hpux in config/ with the linux Makefile. Sorry to waste your time on this (am I blushing?). roy. The Computer Center, University of Tromsø, N-9037 TROMSØ, Norway. phone:+47 77 64 41 07, fax:+47 77 64 41 00 Roy Dragseth, High Perfomance Computing System Administrator Direct call: +47 77 64 62 56. email: royd@cc.uit.no From calvin@cs.uni-sb.de Thu Oct 12 12:12:02 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Thu Oct 12 11:12:02 2000 Subject: [Distutils] patch for config::finalize_options Message-ID: This patch fixes up any supplied command line options. Bastian diff -BurN --exclude=*.pyc distutils/distutils/command/config.py distutils.patched/distutils/command/config.py --- distutils/distutils/command/config.py Mon Oct 9 23:28:37 2000 +++ distutils.patched/distutils/command/config.py Thu Oct 12 17:06:20 2000 @@ -14,6 +14,7 @@ __revision__ = "$Id: config.py,v 1.4 2000/09/30 18:27:54 gward Exp $" import sys, os, string, re +from types import * from distutils.core import Command from distutils.errors import DistutilsExecError @@ -69,7 +70,22 @@ self.temp_files = [] def finalize_options (self): - pass + """fix up types of option values""" + if self.include_dirs is None: + self.include_dirs = self.distribution.include_dirs or [] + elif type(self.include_dirs) is StringType: + self.include_dirs = string.split(self.include_dirs, os.pathsep) + + if self.libraries is None: + self.libraries = [] + elif type(self.libraries) is StringType: + self.libraries = [self.libraries] + + if self.library_dirs is None: + self.library_dirs = [] + elif type(self.library_dirs) is StringType: + self.library_dirs = [self.library_dirs] + def run (self): pass From ljohnson@resgen.com Fri Oct 13 10:09:01 2000 From: ljohnson@resgen.com (Lyle Johnson) Date: Fri Oct 13 09:09:01 2000 Subject: [Distutils] Patch for install.py from Distutils-1.0 Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C034ED.3F322BC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit On Windows one will often get the warning message "warning: install: modules installed to 'c:\Python20\', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself", even though the named directory is in fact in the user's PYTHONPATH. The problem is that the install command is using a case-sensitive comparision of the path names and Python reports this path entry as "c:\python20" (note the lowercase "p"). So the comparison fails and the install command emits this false warning. The attached patch to the current cvs version of install.py should correct the problem. ------=_NextPart_000_0002_01C034ED.3F322BC0 Content-Type: application/octet-stream; name="install.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="install.diff" Index: distutils/command/install.py =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsroot/python/distutils/distutils/command/install.py,v retrieving revision 1.52 diff -c -r1.52 install.py *** distutils/command/install.py 2000/10/03 03:31:52 1.52 --- distutils/command/install.py 2000/10/13 13:00:45 *************** *** 498,506 **** self.record) =20 normalized_path =3D map(os.path.normpath, sys.path) if (self.warn_dir and not (self.path_file and self.install_path_file) and ! os.path.normpath(self.install_lib) not in = normalized_path): self.warn(("modules installed to '%s', which is not in " + "Python's module search path (sys.path) -- " + "you'll have to change the search path = yourself") % --- 498,507 ---- self.record) =20 normalized_path =3D map(os.path.normpath, sys.path) + normalized_path =3D map(os.path.normcase, normalized_path) if (self.warn_dir and not (self.path_file and self.install_path_file) and ! os.path.normcase(os.path.normpath(self.install_lib)) not = in normalized_path): self.warn(("modules installed to '%s', which is not in " + "Python's module search path (sys.path) -- " + "you'll have to change the search path = yourself") % ------=_NextPart_000_0002_01C034ED.3F322BC0-- From gward@python.net Sat Oct 14 00:31:01 2000 From: gward@python.net (Greg Ward) Date: Fri Oct 13 23:31:01 2000 Subject: [Distutils] Distutilizing wxPython In-Reply-To: <017e01c03212$ebd48ef0$4500a8c0@thomasnotebook>; from thomas.heller@ion-tof.com on Mon, Oct 09, 2000 at 07:03:56PM +0200 References: <062b01c0309a$1a7fe4e0$0b01a8c0@ARES> <017e01c03212$ebd48ef0$4500a8c0@thomasnotebook> Message-ID: <20001013232828.A987@beelzebub> On 09 October 2000, Thomas Heller said: > There should probably be separate flags for the C-compiler > and the resource compiler. Is that really necessary? Robin's patch seems OK to me, except that it only fixes MSVCCompiler -- presumably the Borland compiler class should get similar treatment. When would you need separate -I and -D options for the resource compiler? > Yes, I also had this problem with a setup script for Mark's win32all > modules. > IMHO, the import libraries should go into "build/temp.win32-1.5". > There is no use in different directories for Release and Debug builds, > because the file names are already different. OK, I'll bite: what the heck *is* an import library, and why are they needed? Are they produced by the compiler, the linker, or something else? Are they needed to produce static libraries, shared libraries (DLLs), executables, or something else? Are they pecular to Microsoft's compiler or do all Windows compilers have something similar? > (Although it is not a MSVC problem, it is a windows problem. Oh, I guess that answers my last question. > AFAIK there are no import libraries on unix) The only kind of libraries I know of are shared and static. Greg -- Greg Ward gward@python.net http://starship.python.net/~gward/ From gward@python.net Sat Oct 14 00:38:01 2000 From: gward@python.net (Greg Ward) Date: Fri Oct 13 23:38:01 2000 Subject: [Distutils] patch for config::finalize_options In-Reply-To: ; from calvin@cs.uni-sb.de on Thu, Oct 12, 2000 at 05:10:34PM +0200 References: Message-ID: <20001013233532.B987@beelzebub> On 12 October 2000, Bastian Kleineidam said: > This patch fixes up any supplied command line options. Seems harmless to me. Why is it needed now, though? The "config" command is nice, but useless in practice until I finish it... Greg From gward@python.net Sat Oct 14 00:40:01 2000 From: gward@python.net (Greg Ward) Date: Fri Oct 13 23:40:01 2000 Subject: [Distutils] patch for config::finalize_options In-Reply-To: ; from calvin@cs.uni-sb.de on Thu, Oct 12, 2000 at 05:10:34PM +0200 References: Message-ID: <20001013233803.C987@beelzebub> On 12 October 2000, Bastian Kleineidam said: > This patch fixes up any supplied command line options. No wait, I still think it's harmless, but it's inconsistent: include_dirs is treated as a os.pathsep-delimited string, but library_dirs is not. Why not? Greg From gward@python.net Sat Oct 14 00:54:01 2000 From: gward@python.net (Greg Ward) Date: Fri Oct 13 23:54:01 2000 Subject: [Distutils] Watch those tabs! Message-ID: <20001013235228.A4529@beelzebub> Hi all -- when submitting patches, please be sure that no evil tabs sneak in! I've just noticed that there are several Distutils source files with the dreaded ^I in them. I need to be more vigilant in fixing tabs when I apply patches, and patch authors need to be more vigilant about not letting them into their patches in the first place. Remember, (setq-default indent-tabs-mode nil) is your friend! Greg (What, you mean there are editors other than Emacs in the world? Nawwww...) -- Greg Ward gward@python.net http://starship.python.net/~gward/ From gward@python.net Sat Oct 14 00:58:02 2000 From: gward@python.net (Greg Ward) Date: Fri Oct 13 23:58:02 2000 Subject: [Distutils] Patch to config::check_lib() In-Reply-To: ; from calvin@cs.uni-sb.de on Tue, Oct 10, 2000 at 12:04:59PM +0200 References: <20001005114024.A25460@vanderbilt.edu> Message-ID: <20001013235549.D987@beelzebub> On 10 October 2000, Bastian Kleineidam said: > this is a patch to make check_lib more like AC_CHECK_LIB. Sometimes you > need additional libraries to compile programs. Good catch -- thanks. Checked in. Greg From robin@alldunn.com Sat Oct 14 01:18:01 2000 From: robin@alldunn.com (Robin Dunn) Date: Sat Oct 14 00:18:01 2000 Subject: [Distutils] Distutilizing wxPython References: <062b01c0309a$1a7fe4e0$0b01a8c0@ARES> <017e01c03212$ebd48ef0$4500a8c0@thomasnotebook> <20001013232828.A987@beelzebub> Message-ID: <001b01c03595$9332e7c0$0b01a8c0@ARES> > OK, I'll bite: what the heck *is* an import library, and why are they > needed? Are they produced by the compiler, the linker, or something > else? Are they needed to produce static libraries, shared libraries > (DLLs), executables, or something else? When you link together a DLL you also make an import library which defines all the exported symbols in the DLL that can be imported into other code. I believe that it also defines how to find the symbol in the DLL, an offset or ordinal or something like that. When you are linking code that uses the DLL you don't link with the DLL itself (like you do on Unix by linking with the .so) but with the import library instead. -- Robin Dunn Software Craftsman robin@AllDunn.com http://wxPython.org Java give you jitters? http://wxPROs.com Relax with wxPython! From gward@python.net Sat Oct 14 01:18:05 2000 From: gward@python.net (Greg Ward) Date: Sat Oct 14 00:18:05 2000 Subject: [Distutils] New snapshot Message-ID: <20001014001618.A4860@beelzebub> Hi all -- I'm uploading a new Distutils code snapshot; the only real important change is Thomas' fix for the problems with zipfile.py-generated ZIP files with the Windows installer. Also checked in the recent patches to config.py and install.py (thanks to Bastian and Lyle!). Here's the provisional changelog for Distutils 1.0.1 -- if there are no problems with this snapshot, it will become Distutils 1.0.1 sometime this weekend. Relase 1.0.1 (?? October, 2000): -------------------------------- * fixed Windows installer to deal with ZIP files created by the zipfile module better (Thomas Heller) * fixed install command's spurious warnings on Windows (due to case-sensitive filename comparison) * two tweaks to the (experimental, unfinished) config command: make 'check_lib()' more like AC_CHECK_LIB, and make sure any command-line options are the right type The code snapshot is at the usual place... http://www.python.org/sigs/distutils-sig/download.html Greg -- Greg Ward gward@python.net http://starship.python.net/~gward/ From gward@python.net Sat Oct 14 01:23:01 2000 From: gward@python.net (Greg Ward) Date: Sat Oct 14 00:23:01 2000 Subject: [Distutils] Distutilizing wxPython In-Reply-To: <001b01c03595$9332e7c0$0b01a8c0@ARES>; from robin@alldunn.com on Fri, Oct 13, 2000 at 09:16:48PM -0700 References: <062b01c0309a$1a7fe4e0$0b01a8c0@ARES> <017e01c03212$ebd48ef0$4500a8c0@thomasnotebook> <20001013232828.A987@beelzebub> <001b01c03595$9332e7c0$0b01a8c0@ARES> Message-ID: <20001014002112.J639@beelzebub> On 13 October 2000, Robin Dunn said: > When you link together a DLL you also make an import library which defines > all the exported symbols in the DLL that can be imported into other code. I > believe that it also defines how to find the symbol in the DLL, an offset or > ordinal or something like that. When you are linking code that uses the DLL > you don't link with the DLL itself (like you do on Unix by linking with the > .so) but with the import library instead. Ahh, I see -- so it's not actually the *code*, just information *about* the code. I was stuck in a rut thinking "library means code". That clears it up nicely -- thanks. Greg From gward@python.net Sat Oct 14 01:26:01 2000 From: gward@python.net (Greg Ward) Date: Sat Oct 14 00:26:01 2000 Subject: [Distutils] Better SWIG C++ support In-Reply-To: ; from Joerg.Baumann@stud.informatik.uni-erlangen.de on Fri, Oct 06, 2000 at 01:44:08AM +0200 References: Message-ID: <20001014002353.E987@beelzebub> On 06 October 2000, Joerg Baumann said: > I had troubles with distutils 1.0 and the way I use SWIG. > I couldn't find any support for the -shadow option and no way to pass an > extra include dir to swig (like it´s possible for the c compiler) > > Therefore I wrote a patch. Great -- thanks! Unfortunately, this definitely counts as new functionality, so it'll have to wait until post-Python 2.0. I'm not sure if we're talking about Distutils 1.0.2 or 1.1, but definitely not 1.0.1. Could you submit your patch to the SourceForce patch manager so it doesn't get lost? Thanks. Go to: https://sourceforge.net/patch/?group_id=5470 (after logging in, of course, if you have a SourceForge user ID). Thanks -- Greg -- Greg Ward gward@python.net http://starship.python.net/~gward/ From tim_one@email.msn.com Sat Oct 14 02:49:01 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat Oct 14 01:49:01 2000 Subject: [Distutils] Watch those tabs! In-Reply-To: <20001013235228.A4529@beelzebub> Message-ID: [Greg Ward] > when submitting patches, please be sure that no evil tabs sneak in! > I've just noticed that there are several Distutils source files with the > dreaded ^I in them. I need to be more vigilant in fixing tabs when I > apply patches, and patch authors need to be more vigilant about not > letting them into their patches in the first place. Remember, > > (setq-default indent-tabs-mode nil) > > is your friend! > > Greg > > (What, you mean there are editors other than Emacs in the world? > Nawwww...) Just noting that, as of a couple weeks ago, I introduced Tools/scripts/reindent.py. Its sole purpose in life is to rewrite .py files to use 4-space indents and contain no hard tab characters. I haven't caught it screwing up anything yet, but my own .py files are so close to that already they're not really much of a test. After 2.0 is released, The Plan is to run this thing over every .py file in the std distribution. Note that it will not overwrite a file if it's already happy with it -- it saves the "before" and "after" contents verbatim, and leaves things alone if they're the same. There's also a "dry run" switch (-d) that can be used in conjunction with verbose mode (-v) to simply tell you *which* files it thinks needs fixing without actually changing anything. Note that reindent.py *assumes* that tabnanny.py is already happy. While no substitute for Emacs, it requires far less memory to run . emacs==eighty-megs-and-constantly-swapping-ly y'rs - tim From robin@alldunn.com Sat Oct 14 03:59:09 2000 From: robin@alldunn.com (Robin Dunn) Date: Sat Oct 14 02:59:09 2000 Subject: [Distutils] Hacks and bugs for distutilizing wxPython Message-ID: <006801c035ac$2a8fad40$0b01a8c0@ARES> Looks like I've got wxPython building with Distutils now on win32, Linux and Solaris. I thought I'd pass along the things I had to hack around so maybe some official solutions could be put into Distutils 1.1... Win32 (MSCVCompiler) -------------------- 1. As mentioned previously I need to pass -I flags to the resource compiler for my .rc file. I just hacked it to use the same flags passed to the C compiler but it might make sense to do it with a new attribute of Extension. 2. My secondary extensions need to link with the import lib produced from building the first extension. The default location of this file is dynamic based on the python version, debug status, and also the relative path to the first source file. Since there was no reliable way to determine before setup() was called where that directory would be I hacked it to just use a fixed location for the implib (build\ilib\). 3. I implemented these two hacks by deriving from MSCVCompiler and replacing the whole compile and link methods, each with only a one or two line change. It would be nice if they were more modular so derived classes could just override little bits here and there instead of huge methods. 4. I noticed this one on win32 but it may be a general problem. If relative path names containing '..' are used for extension source files then the objects can be placed in odd locations, possibly not even under ./build. For example, '../../wx/contrib/src/stc/stc.cpp' will have its object file put in build\temp.win32-1.5\Release\../../wx/contrib/src/stc/stc.obj which defeats the purpose of having the protection of temp.win32-1.5\Release! Related to this, if a full path is given to a source file, then the object will be put in the same directory as the source. I think object files should always be put under the build dir. Unix ---- 5. On my Linux system (RH 6.1, RPM 3.0.3) bdist_rpm failed with this message: Could not open /home/rd/wx/wxPython/build/bdist.linux-i686/rpm/RPMS/i386/wxPython- 2.2.2-1.i386.rpm because bdist_rpm didn't make the i386 directory. 6. Why is -g used by the compiler when --debug is not given to distutils? 7. It would be nice to be able to override CC, LDSAHRED, etc. (by setting environment variables or something) instead of just blindly taking them from Python's Makefile. For example I would like to be able to use "gcc -G" instead of the default (with Py-1.5.2) of "ld -G" on Solaris so that the static C++ objects will actually get initialized instead of being full of garbage and causing the application to segfault. SWIG ---- 8. Neither the SWIG support in 1.0 nor the recently contributed patches would meet my needs so I rolled my own. It's not integrated with build_ext but is run before setup() while I am constructing my Extension objects, and the list of generated sources is returned so it can be used to build the Extension object. It's very specific to my needs but others may find it useful too. I was able to reuse a lot of utility functions from distutils so much of the behaviour is similar to the way the rest of it works. You can see my setup.py and support files at: http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/wxWindows/wxPython/Attic/?cvsr oot=wxwindows&only_with_tag=WX_2_2_BRANCH It may be educational to take a look at it, even if it's just to point out the mistakes that a Distutils newbie like me makes! BTW, does anybody else have a 436 line setup.py? (Plus a coulple hundred for my MSVCCompiler hacks and other helper functions.) -- Robin Dunn Software Craftsman robin@AllDunn.com http://wxPython.org Java give you jitters? http://wxPROs.com Relax with wxPython! From calvin@cs.uni-sb.de Sat Oct 14 05:21:01 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Sat Oct 14 04:21:01 2000 Subject: [Distutils] patch for config::finalize_options In-Reply-To: <20001013233803.C987@beelzebub> Message-ID: >> This patch fixes up any supplied command line options. > >No wait, I still think it's harmless, but it's inconsistent: >include_dirs is treated as a os.pathsep-delimited string, but >library_dirs is not. Why not? I really dont know. Must have been the weather :) Both should be os.pathsep-delimited. Bastian From bhoel@starship.python.net Sat Oct 14 14:32:01 2000 From: bhoel@starship.python.net (Berthold =?iso-8859-1?q?H=F6llmann?=) Date: Sat Oct 14 13:32:01 2000 Subject: [Distutils] problems with "runtime_library_dirs" option Message-ID: Hello, I tried to use the "runtime_library_dirs" option when compiling the experimental "py-bsddb3-2.2.0" package. I had two problems with it. First I tried replace "library_dirs" by "runtime_library_dirs", but that failed, because the linker needed both, -L... and -R... , so I would suggest to change the method "runtime_library_dir_option" in unixcompiler.py from def runtime_library_dir_option (self, dir): return "-R" + dir to def runtime_library_dir_option (self, dir): return "-R" + dir + " -L" + dir The second problem is, that my gcc 2.95.2 does not propagate unknown options to the linker, so I get: gcc -shared build/temp.linux-i686-2.0/db.o -L/usr/local/BerkeleyDB.3.1/lib -R/usr/local/BerkeleyDB.3.1/lib -ldb -o build/lib.linux-i686-2.0/dbc.so gcc: unrecognized option `-R/usr/local/BerkeleyDB.3.1/lib' The module will be written, but it won't find the specified library, because the path is not in LD_LIBRARY_PATH. I see two ways to cure this. Both are unsatisfactory to me. The first way is to use "ld" instead of "gcc" or "cc" for linking, thus changing the lines 'linker_so' : ["cc", "-shared"], 'linker_exe' : ["cc"], to 'linker_so' : ["ld", "-shared"], 'linker_exe' : ["ld"], but, as I understand it the value for 'linker_so' is eventually taken from the LDSHARED value in the python Makefile stored in python?.?/config/Makefile and that value had to be changed. So the changed value will be overwritten from there. Second gcc has ha flag for options to be given to the linker, thus "-Wl,-R/usr/local/BerkeleyDB.3.1/lib" gives no warning and the wanted effect, but certainly only when you use gcc, other compiler will give an error with this. Is there an other way to solve this than to ask everyone to change python?.?/config/Makefile ? Greetings Berthold -- bhoel@starship.python.net / http://starship.python.net/crew/bhoel/ It is unlawful to use this email address for unsolicited ads (USC Title 47 Sec.227). I will assess a US$500 charge for reviewing and deleting each unsolicited ad. From gward@python.net Sun Oct 15 21:25:01 2000 From: gward@python.net (Greg Ward) Date: Sun Oct 15 20:25:01 2000 Subject: [Distutils] Distutils 1.0.1 releasee Message-ID: <20001015202258.A7540@beelzebub> Hi all -- I've just released Distutils 1.0.1. This is identical to the code in the last snapshot (20001014). And this is the code that will go out with Python 2.0. Now off to deal with the latest bug reports and feature requests... as if things quiet down just because of a major Python release... oh well... Greg -- Greg Ward gward@python.net http://starship.python.net/~gward/ From thomas.heller@ion-tof.com Mon Oct 16 03:50:01 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Mon Oct 16 02:50:01 2000 Subject: [Distutils] Watch those tabs! References: <20001013235228.A4529@beelzebub> Message-ID: <014801c0373d$345544b0$e000a8c0@thomasnotebook> > (What, you mean there are editors other than Emacs in the world? > Nawwww...) How does your emacs syntax-color the doc-string in text_file::TextFile? Mine (XEmacs on win32) doesn't very well... Thomas From thomas.heller@ion-tof.com Mon Oct 16 04:49:01 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Mon Oct 16 03:49:01 2000 Subject: [Distutils] Distutilizing wxPython References: <062b01c0309a$1a7fe4e0$0b01a8c0@ARES> <017e01c03212$ebd48ef0$4500a8c0@thomasnotebook> <20001013232828.A987@beelzebub> Message-ID: <01e801c03745$66030940$e000a8c0@thomasnotebook> > On 09 October 2000, Thomas Heller said: > > There should probably be separate flags for the C-compiler > > and the resource compiler. > > Is that really necessary? Robin's patch seems OK to me, except that it > only fixes MSVCCompiler -- presumably the Borland compiler class should > get similar treatment. > > When would you need separate -I and -D options for the resource > compiler? > Maybe it's ok for -I and -D. Here is the complete list of options for the resource compiler of MSVC6: Usage: rc [options] .RC input file Switches: /r Emit .RES file (optional) /v Verbose (print progress messages) /d Define a symbol /u Undefine a symbol /fo Rename .RES file /l Default language ID in hex /i Add a path for INCLUDE searches /x Ignore INCLUDE environment variable /c Define a code page used by NLS conversion /w Warn on Invalid codepage in .rc (default is an error) /n Append null's to all strings in the string tables. Flags may be either upper or lower case I have often seen use of the /l flag. Thomas From calvin@cs.uni-sb.de Mon Oct 16 06:40:10 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Mon Oct 16 05:40:10 2000 Subject: [Distutils] Distutils 1.0.1 releasee In-Reply-To: <20001015202258.A7540@beelzebub> Message-ID: Hello, nice to mail you. >I've just released Distutils 1.0.1. This is identical to the code in >the last snapshot (20001014). And this is the code that will go out >with Python 2.0. Very nifty. >Now off to deal with the latest bug reports and feature requests... as >if things quiet down just because of a major Python release... oh >well... 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. Okay, here is an example. I am using localization .mo/.po files in my program and I need to know at runtime where these files are. So I look in the Conf.py module for 'install_data' attribute and search there. After all, should we implement a function to generate such a configuration module? This would be a little like the .ini file for the windows installer. Attached is the function I am using for this now, very rough as usual ;) Bastian # dist.py: # self.config_file = self.get_name()+"Conf.py" def create_conf_file(self, directory, data=[]): 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) # write file util.execute(write_file, (filename, data), "creating %s" % filename, self.verbose>=1, self.dry_run) From R.Liebscher@gmx.de Mon Oct 16 07:28:01 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Mon Oct 16 06:28:01 2000 Subject: [Distutils] Distutilizing wxPython References: <062b01c0309a$1a7fe4e0$0b01a8c0@ARES> <017e01c03212$ebd48ef0$4500a8c0@thomasnotebook> <20001013232828.A987@beelzebub> <01e801c03745$66030940$e000a8c0@thomasnotebook> Message-ID: <39EAD74A.70E1750E@gmx.de> Thomas Heller wrote: > > > On 09 October 2000, Thomas Heller said: > > > There should probably be separate flags for the C-compiler > > > and the resource compiler. > > > > Is that really necessary? Robin's patch seems OK to me, except that it > > only fixes MSVCCompiler -- presumably the Borland compiler class should > > get similar treatment. > > > > When would you need separate -I and -D options for the resource > > compiler? > > > Maybe it's ok for -I and -D. > Here is the complete list of options for the resource compiler of MSVC6: > > Usage: rc [options] .RC input file > Switches: > /r Emit .RES file (optional) > /v Verbose (print progress messages) > /d Define a symbol > /u Undefine a symbol > /fo Rename .RES file > /l Default language ID in hex > /i Add a path for INCLUDE searches > /x Ignore INCLUDE environment variable > /c Define a code page used by NLS conversion > /w Warn on Invalid codepage in .rc (default is an error) > /n Append null's to all strings in the string tables. > Flags may be either upper or lower case > Not all compilers have resource compilers which support all these options. There are even resource compilers which doesn't support all possible keywords in rc-files (cygwin's windres.) If you want other people let build your packages it would be nice to have a way to support a format which is compiler-independ. The res-file which comes out of the resource compiler, has the same format for all compilers. So why doesn't support res-files as source files? You only had to compile it on your machine and add it to your sources. If anyone wants to build your package for himself, he doesn't rely on a special (resource) compiler, and you don't have to provide any options to the resource compiler. (If people want to change the rc-files then it is their problem to get it compiled, not yours.) BTW, the 'bcpp', 'cygwin' and 'mingw32' compiler classes do already support res-files as source files. We had only to change the 'msvc' compiler class. Kind regards Rene Liebscher From pete@visionart.com Tue Oct 17 14:24:01 2000 From: pete@visionart.com (Pete Shinners) Date: Tue Oct 17 13:24:01 2000 Subject: [Distutils] compiling extension for app Message-ID: <002001c0385f$2354c320$f73f93cd@visionart.com> 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 From pete@visionart.com Tue Oct 17 18:15:01 2000 From: pete@visionart.com (Pete Shinners) Date: Tue Oct 17 17:15:01 2000 Subject: [Distutils] extra files into the package dir Message-ID: <00be01c0387f$64287930$f73f93cd@visionart.com> i have some extra files i'd like to have copied into the destination package directory when installing. it seems that distutils only installs the .PY(C) files when installing a package directory. how can i tell distutils to copy my other files too? does this involve 'extending' the install command? i could probably do that if there were docs or an example of something like that. thanks From R.Liebscher@gmx.de Wed Oct 18 09:36:01 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Wed Oct 18 08:36:01 2000 Subject: [Distutils] extra files into the package dir References: <00be01c0387f$64287930$f73f93cd@visionart.com> Message-ID: <39ED9849.A0AF5CBF@gmx.de> Pete Shinners wrote: > > i have some extra files i'd like to have copied into > the destination package directory when installing. > > it seems that distutils only installs the .PY(C) files > when installing a package directory. how can i tell > distutils to copy my other files too? > > does this involve 'extending' the install command? > i could probably do that if there were docs or an > example of something like that. > I had a similar problem with PyOpenGL. (It needs some data files for its examples.) May be my solution is what you need. (At least it could serve as an example.) Look at the following address: http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/PyOpenGL/?cvsroot=PyOpenGL "my_install_data.py" extends distutils' install_data command. "setup.py" uses then this alternative command. (The important parts are at the end of this file. One is the specification of this alternative install command = "cmdclass" parameter of the setup function. The other is the "data_files" parameter to the setup function.) Kind regards Rene Liebscher From bhoel@starship.python.net Wed Oct 18 17:26:02 2000 From: bhoel@starship.python.net (Berthold =?iso-8859-1?q?H=F6llmann?=) Date: Wed Oct 18 16:26:02 2000 Subject: [Distutils] extra files into the package dir In-Reply-To: Rene Liebscher's message of "Wed, 18 Oct 2000 14:32:09 +0200" References: <00be01c0387f$64287930$f73f93cd@visionart.com> <39ED9849.A0AF5CBF@gmx.de> Message-ID: >>>>> "Rene" == Rene Liebscher writes: Rene> Pete Shinners wrote: >> i have some extra files i'd like to have copied into the >> destination package directory when installing. >> >> it seems that distutils only installs the .PY(C) files when >> installing a package directory. how can i tell distutils to >> copy my other files too? >> >> does this involve 'extending' the install command? i could >> probably do that if there were docs or an example of something >> like that. >> Rene> I had a similar problem with PyOpenGL. (It needs some data Rene> files for its examples.) May be my solution is what you Rene> need. (At least it could serve as an example.) Rene> Look at the following address: Rene> http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/PyOpenGL/?cvsroot=PyOpenGL Rene> "my_install_data.py" extends distutils' install_data Rene> command. "setup.py" uses then this alternative command. (The Rene> important parts are at the end of this file. One is the Rene> specification of this alternative install command = Rene> "cmdclass" parameter of the setup function. The other is the Rene> "data_files" parameter to the setup function.) 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. Hope this helps. Greetings Berthold -- bhoel@starship.python.net / http://starship.python.net/crew/bhoel/ It is unlawful to use this email address for unsolicited ads (USC Title 47 Sec.227). I will assess a US$500 charge for reviewing and deleting each unsolicited ad. From gward@python.net Wed Oct 18 21:25:01 2000 From: gward@python.net (Greg Ward) Date: Wed Oct 18 20:25:01 2000 Subject: [Distutils] Factoring out WindowsCCompiler? Message-ID: <20001018193256.A896@beelzebub> Rene -- now that the fuss over Distutils 1.0/Python 2.0 has died down, where does your work on factoring out WindowsCCompiler stand? Now would be a good time to get that checked in, so it can be well tested before Distutils 1.1. Greg -- Greg Ward gward@python.net http://starship.python.net/~gward/ From gward@python.net Wed Oct 18 21:25:07 2000 From: gward@python.net (Greg Ward) Date: Wed Oct 18 20:25:07 2000 Subject: [Distutils] Distutilizing wxPython In-Reply-To: <39EAD74A.70E1750E@gmx.de>; from R.Liebscher@gmx.de on Mon, Oct 16, 2000 at 12:24:10PM +0200 References: <062b01c0309a$1a7fe4e0$0b01a8c0@ARES> <017e01c03212$ebd48ef0$4500a8c0@thomasnotebook> <20001013232828.A987@beelzebub> <01e801c03745$66030940$e000a8c0@thomasnotebook> <39EAD74A.70E1750E@gmx.de> Message-ID: <20001018190637.A871@beelzebub> On 16 October 2000, Rene Liebscher said: > Not all compilers have resource compilers which support all these > options. There are even resource compilers which doesn't support all > possible keywords in rc-files (cygwin's windres.) If you want other > people let build your packages it would be nice to have a way to > support a format which is compiler-independ. > > The res-file which comes out of the resource compiler, has the same > format for all compilers. So why doesn't support res-files as source > files? You only had to compile it on your machine and add it to your > sources. If anyone wants to build your package for himself, he > doesn't rely on a special (resource) compiler, and you don't have to > provide any options to the resource compiler. (If people want to > change the rc-files then it is their problem to get it compiled, not > yours.) +1 from this interested bystander. This seems to me like the moral equivalent of including your yacc-generated .c file along with your .y file: not strictly necessary, since "everyone has yacc", but of course *not* everyone has yacc, and it's one more thing that can go wrong in the build process. (There's my Unix bias showing through again.) For the record, I think it's a fool's errand to try to completely wrap the capabilities of any particular compiler, be it a C/C++ compiler or a resource compiler or what. The point of the CCompiler interface is to expose the *common* functionality that *all or most* C compilers provide. If you want to take advantage of particular compilers, there are (awkward) ways of doing so, but you have to skirt around the edges of the standard interface. This is by design! Even including "resource files" in the list of things that can be processed by a C compiler is a bit of a stretch, but I let it slip since Windows is a pretty important platform. However, since there's more than one compiler in the Windows world (whatever Chairman Bill's minions say ;-), we should not tie ourselves to one particular compiler. Idea: should resource files be elevated to first-class status in the CCompiler interface, ie. should we add a 'compile_resource_file()' method? This would be a clean place to expose the common functionality of resource files without cluttering up the general 'compile()' method. Downside: it would require the "build_ext" command to recognize certain files as "resource files" and call this different method on them. (Essential since we must now preserve backwards compatibility of setup scripts at all costs! Gone are the days of changing things willy-nilly...) Greg -- Greg Ward gward@python.net http://starship.python.net/~gward/ From gward@python.net Wed Oct 18 21:25:12 2000 From: gward@python.net (Greg Ward) Date: Wed Oct 18 20:25:12 2000 Subject: [Distutils] Watch those tabs! In-Reply-To: <014801c0373d$345544b0$e000a8c0@thomasnotebook>; from thomas.heller@ion-tof.com on Mon, Oct 16, 2000 at 08:49:17AM +0200 References: <20001013235228.A4529@beelzebub> <014801c0373d$345544b0$e000a8c0@thomasnotebook> Message-ID: <20001018192901.B871@beelzebub> On 16 October 2000, Thomas Heller said: > > (What, you mean there are editors other than Emacs in the world? > > Nawwww...) > How does your emacs syntax-color the doc-string in > text_file::TextFile? > Mine (XEmacs on win32) doesn't very well... Same problem here (XEmacs 21.1 on Linux) -- I think python-mode doesn't like the fact that I have a quoted comment character in a docstring. Ah well... Greg -- Greg Ward gward@python.net http://starship.python.net/~gward/ From gward@python.net Wed Oct 18 21:54:01 2000 From: gward@python.net (Greg Ward) Date: Wed Oct 18 20:54:01 2000 Subject: [Distutils] Hacks and bugs for distutilizing wxPython In-Reply-To: <006801c035ac$2a8fad40$0b01a8c0@ARES>; from robin@alldunn.com on Fri, Oct 13, 2000 at 11:58:32PM -0700 References: <006801c035ac$2a8fad40$0b01a8c0@ARES> Message-ID: <20001018200113.C871@beelzebub> On 13 October 2000, Robin Dunn said: > Looks like I've got wxPython building with Distutils now on win32, Linux and > Solaris. I thought I'd pass along the things I had to hack around so maybe > some official solutions could be put into Distutils 1.1... Cool! I think we can address most of these in due course. > Win32 (MSCVCompiler) > -------------------- > 1. As mentioned previously I need to pass -I flags to the resource compiler > for my .rc file. I just hacked it to use the same flags passed to the C > compiler but it might make sense to do it with a new attribute of Extension. And whatever is done, it should be done for the other Windows CCompiler implementations. This will be helped by factoring a new class, WindowsCCompiler, out of the {MSVC,BCPP}Compiler. Rene Liebscher was working on this, so hopefully it will be done and checked in soon. I want to hold off on changes to the Windows compiler classes until this refactoring is done. > 2. My secondary extensions need to link with the import lib produced from > building the first extension. The default location of this file is dynamic > based on the python version, debug status, and also the relative path to the > first source file. Since there was no reliable way to determine before > setup() was called where that directory would be I hacked it to just use a > fixed location for the implib (build\ilib\). Still pondering this one. Wherever we put it, the directory name will be unpredictable and not known until run-time, because all directories in "build/" with platform-specifc files are named after the platform. One idea: allow expansion of "configuration variables" in more values in the setup script. Eg. setup(... ext_modules = [Extension('secondary', libraries=['$build_temp/primary'])] ) Assuming that your import library is called "primary", lives right in build/temp.-, and can be accessed by adding "-Lbuild/temp.- -lprimary" to the linker command line, then all we need to do is add the ability to expand configuration variables in certain inputs to the extension-building process. This is powerful and dangerous, but the precedent has been set by the "install" command. > 3. I implemented these two hacks by deriving from MSCVCompiler and replacing > the whole compile and link methods, each with only a one or two line change. > It would be nice if they were more modular so derived classes could just > override little bits here and there instead of huge methods. Agreed. This should wait for the WindowsCCompiler refactoring, though. > 4. I noticed this one on win32 but it may be a general problem. If relative > path names containing '..' are used for extension source files then the > objects can be placed in odd locations, possibly not even under ./build. > For example, '../../wx/contrib/src/stc/stc.cpp' will have its object file > put in build\temp.win32-1.5\Release\../../wx/contrib/src/stc/stc.obj which > defeats the purpose of having the protection of temp.win32-1.5\Release! Oooh, tricky! I don't have a good answer for this, except the old standby, "Well don't do that then!". One general weakness of the Distutils is that they really don't like files to be outside of your source tree (ie. above the distribution root). > Related to this, if a full path is given to a source file, then the object > will be put in the same directory as the source. I think object files > should always be put under the build dir. By "full path" do you mean "absolute path", or just "anything with {slashes|backslashes|colons}"? Let's see... yup, I can reproduce this by putting an absolute path in the setup script. Well, again, "don't do that!". I can't think of any good reason to put absolute paths in your setup script; it destroys portability even to another machine (much less another OS), so it's not something I ever even considered supporting. Why do you need it? > 5. On my Linux system (RH 6.1, RPM 3.0.3) bdist_rpm failed with this > message: > > Could not open > /home/rd/wx/wxPython/build/bdist.linux-i686/rpm/RPMS/i386/wxPython- > 2.2.2-1.i386.rpm > > because bdist_rpm didn't make the i386 directory. You must be running rpm 3.0.x, for x < 4. Should detect this and warn about it. > 6. Why is -g used by the compiler when --debug is not given to distutils? Because it's what's in Python's Makefile. Hmmm... here's how it works right now: if 'debug' is true (ie. --debug is given on the build_ext or build_clib command line), then UnixCCompiler inserts "-g" into the argument list. But it does nothing if 'debug' is false. Perhaps it should explicitly remove "-g". That feels wrong to me, though: if you built your Python with -g, then surely you mean to build extensions with -g? (Note that, at least as of Red Hat 6.2, Red Hat built Python with -g, which belies that argument. Still...) > 7. It would be nice to be able to override CC, LDSAHRED, etc. (by setting > environment variables or something) instead of just blindly taking them from > Python's Makefile. For example I would like to be able to use "gcc -G" > instead of the default (with Py-1.5.2) of "ld -G" on Solaris so that the > static C++ objects will actually get initialized instead of being full of > garbage and causing the application to segfault. CFLAGS and LDFLAGS have been on the TODO list for ages. Hadn't thought of allowing CC or LDSHARED, but I guess it would be useful. (Can also be dangerous, but I guess it's on your head if you compile Python with foocc and your extension with barcc. Don't come whining to me when it dumps core, though!) You'll be glad to know that LDSHARED on Solaris is fixed in Python 1.6 and later -- I patched configure.in to handle that. Thanks for the comments -- please watch this space, hopefully in the next couple of weeks we'll start to address some of your problems. I hate the idea of 400-line setup scripts out there to work around bugs or omissions in the Distutils, but I guess we're stuck with them for a little while. Sigh... Greg -- Greg Ward gward@python.net http://starship.python.net/~gward/ From robin@alldunn.com Wed Oct 18 23:14:01 2000 From: robin@alldunn.com (Robin Dunn) Date: Wed Oct 18 22:14:01 2000 Subject: [Distutils] Hacks and bugs for distutilizing wxPython References: <006801c035ac$2a8fad40$0b01a8c0@ARES> <20001018200113.C871@beelzebub> Message-ID: <001701c03972$200a3a10$0b01a8c0@ARES> > > 2. My secondary extensions need to link with the import lib produced from > > building the first extension. The default location of this file is dynamic > > based on the python version, debug status, and also the relative path to the > > first source file. Since there was no reliable way to determine before > > setup() was called where that directory would be I hacked it to just use a > > fixed location for the implib (build\ilib\). > > Still pondering this one. Wherever we put it, the directory name will > be unpredictable and not known until run-time, because all directories > in "build/" with platform-specifc files are named after the platform. > > One idea: allow expansion of "configuration variables" in more values in > the setup script. I like this. Another idea would be to automatically add the directory to the library_dirs of subsequent Extension objects, although I suppose that could be even more dangerous than variable expansion. > > > Related to this, if a full path is given to a source file, then the object > > will be put in the same directory as the source. I think object files > > should always be put under the build dir. > > By "full path" do you mean "absolute path", Yes. > I can't think of any good reason to put absolute paths in your > setup script; it destroys portability even to another machine (much less > another OS), so it's not something I ever even considered supporting. > Why do you need it? The path came from an environment variable that was concatenated with some source file names. > > 6. Why is -g used by the compiler when --debug is not given to distutils? > > Because it's what's in Python's Makefile. Hmmm... here's how it works > right now: if 'debug' is true (ie. --debug is given on the build_ext or > build_clib command line), then UnixCCompiler inserts "-g" into the > argument list. But it does nothing if 'debug' is false. Perhaps it > should explicitly remove "-g". That feels wrong to me, though: if you > built your Python with -g, then surely you mean to build extensions with > -g? > I think it should remove it. With the distutils philosophy, if I want debug info I ask for it. If I want to distribute a lean and mean binary then the absense of --debug should mean the absense of debug info, after all, the flag is not called --no-gol-dang-debug-info-please. IMHO, Python's configure has the wrong default. It's not often that I feel the need to trace into Python sources, even when I'm developing extensions. For the 98% of the Python installations out there that are not developing extensions or hacking on Python itself there is definitly no need. I think it should have an --enable-debug flag that is off by default. But I digress... > > You'll be glad to know that LDSHARED on Solaris is fixed in Python 1.6 > and later -- I patched configure.in to handle that. Yep, I noticed that when I built 2.0. -- Robin Dunn Software Craftsman robin@AllDunn.com http://wxPython.org Java give you jitters? http://wxPROs.com Relax with wxPython! From R.Liebscher@gmx.de Thu Oct 19 10:37:03 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Thu Oct 19 09:37:03 2000 Subject: [Distutils] Factoring out WindowsCCompiler? References: <20001018193256.A896@beelzebub> Message-ID: <39EEF813.1DF9548B@gmx.de> This is a multi-part message in MIME format. --------------731E085DA5F2F5144B5381BE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greg Ward wrote: > > Rene -- > > now that the fuss over Distutils 1.0/Python 2.0 has died down, where > does your work on factoring out WindowsCCompiler stand? Now would be a > good time to get that checked in, so it can be well tested before > Distutils 1.1. > I'm still working on it. But you can have a first version. file: windowsccompiler.py It collects some common initialization and helper functions in the module. The WindowsCCompiler class is currently not more than an additional layer between CCompiler and the existing compiler classes, which means it doesn't contain any implementations for compile and link methods. The main problem is that the link method for Borland C++ needs this strict order. Maybe one should think about some kind of generic building the command line. For example: (Borland C++, linking of a dll) cmdline_link_dll = [ (LINKER_EXECUTABLE,), (EXTRA_PREARGS,), "/Tpd","/Gn","/q","/x", (LIBRARY_DIRS,"/L%s"), (EXTRA_POSTARGS,) "c0d32", (OBJECTS,"%s"), ",", (OUTPUT_FILENAME,"%s"), ",,", (LIBRARIES,"%s"), "import32", "cw32mt", ",", (DEF_FILE,"%s"), ",", (RESOURCES."%s") ] This would need a kind of "parser" in WindowsCCompiler and for a new compiler you would only specify how its command line has to be built. (It would change some existing code to data structures, which means also to a higher level of abstraction.) -------------------------------------- And another problem which was reported to me. Mike Fletcher wrote: > The tar format > command for bdist uses fully-specified windows path names, which might make > tar fail: > > d:\bin\lang\cygwin\cygwin-b20\H-i586-cygwin32\bin\tar.exe -cf > S:\PyOpenGL\dist\PyOpenGL-1.5.6a1.win32.tar . > tar: Cannot execute remote shell: No such file or directory > tar: Cannot open S:\PyOpenGL\dist\PyOpenGL-1.5.6a1.win32.tar: I/O error > tar: Error is not recoverable: exiting now > error: command 'tar' failed with exit status 2 > > Using /PyOpenGL/dist/yada (or even just "yada", since you've changed > directories) should work I think. Strangely, the sdist command uses a > similar format and tar works there... curiouser and curiouser said Alice. The problem comes from tar. The cygwin tar program doesn't like absolute pathnames on windows. (sdist works in the current directory.) (S:\PyOpenGL\dist\PyOpenGL-1.5.6a1.win32.tar fails, but //S/PyOpenGL/... had probably worked.) If we still want let the users work with tar (on windows), we had to change either the path so it is accepted (this is windows cygwin-tar specific) or we could use relative paths instead of absolute ones (this is not platform specific). I attached a patch for archive_util.py which tries to use a relative path whenever possible. file: archive_util.py Kind regards Rene Liebscher --------------731E085DA5F2F5144B5381BE Content-Type: text/plain; charset=us-ascii; name="windowsccompiler.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="windowsccompiler.patch" diff -BurN --exclude=*.pyc --minimal distutils.orig/distutils/bcppcompiler.py distutils.patched/distutils/bcppcompiler.py --- distutils.orig/distutils/bcppcompiler.py Wed Sep 27 15:37:16 2000 +++ distutils.patched/distutils/bcppcompiler.py Thu Oct 19 14:42:32 2000 @@ -18,12 +18,12 @@ from distutils.errors import \ DistutilsExecError, DistutilsPlatformError, \ CompileError, LibError, LinkError -from distutils.ccompiler import \ - CCompiler, gen_preprocess_options, gen_lib_options +from distutils.windowsccompiler import WindowsCCompiler +from distutils.ccompiler import gen_preprocess_options, gen_lib_options from distutils.file_util import write_file -class BCPPCompiler(CCompiler) : +class BCPPCompiler(WindowsCCompiler) : """Concrete class that implements an interface to the Borland C/C++ compiler, as defined by the CCompiler abstract class. """ @@ -27,36 +27,15 @@ """Concrete class that implements an interface to the Borland C/C++ compiler, as defined by the CCompiler abstract class. """ - compiler_type = 'bcpp' - # Just set this so CCompiler's constructor doesn't barf. We currently - # don't use the 'set_executables()' bureaucracy provided by CCompiler, - # as it really isn't necessary for this sort of single-compiler class. - # Would be nice to have a consistent interface with UnixCCompiler, - # though, so it's worth thinking about. - executables = {} - - # Private class data (need to distinguish C from C++ source for compiler) - _c_extensions = ['.c'] - _cpp_extensions = ['.cc', '.cpp', '.cxx'] - - # Needed for the filename generation methods provided by the - # base class, CCompiler. - src_extensions = _c_extensions + _cpp_extensions - obj_extension = '.obj' - static_lib_extension = '.lib' - shared_lib_extension = '.dll' - static_lib_format = shared_lib_format = '%s%s' - exe_extension = '.exe' - def __init__ (self, verbose=0, dry_run=0, force=0): - CCompiler.__init__ (self, verbose, dry_run, force) + WindowsCCompiler.__init__ (self, verbose, dry_run, force) # These executables are assumed to all be in the path. # Borland doesn't seem to use any special registry settings to @@ -65,6 +44,7 @@ self.cc = "bcc32.exe" self.linker = "ilink32.exe" self.lib = "tlib.exe" + self.rc = "brcc32.exe" self.preprocess_options = None self.compile_options = ['/tWM', '/O2', '/q', '/g0'] @@ -120,7 +100,7 @@ if ext == '.rc': # This needs to be compiled to a .res file -- do it now. try: - self.spawn (["brcc32", "-fo", obj, src]) + self.spawn ([self.rc, "-fo", obj, src]) except DistutilsExecError, msg: raise CompileError, msg continue # the 'for' loop @@ -214,7 +194,7 @@ if self._need_link (objects, output_filename): # Figure out linker args based on type of target. - if target_desc == CCompiler.EXECUTABLE: + if target_desc == self.EXECUTABLE: startup_obj = 'c0w32' if debug: ld_args = self.ldflags_exe_debug[:] @@ -316,60 +296,3 @@ self.announce ("skipping %s (up-to-date)" % output_filename) # link () - - # -- Miscellaneous methods ----------------------------------------- - - - def find_library_file (self, dirs, lib, debug=0): - # List of effective library names to try, in order of preference: - # xxx_bcpp.lib is better than xxx.lib - # and xxx_d.lib is better than xxx.lib if debug is set - # - # The "_bcpp" suffix is to handle a Python installation for people - # with multiple compilers (primarily Distutils hackers, I suspect - # ;-). The idea is they'd have one static library for each - # compiler they care about, since (almost?) every Windows compiler - # seems to have a different format for static libraries. - if debug: - dlib = (lib + "_d") - try_names = (dlib + "_bcpp", lib + "_bcpp", dlib, lib) - else: - try_names = (lib + "_bcpp", lib) - - for dir in dirs: - for name in try_names: - libfile = os.path.join(dir, self.library_filename(name)) - if os.path.exists(libfile): - return libfile - else: - # Oops, didn't find it in *any* of 'dirs' - return None - - # overwrite the one from CCompiler to support rc and res-files - def object_filenames (self, - source_filenames, - strip_dir=0, - output_dir=''): - if output_dir is None: output_dir = '' - obj_names = [] - for src_name in source_filenames: - # use normcase to make sure '.rc' is really '.rc' and not '.RC' - (base, ext) = os.path.splitext (os.path.normcase(src_name)) - if ext not in (self.src_extensions + ['.rc','.res']): - raise UnknownFileError, \ - "unknown file type '%s' (from '%s')" % \ - (ext, src_name) - if strip_dir: - base = os.path.basename (base) - if ext == '.res': - # these can go unchanged - obj_names.append (os.path.join (output_dir, base + ext)) - elif ext == '.rc': - # these need to be compiled to .res-files - obj_names.append (os.path.join (output_dir, base + '.res')) - else: - obj_names.append (os.path.join (output_dir, - base + self.obj_extension)) - return obj_names - - # object_filenames () diff -BurN --exclude=*.pyc --minimal distutils.orig/distutils/ccompiler.py distutils.patched/distutils/ccompiler.py --- distutils.orig/distutils/ccompiler.py Wed Sep 27 11:26:08 2000 +++ distutils.patched/distutils/ccompiler.py Thu Oct 19 14:42:32 2000 @@ -695,7 +695,7 @@ """ raise NotImplementedError - def library_option (self, lib): + def library_option (self, lib, debug): """Return the compiler option to add 'dir' to the list of libraries linked into the shared library or executable. """ @@ -969,7 +969,7 @@ # gen_preprocess_options () -def gen_lib_options (compiler, library_dirs, runtime_library_dirs, libraries): +def gen_lib_options (compiler, library_dirs, runtime_library_dirs, libraries,debug=0): """Generate linker options for searching library directories and linking with specific libraries. 'libraries' and 'library_dirs' are, respectively, lists of library names (not filenames!) and search diff -BurN --exclude=*.pyc --minimal distutils.orig/distutils/cygwinccompiler.py distutils.patched/distutils/cygwinccompiler.py --- distutils.orig/distutils/cygwinccompiler.py Wed Sep 27 11:26:09 2000 +++ distutils.patched/distutils/cygwinccompiler.py Thu Oct 19 14:45:12 2000 @@ -46,6 +46,7 @@ __revision__ = "$Id: cygwinccompiler.py,v 1.8 2000/09/27 02:08:14 gward Exp $" import os,sys,copy +import windowsccompiler from distutils.ccompiler import gen_preprocess_options, gen_lib_options from distutils.unixccompiler import UnixCCompiler from distutils.file_util import write_file @@ -60,6 +61,35 @@ static_lib_format = "lib%s%s" shared_lib_format = "%s%s" exe_extension = ".exe" + + # Private class data (need to distinguish C from C++ source for compiler) + _c_extensions = ['.c'] + _cpp_extensions = ['.cc', '.cpp', '.cxx'] + _rc_extensions = ['.rc'] + _rc_obj_extension = '.rc.o' + _res_extensions = ['.res'] + _res_obj_extension = '.res.o' + _mc_extensions = [] # not supported by cygwin ['.mc'] + #_mc_obj_extension = '.mc.o' + + # res-files go for most compilers to the linker, but gcc compiles them + # to a real object file in the compile() method + # so you have to support res-files as source files + _passthrough_extensions = [] + + # Needed for the filename generation methods provided by the + # base class, CCompiler. + src_extensions = ( _c_extensions + _cpp_extensions + + _rc_extensions + _mc_extensions + + _passthrough_extensions ) + + obj_extension = '.obj' + static_lib_extension = '.lib' + shared_lib_extension = '.dll' + static_lib_format = shared_lib_format = '%s%s' + exe_extension = '.exe' + + def __init__ (self, verbose=0, @@ -68,10 +98,10 @@ UnixCCompiler.__init__ (self, verbose, dry_run, force) - (status, details) = check_config_h() + (status, details) = windowsccompiler.check_compatibility("GCC","__GNUC__") self.debug_print("Python's GCC status: %s (details: %s)" % (status, details)) - if status is not CONFIG_H_OK: + if status is not windowsccompiler.COMPATIBILITY_OK: self.warn( "Python's config.h doesn't seem to support your compiler. " + ("Reason: %s." % details) + @@ -275,25 +305,7 @@ source_filenames, strip_dir=0, output_dir=''): - if output_dir is None: output_dir = '' - obj_names = [] - for src_name in source_filenames: - # use normcase to make sure '.rc' is really '.rc' and not '.RC' - (base, ext) = os.path.splitext (os.path.normcase(src_name)) - if ext not in (self.src_extensions + ['.rc','.res']): - raise UnknownFileError, \ - "unknown file type '%s' (from '%s')" % \ - (ext, src_name) - if strip_dir: - base = os.path.basename (base) - if ext == '.res' or ext == '.rc': - # these need to be compiled to object files - obj_names.append (os.path.join (output_dir, - base + ext + self.obj_extension)) - else: - obj_names.append (os.path.join (output_dir, - base + self.obj_extension)) - return obj_names + return windowsccompiler.object_filenames (self,source_filenames,strip_dir,output_dir) # object_filenames () @@ -334,64 +346,6 @@ # __init__ () # class Mingw32CCompiler - -# Because these compilers aren't configured in Python's config.h file by -# default, we should at least warn the user if he is using a unmodified -# version. - -CONFIG_H_OK = "ok" -CONFIG_H_NOTOK = "not ok" -CONFIG_H_UNCERTAIN = "uncertain" - -def check_config_h(): - - """Check if the current Python installation (specifically, config.h) - appears amenable to building extensions with GCC. Returns a tuple - (status, details), where 'status' is one of the following constants: - CONFIG_H_OK - all is well, go ahead and compile - CONFIG_H_NOTOK - doesn't look good - CONFIG_H_UNCERTAIN - not sure -- unable to read config.h - 'details' is a human-readable string explaining the situation. - - Note there are two ways to conclude "OK": either 'sys.version' contains - the string "GCC" (implying that this Python was built with GCC), or the - installed "config.h" contains the string "__GNUC__". - """ - - # XXX since this function also checks sys.version, it's not strictly a - # "config.h" check -- should probably be renamed... - - from distutils import sysconfig - import string,sys - # if sys.version contains GCC then python was compiled with - # GCC, and the config.h file should be OK - if string.find(sys.version,"GCC") >= 0: - return (CONFIG_H_OK, "sys.version mentions 'GCC'") - - fn = sysconfig.get_config_h_filename() - try: - # It would probably better to read single lines to search. - # But we do this only once, and it is fast enough - f = open(fn) - s = f.read() - f.close() - - except IOError, exc: - # if we can't read this file, we cannot say it is wrong - # the compiler will complain later about this file as missing - return (CONFIG_H_UNCERTAIN, - "couldn't read '%s': %s" % (fn, exc.strerror)) - - else: - # "config.h" contains an "#ifdef __GNUC__" or something similar - if string.find(s,"__GNUC__") >= 0: - return (CONFIG_H_OK, "'%s' mentions '__GNUC__'" % fn) - else: - return (CONFIG_H_NOTOK, "'%s' does not mention '__GNUC__'" % fn) - def get_versions(): diff -BurN --exclude=*.pyc --minimal distutils.orig/distutils/msvccompiler.py distutils.patched/distutils/msvccompiler.py --- distutils.orig/distutils/msvccompiler.py Wed Sep 27 11:26:10 2000 +++ distutils.patched/distutils/msvccompiler.py Thu Oct 19 14:44:41 2000 @@ -15,8 +15,10 @@ from distutils.errors import \ DistutilsExecError, DistutilsPlatformError, \ CompileError, LibError, LinkError -from distutils.ccompiler import \ - CCompiler, gen_preprocess_options, gen_lib_options +from distutils.ccompiler import gen_preprocess_options, gen_lib_options +from distutils.windowsccompiler import WindowsCCompiler + + _can_read_reg = 0 try: @@ -50,8 +52,6 @@ HKEY_LOCAL_MACHINE = hkey_mod.HKEY_LOCAL_MACHINE HKEY_CURRENT_USER = hkey_mod.HKEY_CURRENT_USER HKEY_USERS = hkey_mod.HKEY_USERS - - def get_devstudio_versions (): """Get list of devstudio versions from the Windows registry. Return a @@ -162,43 +162,18 @@ os.environ[name] = string.join (p,';') -class MSVCCompiler (CCompiler) : +class MSVCCompiler (WindowsCCompiler) : """Concrete class that implements an interface to Microsoft Visual C++, - as defined by the CCompiler abstract class.""" - + as defined by the CCompiler abstract class. + """ compiler_type = 'msvc' - # Just set this so CCompiler's constructor doesn't barf. We currently - # don't use the 'set_executables()' bureaucracy provided by CCompiler, - # as it really isn't necessary for this sort of single-compiler class. - # Would be nice to have a consistent interface with UnixCCompiler, - # though, so it's worth thinking about. - executables = {} - - # Private class data (need to distinguish C from C++ source for compiler) - _c_extensions = ['.c'] - _cpp_extensions = ['.cc', '.cpp', '.cxx'] - _rc_extensions = ['.rc'] - _mc_extensions = ['.mc'] - - # Needed for the filename generation methods provided by the - # base class, CCompiler. - src_extensions = (_c_extensions + _cpp_extensions + - _rc_extensions + _mc_extensions) - res_extension = '.res' - obj_extension = '.obj' - static_lib_extension = '.lib' - shared_lib_extension = '.dll' - static_lib_format = shared_lib_format = '%s%s' - exe_extension = '.exe' - - def __init__ (self, verbose=0, dry_run=0, force=0): - CCompiler.__init__ (self, verbose, dry_run, force) + WindowsCCompiler.__init__ (self, verbose, dry_run, force) versions = get_devstudio_versions () if versions: @@ -211,7 +186,7 @@ self.mc = find_exe("mc.exe", version) # message compiler set_path_env_var ('lib', version) set_path_env_var ('include', version) - path=get_msvc_paths('path', version) + path = get_msvc_paths('path', version) try: for p in string.split(os.environ['path'],';'): path.append(p) @@ -240,36 +215,6 @@ # -- Worker methods ------------------------------------------------ - def object_filenames (self, - source_filenames, - strip_dir=0, - output_dir=''): - # Copied from ccompiler.py, extended to return .res as 'object'-file - # for .rc input file - if output_dir is None: output_dir = '' - obj_names = [] - for src_name in source_filenames: - (base, ext) = os.path.splitext (src_name) - if ext not in self.src_extensions: - # Better to raise an exception instead of silently continuing - # and later complain about sources and targets having - # different lengths - raise CompileError ("Don't know how to compile %s" % src_name) - if strip_dir: - base = os.path.basename (base) - if ext in self._rc_extensions: - obj_names.append (os.path.join (output_dir, - base + self.res_extension)) - elif ext in self._mc_extensions: - obj_names.append (os.path.join (output_dir, - base + self.res_extension)) - else: - obj_names.append (os.path.join (output_dir, - base + self.obj_extension)) - return obj_names - - # object_filenames () - def compile (self, sources, @@ -420,13 +365,13 @@ lib_opts = gen_lib_options (self, library_dirs, runtime_library_dirs, - libraries) + libraries,debug) if output_dir is not None: output_filename = os.path.join (output_dir, output_filename) if self._need_link (objects, output_filename): - if target_desc == CCompiler.EXECUTABLE: + if target_desc == self.EXECUTABLE: if debug: ldflags = self.ldflags_shared_debug[1:] else: @@ -485,26 +430,11 @@ raise DistutilsPlatformError, \ "don't know how to set runtime library search path for MSVC++" - def library_option (self, lib): - return self.library_filename (lib) - - - def find_library_file (self, dirs, lib, debug=0): - # Prefer a debugging library if found (and requested), but deal - # with it if we don't have one. - if debug: - try_names = [lib + "_d", lib] - else: - try_names = [lib] - for dir in dirs: - for name in try_names: - libfile = os.path.join(dir, self.library_filename (name)) - if os.path.exists(libfile): - return libfile + def library_option (self, lib, debug=0): + if debug: + return self.library_filename (lib + "_d") else: - # Oops, didn't find it in *any* of 'dirs' - return None - - # find_library_file () + return self.library_filename (lib) # class MSVCCompiler + diff -BurN --exclude=*.pyc --minimal distutils.orig/distutils/windowsccompiler.py distutils.patched/distutils/windowsccompiler.py --- distutils.orig/distutils/windowsccompiler.py Thu Jan 1 01:00:00 1970 +++ distutils.patched/distutils/windowsccompiler.py Thu Oct 19 14:42:32 2000 @@ -0,0 +1,223 @@ +"""distutils.windowsccompiler + +Contains WindowsCCompiler, which is the base class for all Windows compilers. + +This module is under development. +Currently it only implements some helper functions. +In the future it might be also provide default implementations for +the compile() and link() methods of the compiler classes. +""" + +# created 2000/09/28, Rene Liebscher + +__revision__ = "$Id: windowsccompiler.py $" + + +from distutils.ccompiler import CCompiler +import os + + +class WindowsCCompiler(CCompiler) : + """Abstract class that serves as base class for all + Windows compilers. + """ + + compiler_type = 'windows' + + # Just set this so CCompiler's constructor doesn't barf. We currently + # don't use the 'set_executables()' bureaucracy provided by CCompiler, + # as it really isn't necessary for this sort of single-compiler class. + # Would be nice to have a consistent interface with UnixCCompiler, + # though, so it's worth thinking about. + executables = {} + + # Private class data (need to distinguish C from C++ source for compiler) + _c_extensions = ['.c'] + _cpp_extensions = ['.cc', '.cpp', '.cxx'] + _rc_extensions = ['.rc'] # resource source files + _mc_extensions = ['.mc'] # messages source files + _rc_obj_extension = '.res' # to what are compiles rc files + _mc_obj_extension = '.res' # to what are compiles rc files + # res-files go for most compilers to the linker, but gcc compiles them + # to a real object file in the compile() method + # so you have to support res-files as source files + _passthrough_extensions = ['.res'] # files not to compile + + # Needed for the filename generation methods provided by the + # base class, CCompiler. ( object_filenames() ) + src_extensions = ( _c_extensions + _cpp_extensions + + _rc_extensions + _mc_extensions + + _passthrough_extensions ) + + obj_extension = '.obj' + static_lib_extension = '.lib' + shared_lib_extension = '.dll' + static_lib_format = shared_lib_format = '%s%s' + exe_extension = '.exe' + + + def __init__ (self, + verbose=0, + dry_run=0, + force=0): + + CCompiler.__init__ (self, verbose, dry_run, force) + + # programs to use + self.cc = None # C/C++ complier + self.linker = None # linker + self.lib = None # librarian + self.rc = None # resource compiler + self.mc = None # message compiler + + # __init__ () + + + # -- Miscellaneous methods ----------------------------------------- + + # overwrite the one from CCompiler to support rc, mc and res-files + def object_filenames (self, + source_filenames, + strip_dir=0, + output_dir=''): + return object_filenames(self,source_filenames,strip_dir,output_dir) + # object_filenames () + + + def find_library_file (self, dirs, lib, debug=0): + return find_library_file(self, dirs, lib, debug) + # find_library_file () + + +# WindowsCCompiler + + + +# plain functions on module level + +# these functions can be used from outside WindowsCCompiler, +# especially from CygwinCCompiler + +# overwrite method from CCompiler to support rc, mc and res-files +def object_filenames (compiler, source_filenames, strip_dir=0, output_dir=''): + # Copied from ccompiler.py, extended to return .res as 'object'-file + # for .rc input file + if output_dir is None: output_dir = '' + obj_names = [] + for src_name in source_filenames: + # use normcase to make sure '.rc' is really '.rc' and not '.RC' + (base, ext) = os.path.splitext (os.path.normcase(src_name)) + if ext not in compiler.src_extensions: + # Better to raise an exception instead of silently continuing + # and later complain about sources and targets having + # different lengths + raise CompileError ("Don't know how to compile %s" % src_name) + if strip_dir: + base = os.path.basename (base) + if ext in compiler._passthrough_extensions: + # these can go unchanged + obj_names.append (os.path.join (output_dir, base + ext)) + elif ext in compiler._rc_extensions: + # these need to be compiled to .res-files + obj_names.append (os.path.join (output_dir, + base + compiler._rc_obj_extension)) + elif ext in compiler._mc_extensions: + obj_names.append (os.path.join (output_dir, + base + compiler._mc_obj_extension)) + else: + obj_names.append (os.path.join (output_dir, + base + compiler.obj_extension)) + return obj_names + +# object_filenames () + + +def find_library_file (compiler, dirs, lib, debug=0): + # List of effective library names to try, in order of preference: + # xxx_????.lib is better than xxx.lib + # and xxx_d.lib is better than xxx.lib if debug is set + # (???? = compiler_type) + # The "_????" suffix is to handle a Python installation for people + # with multiple compilers (primarily Distutils hackers, I suspect + # ;-). The idea is they'd have one static library for each + # compiler they care about, since (almost?) every Windows compiler + # seems to have a different format for static libraries. + if debug: + dlib = (lib + "_d") + try_names = (dlib + "_" + compiler.compiler_type, + lib + "_" + compiler.compiler_type, dlib, lib) + else: + try_names = (lib + "_" + compiler.compiler_type, lib) + for dir in dirs: + for name in try_names: + libfile = os.path.join(dir, compiler.library_filename(name)) + if os.path.exists(libfile): + return libfile + # Oops, didn't find it in *any* of 'dirs' + return None + +# find_library_file () + + +# Because not all windows compilers are configured in Python's config.h file by +# default, we do here some simple test to find out if it could work or if we +# should warn the user that compiling could fail + +COMPATIBILITY_OK = "ok" +COMPATIBILITY_NOTOK = "not ok" +COMPATIBILITY_UNCERTAIN = "uncertain" + +def check_compatibility(compiler_name="FOO",compiler_macro="__FOO__"): + + """Check if the current Python installation (specifically, config.h) + appears amenable to building extensions with FOO. Returns a tuple + (status, details), where 'status' is one of the following constants: + COMPATIBILITY_OK + all is well, go ahead and compile + COMPATIBILITY_NOTOK + doesn't look good + COMPATIBILITY_UNCERTAIN + not sure -- unable to read config.h + 'details' is a human-readable string explaining the situation. + + Note there are two ways to conclude "OK": either 'sys.version' contains + the string "FOO" (implying that this Python was built with FOO), or the + installed "config.h" contains the string "__FOO__". + + compiler_name is the name as it could be found in sys.version. + compiler_macro is the macro name which would be used to start a compiler + specific section in config.h. + """ + + from distutils import sysconfig + import string,sys + # if sys.version contains FOO then python was compiled with + # FOO, and the config.h file should be OK + if string.find(sys.version,compiler_name) >= 0: + return (COMPATIBILITY_OK, "sys.version mentions '%s'" % compiler_name) + + fn = sysconfig.get_config_h_filename() + try: + # It would probably better to read single lines to search. + # But we do this only once, and it is fast enough + f = open(fn) + s = f.read() + f.close() + + except IOError, exc: + # if we can't read this file, we cannot say it is wrong + # the compiler will complain later about this file as missing + return (COMPATIBILITY_UNCERTAIN, + "couldn't read '%s': %s" % (fn, exc.strerror)) + + else: + # "config.h" contains an "#ifdef __FOO__" or something similar + if string.find(s,compiler_macro) >= 0: + return (COMPATIBILITY_OK, + "'%s' mentions '%s'" % (fn,compiler_macro)) + else: + return (COMPATIBILITY_NOTOK, + "'%s' does not mention '%s'" % (fn,compiler_macro)) + +# check_compatibility + --------------731E085DA5F2F5144B5381BE Content-Type: text/plain; charset=us-ascii; name="archive_util.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="archive_util.patch" diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/archive_util.py distutils.patched/distutils/archive_util.py --- distutils.orig/distutils/archive_util.py Tue Sep 26 11:28:52 2000 +++ distutils.patched/distutils/archive_util.py Sat Oct 7 09:55:25 2000 @@ -7,7 +7,7 @@ __revision__ = "$Id: archive_util.py,v 1.9 2000/09/26 02:13:49 gward Exp $" -import os +import os,string from distutils.errors import DistutilsExecError from distutils.spawn import spawn from distutils.dir_util import mkpath @@ -143,7 +143,7 @@ if root_dir is not None: if verbose: print "changing into '%s'" % root_dir - base_name = os.path.abspath(base_name) + base_name = path_relative_to(base_name,root_dir) if not dry_run: os.chdir(root_dir) @@ -166,8 +166,37 @@ if root_dir is not None: if verbose: print "changing back to '%s'" % save_cwd + filename = path_relative_to(filename,save_cwd) os.chdir(save_cwd) return filename # make_archive () + +def path_relative_to(base_name,root_dir): + # save the file name + (base_name,file_name) = os.path.split(os.path.abspath(base_name)) + root_dir = os.path.abspath(root_dir) + # is there a common prefix? + # win32: (C:\foo,C:\bar)=> "C:\" or (C:\...,D:\...) => "" + # the second case has to result in an absolute path as return value + # unix: at least the root slash is common + common_prefix = len(os.path.commonprefix([base_name,root_dir])) + # any common prefix (win32: both on same drive) + base_name = base_name[common_prefix:] + root_dir = root_dir[common_prefix:] + if (base_name <> "") and (base_name[0] == os.sep): + # test for "/foo..." + # could happen for common_prefix(["/abc/foo...","/abc/foo"]) + base_name = base_name[1:] + if (root_dir <> "") and (root_dir[0] == os.sep): + # test for "/foo..." + # could happen for common_prefix(["/abc","/abc/foo..."]) + root_dir = root_dir[1:] + if (common_prefix > 0) and (root_dir <> ""): + number_of_pardirs = len(string.split(root_dir,os.sep)) + par_dirs = string.join([os.pardir]*number_of_pardirs,os.sep) + else: + # no common prefix (only possible on win32) + par_dirs = "" + return os.path.join(par_dirs,base_name,file_name) \ No newline at end of file --------------731E085DA5F2F5144B5381BE-- From R.Liebscher@gmx.de Thu Oct 19 11:26:54 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Thu Oct 19 10:26:54 2000 Subject: [Distutils] extra files into the package dir References: <00be01c0387f$64287930$f73f93cd@visionart.com> <39ED9849.A0AF5CBF@gmx.de> Message-ID: <39EF0380.2D4E5A87@gmx.de> Berthold Höllmann wrote: > > >>>>> "Rene" == Rene Liebscher writes: > > Rene> Pete Shinners wrote: > >> i have some extra files i'd like to have copied into the > >> destination package directory when installing. > >> > >> it seems that distutils only installs the .PY(C) files when > >> installing a package directory. how can i tell distutils to > >> copy my other files too? > >> > >> does this involve 'extending' the install command? i could > >> probably do that if there were docs or an example of something > >> like that. > >> > Rene> I had a similar problem with PyOpenGL. (It needs some data > Rene> files for its examples.) May be my solution is what you > Rene> need. (At least it could serve as an example.) > > Rene> Look at the following address: > Rene> http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/PyOpenGL/?cvsroot=PyOpenGL > > Rene> "my_install_data.py" extends distutils' install_data > Rene> command. "setup.py" uses then this alternative command. (The > Rene> important parts are at the end of this file. One is the > Rene> specification of this alternative install command = > Rene> "cmdclass" parameter of the setup function. The other is the > Rene> "data_files" parameter to the setup function.) > > 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. > 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 ) Kind regards Rene Liebscher From gward@python.net Thu Oct 19 23:01:01 2000 From: gward@python.net (Greg Ward) Date: Thu Oct 19 22:01:01 2000 Subject: [Distutils] Doc tweak: home dirs on Windows Message-ID: <20001019215404.A698@beelzebub> Hi all -- I'm working on polishing and finishing up the "Installing Python Modules" manual, and I notice the following sentence: Since Windows has no conception of a user's home directory, and since the standard Python installation under Windows is simpler than that under Unix, there's no point in having separate \longprogramopt{prefix} and \longprogramopt{home} options. (Please excuse the LaTeX markup!) My understanding, gleaned from a rather involved discussion on python-dev some months ago is that this is not entirely true. Thus, I propose changing this to sentence to: Since Windows has only a vague and fuzzy notion of a user's home directory, and the exact definition varies across different Windows versions, the \command{install} command makes no attempt to figure out a home directory. There's no point in having separate \longprogramopt{prefix} and \longprogramopt{home} options, so only \longprogramopt{prefix} is supported. That's my understanding of the situation. Does this sound right to everyone? Greg -- Greg Ward gward@python.net http://starship.python.net/~gward/ From mcoleman2@kc.rr.com Sat Oct 21 00:30:01 2000 From: mcoleman2@kc.rr.com (Mike Coleman) Date: Fri Oct 20 23:30:01 2000 Subject: [Distutils] Can distutils handle PYTHONPATH? In-Reply-To: "Greg Ward"'s message of "Sat, 14 Oct 2000 18:22:54 -0400" References: <20001013231046.G639@beelzebub> <87bswoq6x7.fsf@kc.net> <20001014182254.A878@beelzebub> Message-ID: <87n1fy50u9.fsf_-_@kc.net> Hi, I've been looking at distutils to package my python project (see subterfugue.org, if curious), and I think I've stumbled across a problem. Two parts of my project are the main python code, which resides in the "root" (no) package, and one or more directories of "tricks" (like plugins), which are python modules, also in the "root" package, which the main code imports. The tricks get imported by virtue of trick directories being on PYTHONPATH. End users can also write their own tricks, and add them by putting their directory on PYTHONPATH. I don't want to put the tricks in a package, because that would complicate the steps for end users wanting to add their own tricks. It appears, though, that distutils wants all python code for the "root" package to live in a single directory. As far as I can tell, the only way I could use distutils is to break the tricks into one or more separate pieces, which I'm pretty reluctant to do. Any suggestions? Thanks, --Mike (please Cc me on this thread) -- [O]ne of the features of the Internet [...] is that small groups of people can greatly disturb large organizations. --Charles C. Mann From sanner@scripps.edu Mon Oct 23 16:40:25 2000 From: sanner@scripps.edu (Michel Sanner) Date: Mon Oct 23 15:40:25 2000 Subject: [Distutils] Package installation strategy ! In-Reply-To: Mike Coleman "[Distutils] Can distutils handle PYTHONPATH?" (Oct 20, 10:29pm) References: <20001013231046.G639@beelzebub> <87bswoq6x7.fsf@kc.net> <20001014182254.A878@beelzebub> <87n1fy50u9.fsf_-_@kc.net> Message-ID: <1001023115013.ZM74191@noah.scripps.edu> 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 ? Should we ise the PyOpenGL strategy of extending the path with a sub-directory for platform specific stuff at run time ? or should we place all .so files in lib-dynload ? 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!) 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. Thanks for any thoughts/hints/advise on this -Michel -- ----------------------------------------------------------------------- >>>>>>>>>> AREA CODE CHANGE <<<<<<<<< we are now 858 !!!!!!! Michel F. Sanner Ph.D. The Scripps Research Institute Assistant Professor Department of Molecular Biology 10550 North Torrey Pines Road Tel. (858) 784-2341 La Jolla, CA 92037 Fax. (858) 784-2860 sanner@scripps.edu http://www.scripps.edu/sanner ----------------------------------------------------------------------- From Paul.Moore@uk.origin-it.com Tue Oct 24 10:21:01 2000 From: Paul.Moore@uk.origin-it.com (Moore, Paul) Date: Tue Oct 24 09:21:01 2000 Subject: [Distutils] Installation directory Message-ID: <714DFA46B9BBD0119CD000805FC1F53B012A834E@UKRUX002.rundc.uk.origin-it.com> I haven't been involved with Python for quite a while now, having been doing work with Perl instead. I was recently prompted to have another look at Python. (I don't have strong enough views on scripting languages to be described as a proper convert, though...) I was fairly quickly drawn into a discussion on 3rd party modules, and on the back of a comment that Python really needs a repository of packages like Perl's CPAN, I said that what was really important was that Python had a standardised build and distribution process, like Perl's MakeMaker and the standard Perl directory structure. As usual when I make comments like this, I immediately discovered distutils, which seems almost exactly what I was thinking of... :-) So I printed out the documentation, downloaded and skimmed the mailing list archive (not had time to read all 1600 messages yet!) and had a go with it. So far, I've only played with "pure python" modules, but it looks quite nice. I do, however, have one problem with it, which may be more a Python issue than a distutils issue, but I thought I'd raise it here anyway. I'm working on Win32, with Python 2.0 (the ActiveState distribution, although I don't believe there is any fundamental difference between this and the BeOpen distribution). When I package a module, and then unpack it, it is installed directly into the C:\Applications\Python20 directory, which is the Python installation directory. This is not what I would want, especially as the default action. (Excuse the mention of Perl here...) When Perl is built and installed, it creates a directory structure under its installation directory, consisting of a "bin" directory (executables and DLLs), a "lib" directory (library modules) and a "site" directory (locally installed modules). The "site" directory is empty by default, but is where all MakeMaker-installed modules are placed. I would like it if Python worked similarly. Clearly, there isn't any point in changing the existing directory structure, but adding a ...\Python20\Site directory, and having distutils install modules there by default, would help to separate components of the installation from local additions. I guess this requires co-operation from the Python core, as it would need ...\Python20\Site adding by default into the sys.path list. Does this idea make sense? Is it worth doing, or have I missed something fundamental? (BTW, I have no idea if Python on Unix is set up differently - maybe this is already in place there...? Thanks for your time, Paul Moore. From Paul.Moore@uk.origin-it.com Tue Oct 24 10:29:09 2000 From: Paul.Moore@uk.origin-it.com (Moore, Paul) Date: Tue Oct 24 09:29:09 2000 Subject: [Distutils] Some suggested additions for distutils Message-ID: <714DFA46B9BBD0119CD000805FC1F53B012A834F@UKRUX002.rundc.uk.origin-it.com> I've just started looking at distutils. There are two things which I feel would be nice to add to the existing functionality. 1. A --dry-run option to the install action. This could list what was going to be done, but not actually do it. This would be useful for testing installations, or for systems admins who want to be sure what an installer is going to do before starting. 2. An uninstall action. This can be simulated by doing a python setup.py install --record installation.log and then using the list of files in install.log as a list of files to delete. However, a proper uninstall action would be nice. (And I don't know if there are more complex installs where the above workaround would be inadequate...) Thanks, Paul Moore From akuchlin@mems-exchange.org Tue Oct 24 10:35:01 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue Oct 24 09:35:01 2000 Subject: [Distutils] Some suggested additions for distutils In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B012A834F@UKRUX002.rundc.uk.origin-it.com>; from Paul.Moore@uk.origin-it.com on Tue, Oct 24, 2000 at 02:27:32PM +0100 References: <714DFA46B9BBD0119CD000805FC1F53B012A834F@UKRUX002.rundc.uk.origin-it.com> Message-ID: <20001024093443.A27938@kronos.cnri.reston.va.us> On Tue, Oct 24, 2000 at 02:27:32PM +0100, Moore, Paul wrote: >1. A --dry-run option to the install action. This could list what was going >to be done, but not actually do it. This would be useful for testing >installations, or for systems admins who want to be sure what an installer >is going to do before starting. Greg's already used the time machine to add that feature: kronos ZEO>python setup.py --help Global options: --verbose (-v) run verbosely (default) --quiet (-q) run quietly (turns verbosity off) --dry-run (-n) don't actually do anything --help (-h) show detailed help message Information display options (just display information, ignore any commands) ... I'm not sure what technical problems there are with respect to uninstalling. --amk From calvin@cs.uni-sb.de Tue Oct 24 10:36:02 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Tue Oct 24 09:36:02 2000 Subject: [Distutils] Some suggested additions for distutils In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B012A834F@UKRUX002.rundc.uk.origin-it.com> Message-ID: Hello all, >2. An uninstall action. This can be simulated by doing a python setup.py >install --record installation.log and then using the list of files in >install.log as a list of files to delete. However, a proper uninstall action >would be nice. (And I don't know if there are more complex installs where >the above workaround would be inadequate...) Hmm, I would vote for a .log file as a Python Module which not only holds installation parameters (files, dirs,...) but also metadata. Suppose you are installing a package named "helicopter". The install command would create a module "helicopterConf.py" and copies it into the install_lib dir. Then you can write Python code, import this module and have access to all used install_* directories, installed files, author, version, etc. Bastian From Paul.Moore@uk.origin-it.com Tue Oct 24 10:40:02 2000 From: Paul.Moore@uk.origin-it.com (Moore, Paul) Date: Tue Oct 24 09:40:02 2000 Subject: [Distutils] Some suggested additions for distutils Message-ID: <714DFA46B9BBD0119CD000805FC1F53B012A8350@UKRUX002.rundc.uk.origin-it.com> From: Andrew Kuchling [mailto:akuchlin@mems-exchange.org] > > Greg's already used the time machine to add that feature: > > kronos ZEO>python setup.py --help > Global options: > --verbose (-v) run verbosely (default) > --quiet (-q) run quietly (turns verbosity off) > --dry-run (-n) don't actually do anything > --help (-h) show detailed help message Missed that one. I think I was looking at the help for the install command, not at the global help. Sorry, Paul. From calvin@cs.uni-sb.de Tue Oct 24 10:44:03 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Tue Oct 24 09:44:03 2000 Subject: [Distutils] Installation directory In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B012A834E@UKRUX002.rundc.uk.origin-it.com> Message-ID: Hi all, >it is installed directly into the C:\Applications\Python20 directory, which >is the Python installation directory. This is not what I would want, >especially as the default action. There was a somewhat lengthy discussion about installation dirs at the beginning of the year, including some mighty words from Guido. You can follow the discussion on the archives, here is a wrapup: http://www.python.org/pipermail/distutils-sig/2000-February/001181.html I think in most cases it boils down to installing things in sys.prefix and sys.exec_prefix. Nothing prevents you from using your custom install scheme though (with --install-lib and such). Bastian From Paul.Moore@uk.origin-it.com Tue Oct 24 11:00:01 2000 From: Paul.Moore@uk.origin-it.com (Moore, Paul) Date: Tue Oct 24 10:00:01 2000 Subject: [Distutils] Installation directory Message-ID: <714DFA46B9BBD0119CD000805FC1F53B012A8351@UKRUX002.rundc.uk.origin-it.com> From: Bastian Kleineidam [mailto:calvin@cs.uni-sb.de] > >it is installed directly into the > >C:\Applications\Python20 directory, which is > >the Python installation directory. This is not > >what I would want, especially as the default > >action. > > There was a somewhat lengthy discussion > about installation dirs at the beginning > of the year, including some mighty words > from Guido. You can follow the discussion > on the archives, here is a wrapup: > http://www.python.org/pipermail/distutils-sig/20 > 00-February/001181.html I think in most cases it > boils down to installing things in sys.prefix > and sys.exec_prefix. OK. So the current behaviour is by design. That's fair enough - I don't personally like it, but that isn't a good reason for it to change. > Nothing prevents you from using your custom > install scheme though (with --install-lib and > such). 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? 2. What happens with binary distributions? (I've not tried building one of these yet, so it may be obvious...) Can I install a binary distribution and specify --install-lib, or is the bdist_wininst version unable to accept command line overrides? Actually, a third (Python) question: If I do add a "site library" directory, what do I need to do to get Python to recognise it by default? Looking at the documentation of the site module, it looks like Unix has a site-python directory already, via sys.prefix, whereas Windows doesn't. Should/could I just set sys.prefix somehow? (Maybe this should be directed to somewhere like the Python newsgroup, though). Paul From calvin@cs.uni-sb.de Tue Oct 24 11:28:02 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Tue Oct 24 10:28:02 2000 Subject: [Distutils] Installation directory In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B012A8351@UKRUX002.rundc.uk.origin-it.com> Message-ID: Hi Paul, >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? Config files are supported since May 2000, but not yet documented. Here is the archive mail: http://www.python.org/pipermail/distutils-sig/2000-May/001482.html >2. What happens with binary distributions? (I've not tried building one of >these yet, so it may be obvious...) Can I install a binary distribution and >specify --install-lib, or is the bdist_wininst version unable to accept >command line overrides? No custom schemes for .exe binary distributions. >Actually, a third (Python) question: If I do add a "site library" directory, >what do I need to do to get Python to recognise it by default? Looking at >the documentation of the site module, it looks like Unix has a site-python >directory already, via sys.prefix, whereas Windows doesn't. Should/could I >just set sys.prefix somehow? (Maybe this should be directed to somewhere >like the Python newsgroup, though). You can set the environment variable PYTHONPATH to give additional directories to search for python modules. Bastian From robin@alldunn.com Tue Oct 24 12:52:23 2000 From: robin@alldunn.com (Robin Dunn) Date: Tue Oct 24 11:52:23 2000 Subject: [Distutils] Installation directory References: Message-ID: <006a01c03dd2$19d72310$0b01a8c0@ARES> > > >Actually, a third (Python) question: If I do add a "site library" directory, > >what do I need to do to get Python to recognise it by default? Looking at > >the documentation of the site module, it looks like Unix has a site-python > >directory already, via sys.prefix, whereas Windows doesn't. Should/could I > >just set sys.prefix somehow? (Maybe this should be directed to somewhere > >like the Python newsgroup, though). > > You can set the environment variable PYTHONPATH to give additional > directories to search for python modules. > Or add it to the registry in HKLM\Software\Python\PythonCore\2.0\PythonPath, or make a file named sitecustomize.py in your Python root directory that imports sys and inserts or appends to sys.path directly. -- Robin Dunn Software Craftsman robin@AllDunn.com http://wxPython.org Java give you jitters? http://wxPROs.com Relax with wxPython! From Mark Evans Wed Oct 25 17:59:01 2000 From: Mark Evans (Mark Evans) Date: Wed Oct 25 16:59:01 2000 Subject: [Distutils] Network Admin Full Python 2.0 Setup Message-ID: <15118451682.20001025160515@clarisay.com> 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. My thought is that a Python script on some preconfigured master PC could read its own install.log and perform, line by line, the actions indicated, including file copies and Windows registry settings. Please send any answers to my email address as I have not subscribed to the SIG. Thanks, Mark Evans mailto:mark.evans@clarisay.com From vanandel@acm.org Thu Oct 26 00:13:01 2000 From: vanandel@acm.org (Joseph VanAndel) Date: Wed Oct 25 23:13:01 2000 Subject: [Distutils] Re: distutils? References: <39F6E2EF.C8A2CA3E@atd.ucar.edu> <001001c03ea2$13bc3760$5f42c3d1@cyberus.ca> Message-ID: <39F7A01E.4BF8850@ucar.edu> re: CREATING PYTHON EXTENSIONS USING BORLAND'S FREE COMPILER http://www.cyberus.ca/~g_will/pyExtenDL.shtml (I'm copying Greg Ward and the distutils-sig to see if we can't build cooperate here.) Gordon Williams wrote: > > This is really a tutorial plus a few other things rather than a "package". > It is for creating extensions using the Borland compiler that can be used > with the Microsoft compiled standard distribution. Maybe this wasn't clear > in the [ANN]? > > Download it and have a look. I'm not familiar with distutils (I just had a > quick read) but I don't think that it is appropriate. If you think that > distutils should be used please get back to me. Gordon: You've written some nice instructions on how to obtain and install the Borland free compiler. You provide instructions on how to customize batch files to compile and link extensions on Windows. Actually, 'distutils' is precisely designed to build extensions. Rather than .bat scripts, you describe how to build your extension in a 'setup.py' file. The advantage of using distutils is that it can compile your code on multiple platforms, with a minimum amount of machine dependencies in the script. And of course, distutils ships standard with Python 2.0. distutils now works with the Microsoft Visual C compiler. There was some work done on using the free Borland compiler, but I don't know if it was finished. Greg (and the distutils gang) - is the free Borland compiler support for Windows working at present? From fdrake@acm.org Thu Oct 26 01:04:01 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu Oct 26 00:04:01 2000 Subject: [Distutils] Re: distutils? In-Reply-To: <39F7A01E.4BF8850@ucar.edu> References: <39F6E2EF.C8A2CA3E@atd.ucar.edu> <001001c03ea2$13bc3760$5f42c3d1@cyberus.ca> <39F7A01E.4BF8850@ucar.edu> Message-ID: <14839.44174.994010.22408@cj42289-a.reston1.va.home.com> Gordon Williams wrote: > This is really a tutorial plus a few other things rather than a "package". > It is for creating extensions using the Borland compiler that can be used > with the Microsoft compiled standard distribution. Maybe this wasn't clear > in the [ANN]? Joseph VanAndel writes: > You've written some nice instructions on how to obtain and install the > Borland free compiler. You provide instructions on how to customize > batch files to compile and link extensions on Windows. Would this information also be useful in the Extending & Embedding manual? I've not read the instructions yet (there didn't seem to be a copy I could look at without downloading a ZIP file), but I know the "compiling on Windows" section is in need of some serious revamping. -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From g_will@cyberus.ca Thu Oct 26 09:10:45 2000 From: g_will@cyberus.ca (Gordon Williams) Date: Thu Oct 26 08:10:45 2000 Subject: [Distutils] Re: distutils? - Borland Extensions References: <39F6E2EF.C8A2CA3E@atd.ucar.edu><001001c03ea2$13bc3760$5f42c3d1@cyberus.ca><39F7A01E.4BF8850@ucar.edu> <14839.44174.994010.22408@cj42289-a.reston1.va.home.com> Message-ID: <000901c03f45$5108d300$b542c3d1@cyberus.ca> Download the zip file and have a look at the instructions and examples. You are welcome to use the parts that you want in your manual. I agree the manual could do with a bit of a revamp in that section. It took me a long time to make the whole thing work because of the incompatibilities between the Microsoft and Borland Compilers. I'm sure others could use some tips. You can also put a link to my site on the python.org "how to" section if you like. Regards, Gordon Williams ----- Original Message ----- From: "Fred L. Drake, Jr." To: "Gordon Williams" Cc: Sent: Thursday, October 26, 2000 12:01 AM Subject: Re: [Distutils] Re: distutils? > > Gordon Williams wrote: > > This is really a tutorial plus a few other things rather than a "package". > > It is for creating extensions using the Borland compiler that can be used > > with the Microsoft compiled standard distribution. Maybe this wasn't clear > > in the [ANN]? > > Joseph VanAndel writes: > > You've written some nice instructions on how to obtain and install the > > Borland free compiler. You provide instructions on how to customize > > batch files to compile and link extensions on Windows. > > Would this information also be useful in the Extending & Embedding > manual? I've not read the instructions yet (there didn't seem to be a > copy I could look at without downloading a ZIP file), but I know the > "compiling on Windows" section is in need of some serious revamping. > > > -Fred > > -- > Fred L. Drake, Jr. > PythonLabs Team Member > From g_will@cyberus.ca Thu Oct 26 09:51:45 2000 From: g_will@cyberus.ca (Gordon Williams) Date: Thu Oct 26 08:51:45 2000 Subject: [Distutils] Re: distutils?- Borland Extensions References: <39F6E2EF.C8A2CA3E@atd.ucar.edu> <001001c03ea2$13bc3760$5f42c3d1@cyberus.ca> <39F7A01E.4BF8850@ucar.edu> Message-ID: <000f01c03f4a$c099ab40$b542c3d1@cyberus.ca> If you want to use distutils with Borland to compile extensions to work with the MS binary distribution you will have to have some way of using the COFF2OMF import library conversion tool on the python20.lib file. We need to link with the converted library and not the python20.lib which is supplied with the distribution. (See the instructions about mypylib.lib) While I can see potential uses for distutils for distributing code across multiple platforms it appears to be an extra level of complication for someone who it doing it for internal use or distributing to only one platform (e.g. windows). Maybe it is very easy to setup and use but from the amount of documentation I think there is a bit of a learning curve. When I distribute programs I use Gordon's Installer to make a standalone package with python, gui and all the scripts and .pyd files. That way I know that there will not be any incompatibilities with old versions, missing parts, etc. This method is not suitable for everyone though. If you get distutils to work with Borland to make extensions you can send me a copy (maybe using one of the examples that I give in the package) so I can have a look. Regards, Gordon Williams ----- Original Message ----- From: "Joseph VanAndel" To: "Gordon Williams" Cc: ; Sent: Wednesday, October 25, 2000 11:08 PM Subject: Re: distutils? > re: CREATING PYTHON EXTENSIONS USING BORLAND'S FREE COMPILER > http://www.cyberus.ca/~g_will/pyExtenDL.shtml > > (I'm copying Greg Ward and the distutils-sig to see if we can't build > cooperate here.) > > Gordon Williams wrote: > > > > > This is really a tutorial plus a few other things rather than a "package". > > It is for creating extensions using the Borland compiler that can be used > > with the Microsoft compiled standard distribution. Maybe this wasn't clear > > in the [ANN]? > > > > Download it and have a look. I'm not familiar with distutils (I just had a > > quick read) but I don't think that it is appropriate. If you think that > > distutils should be used please get back to me. > > Gordon: > You've written some nice instructions on how to obtain and install the > Borland free compiler. You provide instructions on how to customize > batch files to compile and link extensions on Windows. > > Actually, 'distutils' is precisely designed to build extensions. Rather > than .bat scripts, you describe how to build your extension in a > 'setup.py' file. The advantage of using distutils is that it can > compile your code on multiple platforms, with a minimum amount of > machine dependencies in the script. And of course, distutils ships > standard with Python 2.0. > > distutils now works with the Microsoft Visual C compiler. There was > some work done on using the free Borland compiler, but I don't know if > it was finished. > > Greg (and the distutils gang) - is the free Borland compiler support for > Windows working at present? > From ljohnson@resgen.com Thu Oct 26 15:49:02 2000 From: ljohnson@resgen.com (Lyle Johnson) Date: Thu Oct 26 14:49:02 2000 Subject: [Distutils] Update the HTML documentation at www.python.org? Message-ID: Greg et al, If anyone still has control over the distutils documentation stored here: http://www.python.org/sigs/distutils-sig/doc/dist/dist.html You might want to update it to the latest version. A question was recently posted to the newsgroup about the missing "extensions" keyword argument for setup() -- which is correctly labelled "ext_modules" in the latest version of the distutils documentation bundled with Python 2.0. From fdrake@acm.org Thu Oct 26 18:17:03 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu Oct 26 17:17:03 2000 Subject: [Distutils] Update the HTML documentation at www.python.org? In-Reply-To: References: Message-ID: <14840.40578.130053.540190@cj42289-a.reston1.va.home.com> Lyle Johnson writes: > If anyone still has control over the distutils documentation stored here: > > http://www.python.org/sigs/distutils-sig/doc/dist/dist.html > > You might want to update it to the latest version. A question was recently > posted to the newsgroup about the missing "extensions" keyword argument for > setup() -- which is correctly labelled "ext_modules" in the latest version > of the distutils documentation bundled with Python 2.0. If Greg doesn't get to it I'll try and update it next week. I don't want to get in his way if he plans to do anything about it. Thanks for pointing this out! -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From gustav@morpheus.demon.co.uk Fri Oct 27 18:01:13 2000 From: gustav@morpheus.demon.co.uk (Paul Moore) Date: Fri Oct 27 17:01:13 2000 Subject: [Distutils] Manifest.in not included in sdist... Message-ID: This seems odd to me... When I build a source distribution with python setup.py sdist, my MANIFEST.in file is not included in the resulting archive. This seems wrong, as without the MANIFEST.in, I cannot rebuild the distribution. I would assume that building a sdist should create save everything needed to rebuild the package, its sdist, etc etc, from scratch. Another thought - a "reallyclean" command would be nice (deletes all intermediate and generated files - essentially all of the "build" and "dist" directories, at least... Thanks, Paul Moore From martin@loewis.home.cs.tu-berlin.de Fri Oct 27 18:43:04 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Fri Oct 27 17:43:04 2000 Subject: [Distutils] Re: [I18n-sig] Codecs for Big Five and GB 2312 In-Reply-To: <200010270110.KAA16842@dhcp198.grad.sccs.chukyo-u.ac.jp> (message from Tamito KAJIYAMA on Fri, 27 Oct 2000 10:10:10 +0900) References: <200010262342.IAA16679@dhcp198.grad.sccs.chukyo-u.ac.jp> <200010270110.KAA16842@dhcp198.grad.sccs.chukyo-u.ac.jp> Message-ID: <200010272140.XAA00906@loewis.home.cs.tu-berlin.de> > If you are interested, the codec is available at: > http://pseudo.grad.sccs.chukyo-u.ac.jp/~kajiyama/python/iso_2022_7bit.py.gz I just had a look, and it seems like an interesting package. I'm slightly confused about the installation procedure, though. Installing into python2.0/encodings/{euc_jp,shift_jis,japanese} doesn't look right to me - add-on packages should be capable of installing into site-packages by default. I believe it would actually work if you just install without any arguments to setup.py. euc_jp would then end-up in python2.0/site-packages. Later, when you do u"Hello".encode("euc-jp") it looks for a codec. Here, encodings.__init__.search_function do modname = encoding.replace('-', '_') modname = aliases.aliases.get(modname,modname) try: mod = __import__(modname,globals(),locals(),'*') except ImportError,why: _cache[encoding] = None return None First, encoding becomes euc_jp. With no registered aliases, it would then call __import__ with "euc_jp", which will find the codec in site-packages. In the long run, I'd hope that distutils provides a mean to install additional codecs, e.g via setup( ... codecs = ['japanese'] ...) Then, distutils would collect all these strings, and importing codecs would roughly do for package in distutils.registered_codec_packages: p=__import__(package,global(),locals(),"*") p.register() japanese/__init__.py would provide a register function which registers another search_function, which would load euc_jp and shift_jis on demand. That way, users could install additional codecs which are available to everybody on the system, without having to hack the Python library proper. Regards, Martin From gpward@starpower.net Sat Oct 28 10:52:02 2000 From: gpward@starpower.net (Greg Ward) Date: Sat Oct 28 09:52:02 2000 Subject: [Distutils] Re: Newbie needs (begs for) help (fwd) In-Reply-To: ; from jamest@math.ksu.edu on Sun, Oct 22, 2000 at 11:08:16AM -0500 References: Message-ID: <20001027212046.B904@beelzebub> On 22 October 2000, James Thompson said: > I hate to bother you personally but the list is screwed and I'm pushing > for a new release for our app w/ distutil support today. Bad luck! Due to the Starship outage, your mail to me sat in limbo for almost a week. Dunno what's up with the Distutils list... > I have an application that is partially modules, a few packages, and a > final application or two. > > I'd like the application to end up in equiv of autoconfs prefix (/usr/bin, > /usr/local/bin) and everything else to end up is a gnue directory (or > below it in as a package) > > site-packages/gnue > site-packages/gnue/forms/* > site-packages/gnue/misc/* > > I've found that distutils (1.0.1) doesn't allow mixing packages, modules > in setup.py so I assume this will require me doing every thing as a > package. That's a feature -- it's meant to *encourage* people to put their modules into packages. ;-) But if you still have "legacy" top-level modules, that's OK: just tell the Distutils to process the "root package". Eg. packages = ['', 'gnue', 'gnue.forms', 'gnue.misc'] Every "root package" module found in your source tree will wind up in site-packages, unless you specify a .pth file with the 'extra_path' option. > But I can't find anything on how to get the main app in > /usr/local/bin or how to include docs/man pages etc. For the main app: scripts = ['script'] will copy "script" to /usr/local/bin (or whatever the prefix of the current Python interprerter is), with the #! line fixed to point to the interpreter used for the build. Docs and man pages are not handled, because there is no standard documentation format in the Python world. That's a bug, but not one I can fix single-handedly. ;-( Greg -- Greg Ward gward@python.net From mal@lemburg.com Sat Oct 28 11:00:05 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat Oct 28 10:00:05 2000 Subject: [Distutils] Re: [I18n-sig] Codecs for Big Five and GB 2312 References: <200010262342.IAA16679@dhcp198.grad.sccs.chukyo-u.ac.jp> <200010270110.KAA16842@dhcp198.grad.sccs.chukyo-u.ac.jp> <200010272140.XAA00906@loewis.home.cs.tu-berlin.de> Message-ID: <39FADBCC.B19B65C9@lemburg.com> "Martin v. Loewis" wrote: > > > If you are interested, the codec is available at: > > > http://pseudo.grad.sccs.chukyo-u.ac.jp/~kajiyama/python/iso_2022_7bit.py.gz > > I just had a look, and it seems like an interesting package. I'm > slightly confused about the installation procedure, though. > Installing into python2.0/encodings/{euc_jp,shift_jis,japanese} > doesn't look right to me - add-on packages should be capable of > installing into site-packages by default. > > I believe it would actually work if you just install without any > arguments to setup.py. euc_jp would then end-up in > python2.0/site-packages. Later, when you do > > u"Hello".encode("euc-jp") > > it looks for a codec. Here, encodings.__init__.search_function do > > modname = encoding.replace('-', '_') > modname = aliases.aliases.get(modname,modname) > try: > mod = __import__(modname,globals(),locals(),'*') > except ImportError,why: > _cache[encoding] = None > return None > > First, encoding becomes euc_jp. With no registered aliases, it would > then call __import__ with "euc_jp", which will find the codec in > site-packages. The "right" way to install new codec packages is by placing them inside a package which then registers a new search function in the codec registry. Tamito's other does this AFAIR. To be able to use the codecs, a Python script must then import the codecs package (which then registers the search function). Having to import the package has two benefits: 1. the need for another codec package is visible in the source code 2. registering the search function is delayed until the codec package is first used > In the long run, I'd hope that distutils provides a mean to install > additional codecs, e.g via > > setup( ... > codecs = ['japanese'] > ...) > > Then, distutils would collect all these strings, and importing codecs > would roughly do > > for package in distutils.registered_codec_packages: > p=__import__(package,global(),locals(),"*") > p.register() > > japanese/__init__.py would provide a register function which registers > another search_function, which would load euc_jp and shift_jis on > demand. That way, users could install additional codecs which are > available to everybody on the system, without having to hack the > Python library proper. Hmm, not sure here: programs which rely on non-standard codecs should have an explicit "import myCodecs" at the top of the file. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From martin@loewis.home.cs.tu-berlin.de Sat Oct 28 17:33:01 2000 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sat Oct 28 16:33:01 2000 Subject: [Distutils] Re: [I18n-sig] Codecs for Big Five and GB 2312 In-Reply-To: <39FADBCC.B19B65C9@lemburg.com> (mal@lemburg.com) References: <200010262342.IAA16679@dhcp198.grad.sccs.chukyo-u.ac.jp> <200010270110.KAA16842@dhcp198.grad.sccs.chukyo-u.ac.jp> <200010272140.XAA00906@loewis.home.cs.tu-berlin.de> <39FADBCC.B19B65C9@lemburg.com> Message-ID: <200010282026.WAA00748@loewis.home.cs.tu-berlin.de> > Having to import the package has two benefits: > 1. the need for another codec package is visible in the source code I don't think this is a benefit for a typical application that uses multiple codecs. More often than not, the application will learn about a required encoding by means of an application-level protocol (e.g. a Content-Type in a MIME header). It doesn't really *require* any encoding; instead, it needs the codecs of any data it happens to process in a certain session. The application designer is normally not interested in a specific encoding; she expects Python to do the right thing whenever .encode is invoked. > 2. registering the search function is delayed until the codec > package is first used That is hardly a benefit: registering the search function is not an expensive operation, and the typical application would start with try: import japanese except ImportError: pass try: import windows_codepages except ImportError: pass try: import iana except ImportError: pass try: import OSFCharmaps except ImportError: pass anyway, so all codecs it may need are registered right from the start. Regards, Martin From calvin@cs.uni-sb.de Sun Oct 29 12:54:01 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Sun Oct 29 12:54:01 2000 Subject: [Distutils] Patches for install.dump_dirs and install_scripts Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1619418364-242543331-972841896=:15199 Content-Type: TEXT/PLAIN; charset=US-ASCII . Hi all, the first patch fixes the debugging routine dump_dirs. This bug occurs only with DISTUTILS_DEBUG defined. The second patch fixes the initialization of self.outfiles in the install_scripts command. Greetings, Bastian --1619418364-242543331-972841896=:15199 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="dump_dir.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="dump_dir.diff" LS0tIC91c3IvbG9jYWwvc3JjL2Rpc3R1dGlscy9kaXN0dXRpbHMvY29tbWFu ZC9pbnN0YWxsLnB5CVNhdCBPY3QgMTQgMTA6MTg6MzkgMjAwMA0KKysrIGlu c3RhbGwucHkJU3VuIE9jdCAyOSAxODozMzoyMiAyMDAwDQpAQCAtMzM0LDgg KzMzNCwxMyBAQA0KICAgICAgICAgICAgICAgICBvcHRfbmFtZSA9IG9wdFsw XQ0KICAgICAgICAgICAgICAgICBpZiBvcHRfbmFtZVstMV0gPT0gIj0iOg0K ICAgICAgICAgICAgICAgICAgICAgb3B0X25hbWUgPSBvcHRfbmFtZVswOi0x XQ0KLSAgICAgICAgICAgICAgICBvcHRfbmFtZSA9IHN0cmluZy50cmFuc2xh dGUob3B0X25hbWUsIGxvbmdvcHRfeGxhdGUpDQotICAgICAgICAgICAgICAg IHZhbCA9IGdldGF0dHIoc2VsZiwgb3B0X25hbWUpDQorICAgICAgICAgICAg ICAgIGlmIHNlbGYubmVnYXRpdmVfb3B0Lmhhc19rZXkob3B0X25hbWUpOg0K KyAgICAgICAgICAgICAgICAgICAgb3B0X25hbWUgPSBzdHJpbmcudHJhbnNs YXRlKHNlbGYubmVnYXRpdmVfb3B0W29wdF9uYW1lXSwNCisgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsb25nb3B0 X3hsYXRlKQ0KKyAgICAgICAgICAgICAgICAgICAgdmFsID0gbm90IGdldGF0 dHIoc2VsZiwgb3B0X25hbWUpDQorICAgICAgICAgICAgICAgIGVsc2U6DQor ICAgICAgICAgICAgICAgICAgICBvcHRfbmFtZSA9IHN0cmluZy50cmFuc2xh dGUob3B0X25hbWUsIGxvbmdvcHRfeGxhdGUpDQorICAgICAgICAgICAgICAg ICAgICB2YWwgPSBnZXRhdHRyKHNlbGYsIG9wdF9uYW1lKQ0KICAgICAgICAg ICAgICAgICBwcmludCAiICAlczogJXMiICUgKG9wdF9uYW1lLCB2YWwpDQog DQogDQo= --1619418364-242543331-972841896=:15199 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="install_scripts.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="install_scripts.diff" LS0tIC91c3IvbG9jYWwvc3JjL2Rpc3R1dGlscy9kaXN0dXRpbHMvY29tbWFu ZC9pbnN0YWxsX3NjcmlwdHMucHkJTW9uIE9jdCAgOSAyMzoyODo0MCAyMDAw DQorKysgaW5zdGFsbF9zY3JpcHRzLnB5CVN1biBPY3QgMjkgMTg6NDI6Mjkg MjAwMA0KQEAgLTMwLDYgKzMwLDcgQEANCiAgICAgICAgIHNlbGYuZm9yY2Ug PSAwDQogICAgICAgICBzZWxmLmJ1aWxkX2RpciA9IE5vbmUNCiAgICAgICAg IHNlbGYuc2tpcF9idWlsZCA9IE5vbmUNCisgICAgICAgIHNlbGYub3V0Zmls ZXMgPSBbXQ0KIA0KICAgICBkZWYgZmluYWxpemVfb3B0aW9ucyAoc2VsZik6 DQogICAgICAgICBzZWxmLnNldF91bmRlZmluZWRfb3B0aW9ucygnYnVpbGQn LCAoJ2J1aWxkX3NjcmlwdHMnLCAnYnVpbGRfZGlyJykpDQpAQCAtNDIsNyAr NDMsNyBAQA0KICAgICBkZWYgcnVuIChzZWxmKToNCiAgICAgICAgIGlmIG5v dCBzZWxmLnNraXBfYnVpbGQ6DQogICAgICAgICAgICAgc2VsZi5ydW5fY29t bWFuZCgnYnVpbGRfc2NyaXB0cycpDQotICAgICAgICBzZWxmLm91dGZpbGVz ID0gc2VsZi5jb3B5X3RyZWUoc2VsZi5idWlsZF9kaXIsIHNlbGYuaW5zdGFs bF9kaXIpDQorICAgICAgICBzZWxmLm91dGZpbGVzLmV4dGVuZChzZWxmLmNv cHlfdHJlZShzZWxmLmJ1aWxkX2Rpciwgc2VsZi5pbnN0YWxsX2RpcikpDQog ICAgICAgICBpZiBvcy5uYW1lID09ICdwb3NpeCc6DQogICAgICAgICAgICAg IyBTZXQgdGhlIGV4ZWN1dGFibGUgYml0cyAob3duZXIsIGdyb3VwLCBhbmQg d29ybGQpIG9uDQogICAgICAgICAgICAgIyBhbGwgdGhlIHNjcmlwdHMgd2Ug anVzdCBpbnN0YWxsZWQuDQpAQCAtNTgsNiArNTksNiBAQA0KICAgICAgICAg cmV0dXJuIHNlbGYuZGlzdHJpYnV0aW9uLnNjcmlwdHMgb3IgW10NCiANCiAg ICAgZGVmIGdldF9vdXRwdXRzKHNlbGYpOg0KLSAgICAgICAgcmV0dXJuIHNl bGYub3V0ZmlsZXMgb3IgW10NCisgICAgICAgIHJldHVybiBzZWxmLm91dGZp bGVzDQogDQogIyBjbGFzcyBpbnN0YWxsX3NjcmlwdHMNCg== --1619418364-242543331-972841896=:15199-- From mal@lemburg.com Mon Oct 30 03:51:03 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Oct 30 03:51:03 2000 Subject: [Distutils] Re: [I18n-sig] Codecs for Big Five and GB 2312 References: <200010262342.IAA16679@dhcp198.grad.sccs.chukyo-u.ac.jp> <200010270110.KAA16842@dhcp198.grad.sccs.chukyo-u.ac.jp> <200010272140.XAA00906@loewis.home.cs.tu-berlin.de> <39FADBCC.B19B65C9@lemburg.com> <200010282026.WAA00748@loewis.home.cs.tu-berlin.de> Message-ID: <39FD35E8.17B4AF5C@lemburg.com> "Martin v. Loewis" wrote: > > > Having to import the package has two benefits: > > 1. the need for another codec package is visible in the source code > > I don't think this is a benefit for a typical application that uses > multiple codecs. More often than not, the application will learn about > a required encoding by means of an application-level protocol (e.g. a > Content-Type in a MIME header). It doesn't really *require* any > encoding; instead, it needs the codecs of any data it happens to > process in a certain session. The application designer is normally not > interested in a specific encoding; she expects Python to do the right > thing whenever .encode is invoked. But the requirement for a non-standard codec package is made visible this way and that's what I was referring to. An application which relies on availability of Japanese codecs will produce an ImportError in case these are not installed. > > 2. registering the search function is delayed until the codec > > package is first used > > That is hardly a benefit: registering the search function is not an > expensive operation, and the typical application would start with > > try: > import japanese > except ImportError: > pass > try: > import windows_codepages > except ImportError: > pass > try: > import iana > except ImportError: > pass > try: > import OSFCharmaps > except ImportError: > pass > > anyway, so all codecs it may need are registered right from the start. No. You wouldn't hide these ImportErrors if you rely on the packages being installed. If the application doesn't care for the specific encodings being installed, then the administrator could add these imports to the sitecustomize.py module after installing the codec packages. I don't think that doing this automatically is a good idea. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From R.Liebscher@gmx.de Mon Oct 30 07:47:29 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Mon Oct 30 07:47:29 2000 Subject: [Distutils] Manifest.in not included in sdist... References: Message-ID: <39FD5BE9.2E8868C4@gmx.de> Paul Moore wrote: > > This seems odd to me... > > When I build a source distribution with python setup.py sdist, my > MANIFEST.in file is not included in the resulting archive. This seems wrong, > as without the MANIFEST.in, I cannot rebuild the distribution. > Ok, this is easy to change. The attached patch adds the template file (MANIFEST.in) to MANIFEST if the template file is used and the no-defaults option was not given. file: sdist.patch Kind regards Rene Liebscher From R.Liebscher@gmx.de Mon Oct 30 08:03:12 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Mon Oct 30 08:03:12 2000 Subject: [Distutils] Manifest.in not included in sdist... References: <39FD5BE9.2E8868C4@gmx.de> Message-ID: <39FD7111.441EE8F9@gmx.de> This is a multi-part message in MIME format. --------------4BE2DB74C592F5B7F4944BEC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit It seems I forgot to attach the patch. file: sdist.patch Kind regards Rene Liebscher --------------4BE2DB74C592F5B7F4944BEC Content-Type: text/plain; charset=us-ascii; name="sdist.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sdist.patch" diff -BurN --exclude=*.pyc --minimal distutils.orig/distutils/command/sdist.py distutils.patched2/distutils/command/sdist.py --- distutils.orig/distutils/command/sdist.py Mon Oct 16 11:37:41 2000 +++ distutils.patched2/distutils/command/sdist.py Mon Oct 30 13:13:36 2000 @@ -244,6 +244,8 @@ # Read manifest template if it exists if template_exists: self.read_template() + if self.use_defaults: # don't forget MANIFEST.in + self.filelist.append(self.template) # Prune away any directories that don't belong in the source # distribution --------------4BE2DB74C592F5B7F4944BEC-- From R.Liebscher@gmx.de Mon Oct 30 08:07:01 2000 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Mon Oct 30 08:07:01 2000 Subject: [Distutils] Re: distutils?- Borland Extensions References: <39F6E2EF.C8A2CA3E@atd.ucar.edu> <001001c03ea2$13bc3760$5f42c3d1@cyberus.ca> <39F7A01E.4BF8850@ucar.edu> <000f01c03f4a$c099ab40$b542c3d1@cyberus.ca> Message-ID: <39FD7229.A2E7F94D@gmx.de> Gordon Williams wrote: > > If you want to use distutils with Borland to compile extensions to work with > the MS binary distribution you will have to have some way of using the > COFF2OMF import library conversion tool on the python20.lib file. We need > to link with the converted library and not the python20.lib which is > supplied with the distribution. (See the instructions about mypylib.lib) Distutils uses the name python20_bcpp.lib for mypylib.lib (See also the explanation at the end of this mail.) > ... > ----- Original Message ----- > From: "Joseph VanAndel" > To: "Gordon Williams" > Cc: ; > Sent: Wednesday, October 25, 2000 11:08 PM > Subject: Re: distutils? > > > re: CREATING PYTHON EXTENSIONS USING BORLAND'S FREE COMPILER > > http://www.cyberus.ca/~g_will/pyExtenDL.shtml > > > > ... > > > > Gordon: > > You've written some nice instructions on how to obtain and install the > > Borland free compiler. You provide instructions on how to customize > > batch files to compile and link extensions on Windows. > > > > Actually, 'distutils' is precisely designed to build extensions. Rather > > than .bat scripts, you describe how to build your extension in a > > 'setup.py' file. The advantage of using distutils is that it can > > compile your code on multiple platforms, with a minimum amount of > > machine dependencies in the script. And of course, distutils ships > > standard with Python 2.0. > > > > distutils now works with the Microsoft Visual C compiler. There was > > some work done on using the free Borland compiler, but I don't know if > > it was finished. > > > > Greg (and the distutils gang) - is the free Borland compiler support for > > Windows working at present? > > Distutils can be used with the free Borland compiler too. (I have tried it with PyOpenGL 1.5.5 and one of my packages, but it surely needs more testing.) What is to do? First convert all MSVC++ libraries you need from COFF to OMF. coff2omf python20.lib python20_bcpp.lib The suffix _bcpp is important if you don't want replace to original files (python20.lib,...) When you want to link against a library (python20), distutils checks if there is a library with _bcpp suffix and uses it, otherwise it tries the normal name for the library (python20.lib). The second point is, you have to specify that you want to use the Borland compiler. python setup.py install build_ext --compiler=bcpp This is all. Kind regards Rene Liebscher From pete@visionart.com Mon Oct 30 16:28:02 2000 From: pete@visionart.com (Pete Shinners) Date: Mon Oct 30 16:28:02 2000 Subject: [Distutils] adding docs/samples to bdist ?? Message-ID: <008e01c042b8$279ead20$f73f93cd@visionart.com> i have a set of python extension modules that are building and installing with distutils. it is finally working very well, and i'm very happy with the results. 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? what i was thinking would be ideal, is for my binary distributions to come exactly like the source distributions, but with the compiled files in the "build" directory included. this is mainly for windows i suppose? but then users without compilers could still do the "setup.py install", and there would be no need for compilation, since the binaries would already be in the build directories. is that a clean method for the binary releases? to me it sounds like the best plan, i suppose i could just zip up my source directory and include the "build" for my binary distributions, but i was checking if distutils already supported something similar. just trying to figure this all out, thanks From akuchlin@mems-exchange.org Tue Oct 31 14:28:05 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue Oct 31 14:28:05 2000 Subject: [Distutils] Manifest.in not included in sdist... In-Reply-To: ; from gustav@morpheus.demon.co.uk on Fri, Oct 27, 2000 at 10:02:46PM +0100 References: Message-ID: <20001031142729.D12192@kronos.cnri.reston.va.us> I never saw any reply to this, so... On Fri, Oct 27, 2000 at 10:02:46PM +0100, Paul Moore wrote: >This seems odd to me... > >When I build a source distribution with python setup.py sdist, my >MANIFEST.in file is not included in the resulting archive. This seems wrong, >as without the MANIFEST.in, I cannot rebuild the distribution. > >I would assume that building a sdist should create save everything needed to >rebuild the package, its sdist, etc etc, from scratch. 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: include ANNOUNCE include CREDITS include LICENCE include MANIFEST include MANIFEST.in include README* include TODO include setup.py ... (I believe those could all be collapsed into one line, but you get the idea.) >Another thought - a "reallyclean" command would be nice (deletes all >intermediate and generated files - essentially all of the "build" and "dist" >directories, at least... Should be easy to write... up to Greg to decide if it's worth adding. --amk From china@thewrittenword.com Tue Oct 31 23:49:01 2000 From: china@thewrittenword.com (Albert Chin-A-Young) Date: Tue Oct 31 23:49:01 2000 Subject: [Distutils] License for Distutils Message-ID: <20001031224850.A2674@postal.il.thewrittenword.com> What license is Distutils distributed under? I downloaded Distutils-1.0.1.tar.gz but there was no mention in any file of redistribution terms. -- albert chin (china@thewrittenword.com)