Mailman 3 May 2000 - Distutils-SIG

Small bug in distutils 2000-05-11 snapshot
by Thomas Heller 20 May '00

20 May '00

It seems the line 'from distutils import sysconfig' is missing on top of file dist.py in the recent distutils snapshot 2000-05-11. Thomas Heller

2 1

Function stubs for CCompiler class?
by Lyle Johnson 20 May '00

20 May '00

It appears that in addition to the "worker" functions like compile(), link_shared_object(), etc. there are four functions which *must* be implemented by subclasses of CCompiler: library_dir_option() runtime_library_dir_option() library_option() find_library_file() I submit the following patch (against the current CVS version of ccompiler.py) to make future compiler implementors aware of this requirement. Lyle Index: distutils/ccompiler.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/ccompiler.py,v retrieving revision 1.17 diff -a -u -r1.17 ccompiler.py --- ccompiler.py 2000/03/26 21:37:09 1.17 +++ ccompiler.py 2000/05/11 20:59:16 @@ -566,7 +566,38 @@ pass + # -- Miscellaneous methods ----------------------------------------- + # These are all used by the 'gen_lib_options() function; there is + # no appropriate default implementation so subclasses should + # implement all of these. + + + def library_dir_option (self, dir): + """Return the compiler option to add 'dir' to the list of directories + searched for libraries.""" + raise NotImplementedError + + + def runtime_library_dir_option (self, dir): + """Return the compiler option to add 'dir' to the list of directories + searched for runtime libraries.""" + raise NotImplementedError + + + def library_option (self, lib): + """Return the compiler option to add 'dir' to the list of libraries + linked into the shared library or executable.""" + raise NotImplementedError + + + def find_library_file (self, dirs, lib): + """Search the specified list of directories for a static or shared + library file 'lib' and return the full path to that file. Return + None if it wasn't found in any of the specified directories.""" + raise NotImplementedError + + # -- Filename generation methods ----------------------------------- # The default implementation of the filename generating methods are

2 1

Patch to MSVCCompiler: 'export_symbols'
by Greg Ward 20 May '00

20 May '00

OK, all your Windows experts: tell me if I got this right. Here's a patch to msvccompiler.py to add support for the 'export_symbol' keyword argument to 'link_shared_lib()' and 'link_shared_object()'. Right now it turns a list of ['foo', 'bar', 'baz'] into additional arguments to the linker: /EXPORT:foo /EXPORT:bar /EXPORT:baz Is this the correct and/or optimal way to do it? Here's the patch... diff -c -r1.27 msvccompiler.py *** msvccompiler.py 2000/04/19 02:16:49 1.27 --- msvccompiler.py 2000/05/20 12:59:04 *************** *** 304,309 **** --- 304,310 ---- libraries=None, library_dirs=None, runtime_library_dirs=None, + export_symbols=None, debug=0, extra_preargs=None, extra_postargs=None): *************** *** 313,318 **** --- 314,321 ---- output_dir=output_dir, libraries=libraries, library_dirs=library_dirs, + runtime_library_dirs=runtime_library_dirs, + export_symbols=export_symbols, debug=debug, extra_preargs=extra_preargs, extra_postargs=extra_postargs) *************** *** 325,330 **** --- 328,334 ---- libraries=None, library_dirs=None, runtime_library_dirs=None, + export_symbols=None, debug=0, extra_preargs=None, extra_postargs=None): *************** *** 350,357 **** else: ldflags = self.ldflags_shared ! ld_args = ldflags + lib_opts + \ ! objects + ['/OUT:' + output_filename] if extra_preargs: ld_args[:0] = extra_preargs --- 354,365 ---- else: ldflags = self.ldflags_shared ! export_opts = [] ! for sym in (export_symbols or []): ! export_opts.append("/EXPORT:" + sym) ! ! ld_args = (ldflags + lib_opts + export_opts + ! objects + ['/OUT:' + output_filename]) if extra_preargs: ld_args[:0] = extra_preargs -- Greg Ward - Unix bigot gward(a)python.net http://starship.python.net/~gward/ Disclaimer: All rights reserved. Void where prohibited. Limit 1 per customer.

1 0

install_scripts and install_data commands
by Bastian Kleineidam 15 May '00

15 May '00

Hi, I wrote a patch for the above commands. Both commands derive from install_misc, which copies some files to a given directory and is defined in cmd.py. With the attached patch you can now have "scripts=[...]" and "data=[...]" attributes in setup.py. By the way: I was not able to TeX the documentation because I found no howto.cls file (the files are using \documentclass{howto}). There should be a make file to compile all the various .tex files. Bastian -- Bastian Kleineidam -- Just do it. Use Linux. .~. http://fsinfo.cs.uni-sb.de/~calvin/official/ /V\ // \\ /( )\ ^`~'^

3 6

RE: [Distutils] Patches for --compiler option
by Lyle Johnson 12 May '00

12 May '00

> Thanks -- I'll check it in shortly. One problem: > > > extra_args.append ('/IMPLIB:' + implib_dir) > > + self.mkpath (os.path.dirname(implib_dir)) > > # if MSVC > > I fixed this bug just before seeing your patch with > > self.mkpath(implib_dir) > > One of us misunderstands what 'implib_dir' is, and since you're the one > using Windows, it could well be me. Can you test to see which fix is > the right one? The /IMPLIB:name switch to the linker is used to specify the name of an import library. The variable name "implib_dir" should probably be changed to "implib_file" because it is the file name of the import library and not a directory name. Having said that, the correct code snippet is: implib_file = os.path.join (self.build_temp, \ self.get_ext_libname (extension_name)) extra_args.append ('/IMPLIB:' + implib_file) self.mkpath (os.path.dirname (implib_file)) I just tested this on two of my projects plus PyXML-0.5.4 and it works properly. Lyle

2 1

RE: [Distutils] install_scripts and install_data commands
by Michael Muller 12 May '00

12 May '00

Tony J Ibbs (Tibs) wrote: > I'm only following this with half a mind at best (sorry), but Bastian had an > email that contained: > > > >But I don't think we should rely on everyone using the > > >"#!/usr/bin/env" hack, either: the first python on the path isn't > > >necessarily the right one. > > The "first python on the path" is the correct thing for the user, > > otherwise the path is wrong. So "/usr/bin/env pyton" yields the correct > > interpreter to execute. > > Do please remember the problem on Dec Unixes (which appears to be) that if > the environment is large (i.e., many environment variables) then > /usr/bin/env falls back to *printing* the environment variables, instead of > executing the given program (gods know why, but this is Dec). [snip] That's not the only problem, apparently different systems are undecided as to whether "env" belongs in "/usr/bin" or in "/bin". Also, considering that other operating systems have their own ways of implementing the spirit of the "#!" hack (and they're usually pretty bad at it), I think the final script really needs to be generated during installation. See this URL for the complete discussion on #!/bin/env: http://x29.deja.com/dnquery.xp?search=next&DBS=1&IS=%22/bin/env%20python%22… ============================================================================= michaelMuller = mmuller(a)enduden.com | http://www.cloud9.net/~proteus ----------------------------------------------------------------------------- The natural progress of things is for liberty to yield and government to gain control. - Thomas Jefferson =============================================================================

1 0

Suggested additions to function argument list
by Lyle Johnson 12 May '00

12 May '00

All, In trying to implement the compiler class for Borland's C++ compiler I've run up against a minor snag or two. First, some background. For extension modules on Windows, we want to support the specification of an optional module definition file (a.k.a. a .DEF file). On Unix I believe it's true that all of the symbols in a shared library are "exported" so this is a non-issue. On Windows, however, you must specify in one way or another which symbols in a DLL are to be exported. One way to do this is to provide the exported symbols' names in a .DEF file which you must write (it's a specially-formatted ASCII text file). Another way to do this is list each of the exported symbols' names on the linker command line using a linker-specific switch. Currently, a module developer can tell the Distutils which DEF file to use for each extension module with the "def_file" key, e.g.: setup (..., ext_modules = [ ('module1', { 'sources' : ['module1.c'], 'def_file' : ['module1.def'] } ), ('module2', { 'sources' : ['module2.c'], 'def_file' : ['module2.def'] } ), ] ) If the "def_file" information for an extension module is not explicitly specified, there is code in the build_ext command which guesses a likely name for the .DEF file (basically module_name + ".def") and sees if that file exists. If so, it uses that file. Otherwise, we adopt a reasonable fallback position and guess the initialization function's name to be "init" + module_name and ask the linker to export that symbol for us. OK, we have now arrived at the problem part ;) The way to specify either the .DEF file name or the exported symbol name(s) is linker-specific. For Microsoft's linker they are passed along as straightforward arguments, either: /DEF:module1.def or /EXPORTS:initmodule1 but for Borland's linker this information comes in very differently -- not as simple arguments which you can just append to the linker's argument list. Since only the compiler class knows for sure how to specify the .DEF file name (or alternatively the exported symbols list) it seems that we should pass this information directly to the compiler through the link_shared_object() function's argument list, instead of cooking up those arguments in the build_ext command. I'd propose adding an additional argument to the function's signature (its default could be None and could be ignored by non-Windows compilers). Changing the subject, it might also be appropriate to pass down the temporary files directory for the current extension's build, unless this kind of code: build_ext = self.find_peer ('build_ext') build_temp = build_ext.build_temp is considered safe. If this doesn't violate encapsulation (for the compiler object to know that the build_ext object has an attribute named "build_temp") then I'll just do this and sleep soundly ;) Sorry for the rambling e-mail! Lyle

2 8

New snapshot available
by Greg Ward 11 May '00

11 May '00

Hi all -- I've just released a new code snapshot, available at http://www.python.org/sigs/distutils-sig/download.html#snapshot The major change is the addition of Bastian Kleineidam's "install_scripts" and "install_data" commands. I'll let you figure out what type of files these two install. ;-) I also fixed a little bug in the "install" command that appeared when testing Bastian's two commands. Also, there an initial stab at finding and parsing config files has been added. It doesn't have any actual effect yet, though. Oh yeah, Lyle Johnson's --compiler switch went in tonight too. Thanks to Bastian and Lyle for the patches! (And also to Harry Gebel, whose bdist_rpm did *not* make it in tonight ... that was the original plan, but I got distracted by Bastian's stuff. Ahh well, one patch at a time...) Greg PS. there's some CVS reshuffling going on at python.org, the upshot of which is that these changes are *not* available by CVS (unless you happen to have a login on my home PC, which you do not unless you are me). I'm afraid everyone will have to use code snapshots for the next couple of days. ;-( -- Greg Ward - Linux nerd gward(a)python.net http://starship.python.net/~gward/ Be wary of strong drink. It can make you shoot at tax collectors--and miss.

1 0

Re: using distutils for compiling PyXML0.5.4
by Greg Ward 11 May '00

11 May '00

On 11 May 2000, F. Oliver Gathmann said: > I was trying to get the new PyXML (v. 0.5.4) compiled with distutils v. > 0.8.1, and besides some tweaking of pyexpat.c I had to make sure the > directory path for the > temporary import library was generated, as shown in the attached patch > to build_ext.py (BTW, this was on a Win98 machine). Hmmm, I thought someone else had reported this, and I thought it had been fixed. Can you try Distutils 0.8.2 and see if if it works any better?

1 0

Patches for --compiler option
by Lyle Johnson 11 May '00

11 May '00

All, Listed below are patches for the build, build_clib and build_ext commands to support a new option "--compiler=compiler_type". This is a prerequisite for supporting compiler types other than the default (and specifically, supporting Borland's compiler on Windows). These patches are against the latest CVS version of the distutils. Lyle Index: distutils/command/build.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/command/build.py,v retrieving revision 1.17 diff -a -u -r1.17 build.py --- build.py 2000/04/10 01:31:58 1.17 +++ build.py 2000/05/11 20:43:38 @@ -26,10 +26,12 @@ "build-purelib or build-platlib"), ('build-temp=', 't', "temporary build directory"), + ('compiler=', 'c', + "specify the compiler type"), ('debug', 'g', "compile extensions and libraries with debugging information"), ('force', 'f', - "forcibly build everything (ignore file timestamps"), + "forcibly build everything (ignore file timestamps)"), ] def initialize_options (self): @@ -40,6 +42,7 @@ self.build_platlib = None self.build_lib = None self.build_temp = None + self.compiler = None self.debug = None self.force = 0 Index: distutils/command/build_clib.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/command/build_clib.py,v retrieving revision 1.13 diff -a -u -r1.13 build_clib.py --- build_clib.py 2000/04/15 22:15:07 1.13 +++ build_clib.py 2000/05/11 20:43:39 @@ -38,7 +38,9 @@ ('debug', 'g', "compile with debugging information"), ('force', 'f', - "forcibly build everything (ignore file timestamps"), + "forcibly build everything (ignore file timestamps)"), + ('compiler=', 'c', + "specify the compiler type"), ] def initialize_options (self): @@ -54,6 +56,7 @@ self.undef = None self.debug = None self.force = 0 + self.compiler = None # initialize_options() @@ -68,6 +71,7 @@ self.set_undefined_options ('build', ('build_temp', 'build_clib'), ('build_temp', 'build_temp'), + ('compiler', 'compiler'), ('debug', 'debug'), ('force', 'force')) @@ -93,9 +97,11 @@ return # Yech -- this is cut 'n pasted from build_ext.py! - self.compiler = new_compiler (verbose=self.verbose, + self.compiler = new_compiler (compiler=self.compiler, + verbose=self.verbose, dry_run=self.dry_run, force=self.force) + if self.include_dirs is not None: self.compiler.set_include_dirs (self.include_dirs) if self.define is not None: Index: distutils/command/build_ext.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/command/build_ext.py,v retrieving revision 1.34 diff -a -u -r1.34 build_ext.py --- build_ext.py 2000/05/09 01:50:41 1.34 +++ build_ext.py 2000/05/11 20:43:39 @@ -67,7 +67,9 @@ ('debug', 'g', "compile/link with debugging information"), ('force', 'f', - "forcibly build everything (ignore file timestamps"), + "forcibly build everything (ignore file timestamps)"), + ('compiler=', 'c', + "specify the compiler type"), ] @@ -87,6 +89,7 @@ self.link_objects = None self.debug = None self.force = None + self.compiler = None def finalize_options (self): @@ -95,6 +98,7 @@ self.set_undefined_options ('build', ('build_lib', 'build_lib'), ('build_temp', 'build_temp'), + ('compiler', 'compiler'), ('debug', 'debug'), ('force', 'force')) @@ -169,7 +173,8 @@ # Setup the CCompiler object that we'll use to do all the # compiling and linking - self.compiler = new_compiler (verbose=self.verbose, + self.compiler = new_compiler (compiler=self.compiler, + verbose=self.verbose, dry_run=self.dry_run, force=self.force) @@ -340,6 +345,7 @@ implib_dir = os.path.join(self.build_temp,\ self.get_ext_libname(extension_name)) extra_args.append ('/IMPLIB:' + implib_dir) + self.mkpath (os.path.dirname(implib_dir)) # if MSVC fullname = self.get_ext_fullname (extension_name)

1 0