Mailman 3 May 2001 - Distutils-SIG

Building external libs with distutils
by M.-A. Lemburg May 17, 2001

May 17, 2001

I was just wondering whether anybody has already tackled the job of using distutils to build external libs. I am thinking of the following setup here: * you have a source tree in ./libsrc * building the lib is done in the usual Unix way: cd ./libsrc; ./configure; make * now copy te resulting .a or .so to your Python package target build dir * continue with the normal distutils procedure to build the Python wrapper Is this possible in a fairly portable way (at least with respect to Unix platforms) ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

2 2

Installing non-program files into the lib directory
by Konrad Hinsen May 16, 2001

May 16, 2001

I have a package which includes some non-program files (in fact scripts, but which are run by exec_file) that have to be installed in a specific subpackage folder. Is there any simple way to do this with distutils, i.e. one which doesn't require me to reimplement several methods? Library installation ignores everything which is not .py, whereas data file installation doesn't let me access the lib directory. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen(a)cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------

2 2

No support for .pyo files
by Greg Kochanski May 14, 2001

May 14, 2001

Python has a -O flag that turns on some compiler optimizations. Python then looks for (and produces) .pyo files instead of .pyc files. Distutils doesn't seem to provide any support for this. What can be done?

3 2

Distributing modules with dependencies
by scleary＠jerviswebb.com May 9, 2001

May 9, 2001

I see that between PEP241 and 243, Py is moving towards a central module repository. My question is: has any thought been given to the idea of having one application/library be dependent on another library, and for the download/install to be done as part of setup.py? For example, I'm writing a simple application that uses wxPython -- which not everyone has installed. During installation, I can right now in setup.py abort if wxPython isn't found -- but it would be much nicer to users (IMO) if it can download & install wxPython silently. This is more complicated than just that; I'd like to see: . The ability for users (special command-line option?) to download all dependent packages to a local directory first. . The ability for distutils to substitute newer versions in place of older -- this is a lot more tricky, since we *don't* want it to do that for non-backwards-compatible differences. I'd like to see the basic functionality anyway, even if the two features above aren't done until later. The reason being that my intended user base are not programmers or even serious computer users at all. In fact, if there was any way to package Python itself with my app, I'd like to know about it (is there?). I just don't want to see us in the future run into what Linux did a little while ago -- oh, your update for package x requires an update to package y, so after you download and install the update to package y, you find it requires an update to package z, ... -Steve

1 0

Building Cygwin-Python extension modules - export strategies
by Mark Hadfield May 1, 2001

May 1, 2001

I have posted the following on comp.lang.python. At Jason Tishler's suggestion I am now also sending it to this SIG. In keeping with the dignity of this forum I have cut some of the excessively flippant bits.... On Friday I posted a message to comp.lang.idl-pvwave entitled "Building Numeric package on Cygwin-Python". I reported that the Numpy module library could not be built with Cygwin Python 2.1 using the distutils-based setup script. With the help of people who responded to this message, and to another one on the Cygwin mailing list, I can now build Numpy. But to get it to work out-of-the-box requires changes either to the C code or to distutils (see below). I would like to trigger a discussion on this list and ultimately a ruling from the Python gods about the one-true-Pythonic-way to write and install Python extension modules for the Cygwin version of Python. To recap, I have the Numpy source distribution, Numeric-20.0.0b2.tar.gz (but I think these considerations apply to any Python module library that uses C code) and I have Python 2.1 installed by Cygwin's setup program (but the results should be the same if I had built it myself using the Cygwin gcc compiler). I unpack the source and cd to the directory created. According to the "Installing Python Modules" manual, I should be able to build & install this by typing python setup.py build python setup.py install However the build step fails at the first link command, with messages about undefined symbols. The problem is (and I'm a bit hazy here) that to build a DLL on the Windows platform, the compiler needs a list of symbols to be exported. The above command invokes a Unix-like build process that doesn't know about this. There are two solutions: 1. (Thanks to Robert Yodlowski): In each C file foomodule.c, replace void initfoo () with DL_EXPORT(void) initfoo () where DL_EXPORT is a preprocessor macro. 2. (Thanks to Norman Vine): Invoke the setup script's "cygwin" compiler option: python setup.py build compiler=cygwin python setup.py install after first applying a patch (after sig) that modifies a couple of distutils files. The compiler then creates and uses the necessary .def files to specify the exports. (Note that the Numeric source does include several .def files but these are ignored.) This is all fine, and it's not that much of a hardship to make one or other of these changes. But obviously it would be good if Cygwin Python users could build extension modules out-of-the-box, so I would like to see one of these changes (or something like them) incorporated into Python and its documentation. So which one? Jason Tishler and Norman Vine have told me that these things have been discussed before on python-dev and distutils-sig but never carried through to a resolution Option 1 does have the blessing of Tim Peters http://mail.python.org/pipermail/python-dev/2001-February/013292.html The downside is that it requires changes (albeit minor) to the C code of the Numeric package and, I presume, most other Python extension packages. Not to mention modifications to the "Extending and Embedding" manual. Option 2 was raised by Jason Tishler on distutils-sig http://mail.python.org/pipermail/distutils-sig/2001-February/002003.html but there wasn't any enthusiasm for it so he dropped it (to paraphrase Jason's words). If this is to be applied I would prefer that it not be necessary to specify the "cygwin" compiler option explicitly. (According to the "Installing Python Modules" manual this should only be necessary when using Cygwin to build extensions for native win32 Python.) Yes, I know I can achieve this myself via the distutils configuration file. On the newsgroup Jason has pointed out that Option 1 works with the traditional Misc/Makefile.pre.in, whereas Option 2 does not. Opinions? --- Mark Hadfield m.hadfield(a)niwa.cri.nz http://katipo.niwa.cri.nz/~hadfield National Institute for Water and Atmospheric Research ? cygwinccompiler.py.patch ? diffs ? my.diffs cvs server: Diffing . Index: cygwinccompiler.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/cygwinccompiler.py,v retrieving revision 1.12 diff -r1.12 cygwinccompiler.py 99,103c99,103 < self.set_executables(compiler='gcc -mcygwin -O -Wall', < compiler_so='gcc -mcygwin -mdll -O -Wall', < linker_exe='gcc -mcygwin', < linker_so=('%s -mcygwin -mdll -static' % < self.linker_dll)) --- > # self.set_executables(compiler='gcc -mcygwin -O -Wall', > # compiler_so='gcc -mcygwin -mdll -O -Wall', > # linker_exe='gcc -mcygwin', > # linker_so=('%s -mcygwin -mdll -static' % > # self.linker_dll)) Index: sysconfig.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/sysconfig.py,v retrieving revision 1.34 diff -r1.34 sysconfig.py 120c120,121 < if compiler.compiler_type == "unix": --- > # if compiler.compiler_type == "unix": > if compiler.compiler_type in ["unix", "cygwin"]: cvs server: Diffing command

1 0