Mailman 3 September 2000 - Distutils-SIG

borland compiler
by Pete Shinners 30 Sep '00

30 Sep '00

i'm trying to get borland's free commandline compiler working with a sample module i'm testing with. everything goes fine in the compile, but the linker is giving me the following error: Error: 'D:\PYTHON\LIBS\PYTHON20.LIB' contains invalid OMF record, type 0x21 (possibly COFF) ok, sounds like the python20.lib is incompatible with borland's compiler (??). if so, that seems like a big pain. does anyone have the steps needed to get this compiler working? i've not found any help from the docs or source yet. i'm guessing i'll need to recompile python with borland? (i didn't think that was an option?) perhaps i'm better off going with cygnus or mingw? what is the most common free win32 compiler for use with distutils?

3 4

Bug report: debug builds on msvc compiler don't specify *_d.lib a s link sources
by Mike Fletcher 29 Sep '00

29 Sep '00

In ccompiler, you have this code in gen_lib_options: for lib in libraries: (lib_dir, lib_name) = os.path.split (lib) if lib_dir: lib_file = compiler.find_library_file ([lib_dir], lib_name) if lib_file: lib_opts.append (lib_file) else: compiler.warn ("no library file corresponding to " "'%s' found (skipping)" % lib) else: lib_opts.append (compiler.library_option (lib)) Note that you aren't passing "debug" to compiler.find_library_file, so the debug libraries will never get used. Also note that msvccompiler doesn't provide for passing the debug flag to library_option, so it doesn't do the proper name mangling (adding _d) for the library name. I'm guessing you'll need to make gen_lib_options get passed the debug flag, and then make it pass that flag on to the compiler methods. No clue what to do for non-vc++ compilers (or even if they need debug flags). Enjoy, Mike

3 4

Fw: [Python-checkins] CVS: distutils/distutils/command build_ext.py,1.66,1.67
by Thomas Heller 28 Sep '00

28 Sep '00

> Update of /cvsroot/python/distutils/distutils/command > In directory slayer.i.sourceforge.net:/tmp/cvs-serv31686 > > Modified Files: > build_ext.py > Log Message: > Removed the implib_dir instance variable because it is unused. > > Removed get_ext_libname() because it is unused. > > Fixed get_libraries() to append an '_d' to the python debug > import library. If MSVC is used, do not add 'pythonxx.lib' to > the list of libraries, because this is handled better > by a pragma in config.h. > > This should fix bug #115595, but it needs some more testing. > > > Index: build_ext.py > =================================================================== > RCS file: /cvsroot/python/distutils/distutils/command/build_ext.py,v > retrieving revision 1.66 > retrieving revision 1.67 > diff -C2 -r1.66 -r1.67 > *** build_ext.py 2000/09/25 01:41:15 1.66 > --- build_ext.py 2000/09/28 19:28:35 1.67 > *************** > *** 159,163 **** > if os.name == 'nt': > self.library_dirs.append (os.path.join(sys.exec_prefix, 'libs')) > - self.implib_dir = self.build_temp > if self.debug: > self.build_temp = os.path.join (self.build_temp, "Debug") > --- 159,162 ---- > *************** > *** 544,556 **** > return apply (os.path.join, ext_path) + so_ext > > - def get_ext_libname (self, ext_name): > - # create a filename for the (unneeded) lib-file. > - # extensions in debug_mode are named 'module_d.pyd' under windows > - ext_path = string.split (ext_name, '.') > - if os.name == 'nt' and self.debug: > - return apply (os.path.join, ext_path) + '_d.lib' > - return apply (os.path.join, ext_path) + '.lib' > - > - > def get_export_symbols (self, ext): > """Return the list of symbols that a shared extension has to > --- 543,546 ---- > *************** > *** 574,580 **** > # config.h that MSVC groks. The other Windows compilers all seem > # to need it mentioned explicitly, though, so that's what we do. > ! if sys.platform == "win32": > ! pythonlib = ("python%d%d" % > ! (sys.hexversion >> 24, (sys.hexversion >> 16) & 0xff)) > # don't extend ext.libraries, it may be shared with other > # extensions, it is a reference to the original list > --- 564,576 ---- > # config.h that MSVC groks. The other Windows compilers all seem > # to need it mentioned explicitly, though, so that's what we do. > ! # Append '_d' to the python import library on debug builds. > ! from distutils.msvccompiler import MSVCCompiler > ! if sys.platform == "win32" and \ > ! not isinstance(self.compiler, MSVCCompiler): > ! template = "python%d%d" > ! if self.debug: > ! template = template + '_d' > ! pythonlib = (template % > ! (sys.hexversion >> 24, (sys.hexversion >> 16) & 0xff)) > # don't extend ext.libraries, it may be shared with other > # extensions, it is a reference to the original list > > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://www.python.org/mailman/listinfo/python-checkins

1 0

Re: [XML-SIG] [Bug #115544] Compile Problems on Mac OS X
by Martin v. Loewis 28 Sep '00

28 Sep '00

> Details: I have successfully compiled and installed Python 2.0b2 on > my Mac OS X system, but I am having trouble building the current > Python/XML CVS version. During the linking stage, I get a warning > and an error: I assume that your Python build does not include the pyexpat module, right? If it did, PyXML should not attempt to build it itself. Since building is controlled by distutils, I've cc'ed this to the distutils-sig. Since likely fixes will also need to appear in Python 2.0, it would be good if we resolve this within the next week. > cc -bundle -prebind build/temp.darwin-1.2-Power Macintosh-2.0/extensions/pyexpat.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmltok/xmltok.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmltok/xmlrole.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlwf/xmlfile.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlwf/xmlwf.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlwf/codepage.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlparse/xmlparse.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlparse/hashtable.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlwf/unixfilemap.o -o build/lib.darwin-1.2-Power Macintosh-2.0/_xmlplus/parsers/pyexpat.so I guess I need some help in resolving this, as I have no MacOS X myself. Can you spot anything that is incorrect in this command line? > /usr/bin/ld: warning -prebind has no effect with -bundle What is the intended effect of -prebind and -bundle? Where do these options come from, anyway? Grepping the distutils sources, I see no mentioning of them, so what magic finds those options? > /usr/bin/ld: Undefined symbols: > _PyArg_ParseTuple > _PyArg_ParseTupleAndKeywords > ...*removed a few dozen more symbols*... It's certainly the case that these symbols are undefined - we are building an extension module, after all. On MacOS X, the compiler is gcc, right? Normally, you'll have to pass -shared to the compiler to have it build shared libraries. I notice that Python's configure.in has two alternatives for building extension modules on next/*: If dyld is used, then the options are "-bundle -prebind", otherwise they are "-nostdlib -r". Do you use WITH_DYLD? Can you try linking the module with "-nostdlib -r"? Thanks, Martin > For detailed info, follow this link: > http://sourceforge.net/bugs/?func=detailbug&bug_id=115544&group_id=6473

1 0

My (slightly goofy) coding standard
by Greg Ward 27 Sep '00

27 Sep '00

Hi all -- I have just completed one pass over the Distutils source to enforce one minor coding convention: whitespace next to the open parentheses when calling a function (or other callable). Anyone hacking on the Distutils needs to know about this convention, which is slightly odd but quite defensible (IMHO): * when *defining* a callable, use a space: def foo (): ... def foo (arg1, arg2, ...): ... class SubThing (Thing): ... * corollary: for long functions that need a "# end"-style line, it looks like this: def foo (): # > 40 lines of code (say) # foo () because the "# foo ()" line is part of the definition * when *using* a callable, no space: foo() thing.foo() foo(2, "hello") this.that.get_something().foo.name_of_long_method( arg1, arg2, arg3, ...) Rationale: this makes it trivial (grep-wise) to distinguish between *definition* and *use*. I *know* what Guido's coding standard says, but the problem with "def foo()" is that you can't search for use only without a negative lookbehind to exclude "def" lines... and my "grep" doesn't have negative lookbehind. Anyways, that's the Distutils convention as of tonight. Please respect it when hacking on the code! (And please fix deviance if you submit patches: I've only fixed up distutils/*.py, excluding *ccompiler.py because of a pending patch. distutils/command/*.py is still to go; I can only do so much brain-dead search 'n replace work at once.) Greg -- Greg Ward gward(a)python.net http://starship.python.net/~gward/

2 2

ANNOUNCE: Distutils 0.9.3
by Greg Ward 27 Sep '00

27 Sep '00

Python Distribution Utilities release 0.9.3 September 26, 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 and (ultimately) applications. The Distutils are a standard part of Python 2.0; if you are running 2.0 (or one of the 1.6 alpha releases that preceded it), you don't need to install the Distutils separately. 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. Version 0.9.3 is identical to the Distutils code included with Python 2.0b2. 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(a)python.net. Larger patches should be discussed on the Distutils mailing list: distutils-sig(a)python.org. Greg -- Greg Ward gward(a)python.net http://starship.python.net/~gward/

1 0

New code snapshot
by Greg Ward 26 Sep '00

26 Sep '00

Hi all -- I've just checked in Rene's rather hefty patch to collapse a bunch of mostly-redundant 'link_*()' methods in the various CCompiler classes into one 'link()'. This is big enough to warrant a whole new code snapshot, so I put one out: two-and-a-half releases in one day, a personal record! ;-) It works for me building a few things on my Linux box; please try it out on other platforms (especially with a variety of compilers on Windows) and let me know how it goes. Thanks. Oh yeah: http://www.python.org/sigs/distutils-sig/download.html#snapshot Greg -- Greg Ward gward(a)python.net http://starship.python.net/~gward/

1 0

Synchronizing version information
by Martin von Loewis 26 Sep '00

26 Sep '00

In my package, I have two places which carry version information: in the setup.py, when passing the version= keyword argument to setup, and in the package's __init__, to allow runtime access to the available version. I'd like these to be synchronized, having the information only in a single place, and fetching it from there in the other. Is there any mechanism in distutils to facilitate such synchronization? One approach would be a autoconf-style replacement mechanism, where I put version_info = distutils.version.StrictVersion(@VERSION@) into the Python source, and version = version_string, substitute = {'VERSION': repr(version_string)} into setup.py. 'build', 'sdist', etc would update the string appropriately. Any comments? TIA, Martin

4 5

Changes to config file handling
by Greg Ward 26 Sep '00

26 Sep '00

Hi all -- I think I've fixed all the problems Marc-André pointed out with config files last week, specifically: * options in config files can now be spelled either "foo-bar" (like on the command line, minus the leading "--") or "foo_bar" (like in the code) * negative alias options are now respected, eg. "quiet=1" is the same as "verbose=0" Plus I fixed a bug nobody had reported: * boolean options now work: previously, "force=0" resulted in an attribute 'force' being set to the string "0", which of course is true. As an extra bonus, you can now use a variety of sensible representations of true and false: yes, y, t, true, 1, on for true, and no, n, f, false, 0, off for false. And added a feature that was supposed to be in there from the beginning, but I just plain forgot about: * a "[global]" section where you can set global options; currently, only 'verbose' and 'dry-run' are supported here (and of course 'quiet', since it's the opposite of 'verbose') As soon as I've checked everything in, I'll put out a new code snapshot. Please give it a try and let me know if config files now work as you'd expect them to work. Greg -- Greg Ward gward(a)python.net http://starship.python.net/~gward/

2 2

ANNOUNCE: Distutils 0.9.3
by Greg Ward 26 Sep '00

26 Sep '00

Python Distribution Utilities release 0.9.3 September 26, 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 and (ultimately) applications. The Distutils are a standard part of Python 2.0; if you are running 2.0 (or one of the 1.6 alpha releases that preceded it), you don't need to install the Distutils separately. 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. Version 0.9.3 is identical to the Distutils code included with Python 2.0b2. 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(a)python.net. Larger patches should be discussed on the Distutils mailing list: distutils-sig(a)python.org. Greg -- Greg Ward gward(a)python.net http://starship.python.net/~gward/

1 0