Mailman 3 January 2004 - Distutils-SIG

msvccompiler clobbers LIB/INCLUDE vars
by Mark Hammond 22 Jan '04

22 Jan '04

I've recently noticed that msvccompiler clobbers the LIB and INCLUDE environment variables set in the environment. What happens is that distutils looks up the registry entries for the DevStudio include and lib file settings, then *sets* the LIB and INCLUDE environment with these values, ignoring any previous values. It is quite common (for me anyway <wink>) to say something like: set LIB=%LIB%;c:\some_obscure_sdk\lib set INCLUDE=%INCLUDE%;c:\some_obscure_sdk\include make But if I try and use the same technique with distutils, these variable values are lost. It seems the *only* way I can add new paths that will work with distutils is via the DevStudio GUI, rather than these standard environment variables. Is that the intent? I understand we need to work when these variables are not set. Thanks, Mark.

3 9

Distutils-sig, J0|N N0\/\/ to see new 2004 foorblddeen lnccessst scenes
by Revisits 22 Jan '04

22 Jan '04

1 0

build_lib
by Paul Prescod 21 Jan '04

21 Jan '04

I'm having trouble in my code spelunking. Where does distutils.command.build_ext.build_ext get its build_platlib from? I'm guessing it is somewhere in distutils.command.build but there are two reasons I am confused. 1. Sometimes you invoke build_ext directly from the command line. Does a build object ever get created? 2. I can't find where the variable is passed explicitly. Maybe as part of some dictionary? Really, all I want to do is: python Setup.py build_ext --build-base=/tmp/junk But it won't work becaus build-base is defined on "build", not "build_ext". I could use the more specific "--build-lib" option but I like the way distutils lays out its directory. I just want to BOTH do a direct build_ext (rather than a higher level build) AND have control over the build-base. In the end it is going into a directory named "build" anyway, just not one in the current directory. Paul Prescod

1 0

Manifests
by Paul Prescod 21 Jan '04

21 Jan '04

I love distutils. It is a key piece of Python infrastructure. But I'm not happy with one of its design decisions. Consider the case of Joe Blow. He creates the simplest possible distribution structure: from distutils.core import setup setup( name = "pyximport", version = "1.0", url = "http://www.example.com", author = "Joe Blow", author_email = "joe(a)example.com", py_modules = ["doit"]) The distutils docs[1] say: "If you don't supply an explicit list of files (or instructions on how to generate one), the sdist command puts a minimal default set into the source distribution." The default set described is just what Joe needs. He is happy. He tries to create the distribution: bash-2.05a$ python setup.py sdist running site customization running sdist warning: sdist: manifest template 'MANIFEST.in' does not exist (using default file list) warning: sdist: standard file not found: should have one of README, README.txt writing manifest file 'MANIFEST' ... Oops. Forgot the README. So Joe adds the README. He also remembers that there is a nother module: "dothat". So he updates py_modules in setup.py. He regenerates and gets no errors. He uploads to his website. The problem is: his users WILL NOT get README or dothat.py. Distutils will not update the MANIFEST file. Joe probably didn't even notice that a MANIFEST exists and certainly won't care about it until it bites him in the ass. Even if he read the documentation closely, he would get a wrong impression: "if either MANIFEST.in or the setup script ( setup.py ) are more recent than MANIFEST , recreate MANIFEST by reading MANIFEST.in" That's not quite true because of the special case described in Distutil's source code: # The contents of the manifest file almost certainly depend on the # setup script as well as the manifest template -- so if the setup # script is newer than the manifest, we'll regenerate the manifest # from the template. (Well, not quite: if we already have a # manifest, but there's no template -- which will happen if the # developer elects to generate a manifest some other way -- then we # can't regenerate the manifest, so we don't.) I propose that if distutils is going to generate a MANIFEST then it should generate it to its temporary cruft directory, not to the source directory. If there is some reason that a user would want to hand-edit the output of this process and use it from then on as INPUT then they can copy it OUT of their distribution to the top-level directory where distutils will treat it from then on as INPUT. Their explicit copying action will indicate that they want to take control of its maintenance henceforth. I really don't know why anyone would want to hand-maintain (or use a program to generate) a MANIFEST file when they could just as easily hand-maintain or code-generate the much more flexible manifest template file. === (mostly unrelated thought:) I am not clear why distutils separates the concept of manifest template from setup.py. Couldn't you express your complete set of dependencies using globs etc. in the Python code? The whole manifest template seems like just one more file syntax to learn and one more file to maintain. Paul Prescod

4 5

Fwd[6]: Via-Grra. Allmoosstt ffrree. 0nIy T0d@y (distutils-sig@python.org).
by Brandishing 21 Jan '04

21 Jan '04

1 0

Backup your DVd's and VHS tapes with your CDR beecham
by Abe Sims 20 Jan '04

20 Jan '04

1 0

RE: [Distutils] Compiling extensions with MingW32 / python.org binary
by Moore, Paul 14 Jan '04

14 Jan '04

From: Michael Droettboom > I've come across a possible bug with --compiler=mingw32 and > --compiler=cygwin support when using the standard python.org 2.3.3 > .exe. (I do this so I can distribute binary installers that work with > the standard Python distribution, but don't want to buy MS Visual Studio...) I don't have a C extension handy to try at the moment, but I haven't had a problem in the past using mingw (--compiler=mingw32) and python.org python 2.3.3. Can you clarify what you are having problems with? Using python.org python with cygwin gcc (--compiler=cygwin)? If so, I have no experience with that, so I can't help (beyond saying that mingw works fine, so don't break that in the process of fixing the cygwin case!) Paul.

4 7

RE: [Distutils] Compiling extensions with MingW32 / python.org binary
by Moore, Paul 14 Jan '04

14 Jan '04

From: Michael Droettboom [mailto:mdboom@jhu.edu] > I'm having problems with both --compiler=cygwin and --compiler=mingw32. What version of mingw do you have installed, and are you sure it's getting used in preference to the cygwin one (ie, is it in your PATH before the cygwin directory)? I'll check when I get home. (Where I have something I can compile :-)) Paul

1 0

Compiling extensions with MingW32 / python.org binary
by Michael Droettboom 14 Jan '04

14 Jan '04

I've come across a possible bug with --compiler=mingw32 and --compiler=cygwin support when using the standard python.org 2.3.3 .exe. (I do this so I can distribute binary installers that work with the standard Python distribution, but don't want to buy MS Visual Studio...) It seems that the linker command being used is cc.exe, which on Cygwin 1.5.5-1 is actually a symlink to gcc.exe. This works fine if your Python interpreter was compiled with Cygwin, because it handles the symlink correctly. However, when using the python.org interpreter, you get a: command 'cc' failed: Invalid argument error. Making cc.exe a real copy of gcc.exe fixes the problem. Looking in cygwinccompiler.py, it seems that the linker is getting set to 'gcc', so it must be getting changed to 'cc' at somewhere else in the heirarchy... Any ideas? I'd be happy to submit a patch if this is in fact a new bug. Note also, that things worked correctly in Python 2.2.3. It is only when I moved to Python 2.3 that this error occurred. Michael Droettboom

1 0

Linking C++ under Linux
by Bill Spotz 12 Jan '04

12 Jan '04

I am developing a set of extension modules for python written in C++ and have successfully written a setup.py that works on my mac. Portability is important, though, and under Linux, the linking command I get from distutils appears to be not what I want. Specifically, on the mac, the compile command from distutils is gcc with the appropriate command line options and the link command is c++. On the Linux machine, gcc is both the compile and linking command, and when the module is loaded, I get ImportError: ../build/lib.linux-i686-2.2/PyTrilinos/_Epetra.so: undefined symbol: endl__FR7ostream which sure looks like a missing c++ library to me. In my searching through distutils documentation, all I can find is a warning to "Be sure to use appropriate extensions to distinguish C++ source files: .cc and .cpp seem to be recognized by both Unix and Windows compilers." But changing my suffix from .cxx to .cpp didn't help. (I was using .cxx because that is the default suffix produced by SWIG -- but I'm currently calling swig via a Makefile because distutils doesn't appear to be robust enough yet to handle everything I need it to do.) System info: sahp4960(41)$ uname -a Linux sahp4960 2.4.18-17.7.xsmp #1 SMP Tue Oct 8 12:37:04 EDT 2002 i686 unknown Python info: sahp4960(42)$ python Python 2.2.1 (#1, May 14 2002, 16:46:34) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 [It just occurred to me that this could be a python version issue, as my working mac version is under python 2.3. I'll be looking into this, but would still appreciate a response.] Thanks ** Bill Spotz ** ** Sandia National Laboratories Voice: (505)845-0170 ** ** P.O. Box 5800 Fax: (505)284-5451 ** ** Albuquerque, NM 87185-0316 Email: wfspotz(a)sandia.gov **

2 4