From gward@python.net  Wed Mar  1 02:41:22 2000
From: gward@python.net (Greg Ward)
Date: Tue, 29 Feb 2000 21:41:22 -0500
Subject: [Distutils] Upheaval in build and install commands
Message-ID: <20000229214122.A2387@beelzebub>

Hi all --

anyone keeping up with the Distutils CVS archive may have noticed these
changes, but I thought I should mention them just so everyone's up to
speed.

First, the "install" command is in a state of disrepair.  The
most-recent checkin was an incomplete, unfinished, aborted idea -- only
checked it in for posterity.  Don't even bother trying to use it.

Second, the "build" commands have been undergoing some upheaval.  The
reasons are:

  * put compiler turds (object files, in particular, but also the stuff
    that MSVC leaves behind on linking a DLL) in a temp directory --
    eg. build/temp.linux-i586 on my machine.

  * make the "is this a pure Python distribution or a distribution
    with extensions?" decision at build time rather than install time
    -- the effect of this is that *everything* will build to either
    build/lib or build/lib.<plat>

  * support building extensions right into the source tree, so that
    developers hacking away on an extension don't have to screw around
    with "building" Python modules or mucking with PYTHONPATH (or
    kludging sys.path)

I'm still working on the "build_lib" command, which I think I'm going to
rename to "build_clib", since that's what it does.  (The terminology I'm
gravitating towards is that "lib" means "Python library directory",
"purelib" means "pure Python library directory", and "platlib" means
"platform-specific Python library directory".  Thus it's misleading to
call the command that builds C/C++ libraries "build_lib", since it has
nothing to do with Python libraries.)

But the basic Python building stuff -- pure Python and extensions --
seems to be working.  Check it out and give it a spin if you're feeling
brave.  Maybe tomorrow at work I'll actually test it on a platform other 
than Linux.  ;-)

        Greg
-- 
Greg Ward - Unix bigot                                  gward@python.net
http://starship.python.net/~gward/
"When I hear the word `culture', I reach for my gun." --Goebbels
"When I hear the word `Microsoft', *I* reach for *my* gun." --me


From gward@python.net  Thu Mar  2 02:16:19 2000
From: gward@python.net (Greg Ward)
Date: Wed, 1 Mar 2000 21:16:19 -0500
Subject: [Distutils] Upheaval in build commands: almost done!
Message-ID: <20000301211619.A1688@beelzebub>

Hi all --

as I mentioned last night, I've been hacking on the build_* commands
lately, with the goal of putting all temporary compiler by-products
under build/temp.<plat>, and allowing "in-place" building of extensions.

Everything is done now, and for the most part It Works For Me (TM).  (I
just remembered that I haven't tested the new --inplace option on the
build_ext command -- arg!)  Windows support isn't there yet -- I have to
hack on the MSVCCompiler class a bit, and I think I will take advantage
of this to reduce overlap and increase uniformity between UnixCCompiler
and MSVCCompiler -- ie. it'll take parallel printouts and a couple of
hours, so I'll save it for tomorrow.

Anyways, if you're a on a Unix-y platform, please check out the latest
CVS and try building some distributions with extensions and/or C
libraries.  NumPy and PIL are as usual the canonical examples (setup
script free with the Distutils!), but if you're feeling adventurous you
might try distutilizing some other distribution.

Oh yeah, the setup.py currently distributed with NumPy won't work with
the CVS version of Distutils; you'll have to replace it with
examples/numpy_setup.py.  It was the renaming thing in command classes
that did it, y'know.

        Greg
-- 
Greg Ward - Unix weenie                                 gward@python.net
http://starship.python.net/~gward/
Never underestimate the power of human stupidity.


From gward@python.net  Sat Mar  4 18:07:11 2000
From: gward@python.net (Greg Ward)
Date: Sat, 4 Mar 2000 13:07:11 -0500
Subject: [Distutils] Question about DOS/Windows static libs
Message-ID: <20000304130711.A545@beelzebub>

Hi all --

a question for the Windows crowd: in the current distutils MSVCCompiler
class, the 'link_static_lib()' method takes arguments for libraries and
library search directories -- this implies that, when building static
libraries under Windows, the library-building tool needs to be told
which other libraries this one depends on, and where to find them.

This is different from the Unix world, where a static library just has
dangling references that are resolved at link-time.  This also differs
from the "canonical compiler interface" defined by the CCompiler class;
so, if it is needed on Windows, I'll have to change this canonical
interface.

So: is this true?  Does a static library under Windows need to be built
with library and library search directories?  Or is this an unnecessary
appendage that can be jettisoned?

(Yep, I'm on a simplify-the-code vendetta this weekend...)

        Greg
-- 
Greg Ward - just another Python hacker                  gward@python.net
http://starship.python.net/~gward/
Cheops' Law: Nothing *ever* gets built on schedule or within budget.


From jim@interet.com  Mon Mar  6 14:15:05 2000
From: jim@interet.com (James C. Ahlstrom)
Date: Mon, 06 Mar 2000 09:15:05 -0500
Subject: [Distutils] Question about DOS/Windows static libs
References: <20000304130711.A545@beelzebub>
Message-ID: <38C3BD69.4D59A169@interet.com>

Greg Ward wrote:

> So: is this true?  Does a static library under Windows need to be built
> with library and library search directories?  Or is this an unnecessary
> appendage that can be jettisoned?

AFAIK, Windows is just like Unix.  You specify a list of libraries to
use to find undefined symbols.  In Unix you add "-lsomething" to the
linker
command line, and in
Windows you add "something.lib" to a list.

The list of lib search directories is used to find the file
"something.lib" in case the full path is not specified.

Only undefined symbols cause code to be linked from these libraries.
If the libs are not needed, no code from them is linked.  Windows
uses a lengthy list of libraries, the whole OS is a bunch of DLL's.

JimA


From gward@python.net  Tue Mar  7 02:34:04 2000
From: gward@python.net (Greg Ward)
Date: Mon, 6 Mar 2000 21:34:04 -0500
Subject: [Distutils] Question about DOS/Windows static libs
In-Reply-To: <38C3BD69.4D59A169@interet.com>; from James C. Ahlstrom on Mon, Mar 06, 2000 at 09:15:05AM -0500
References: <20000304130711.A545@beelzebub> <38C3BD69.4D59A169@interet.com>
Message-ID: <20000306213404.A503@beelzebub>

[me]
> So: is this true?  Does a static library under Windows need to be built
> with library and library search directories?  Or is this an unnecessary
> appendage that can be jettisoned?

[Jim Ahlstrom]
> AFAIK, Windows is just like Unix.  You specify a list of libraries to
> use to find undefined symbols.  In Unix you add "-lsomething" to the
> linker
> command line, and in
> Windows you add "something.lib" to a list.

No no, I'm talking about *building* a library, not about using one.
I.e. when you bundle *.obj together into foo.lib, do you need to tell
the tool-that-creates-foo.lib what libraries the code in *.obj depends
on and where to find those libraries?

Under Unix, it goes like this:

  cc -c foo1.c foo2.c foo3.c     # create *.o
  ar -cr libfoo.a foo1.o foo2.o foo3.o

and with MSVC++'s command-line interface, I gather it's something
sorta-kinda-vaguely like this:

  cl /c /Tcfoo1.c /Fofoo1.obj  # repeat three times
  link foo1.obj foo2.obj foo3.obj /OUT:foo.lib

HOWEVER, the code that does this in Distutils adds other libraries to
this mix.  My question: is this necessary?  Does the MSVC++ linker need
to know how to resolve symbols in *.obj *when it bundles them together
into a static library*?

If so, this affects the CCompiler interface; currently, MSVCCompiler and
UnixCCompiler are inconsistent, and I want to fix that.  The question
is, do I add unused 'libraries' and 'library_dirs' args to the
UnixCCompiler link-a-static-lib method, or do I remove them from the
corresponding MSVCCompiler method?

Perry Stoll, author of the original code, seems to think that removing
the library options from MSVCCompiler's 'link_static_lib()' is OK, so
that's what I'm inclined to do.  I just want to make sure I'm not
misunderstanding what it means to build a static library with MSVC++.

        Greg
-- 
Greg Ward - Unix weenie                                 gward@python.net
http://starship.python.net/~gward/
BE ALERT!!!!  (The world needs more lerts ...)


From robin@jessikat.demon.co.uk  Tue Mar  7 08:11:45 2000
From: robin@jessikat.demon.co.uk (Robin Becker)
Date: Tue, 7 Mar 2000 08:11:45 +0000
Subject: [Distutils] Question about DOS/Windows static libs
In-Reply-To: <20000306213404.A503@beelzebub>
References: <20000304130711.A545@beelzebub> <38C3BD69.4D59A169@interet.com>
 <20000306213404.A503@beelzebub>
Message-ID: <IiwEbAABnLx4EwCN@jessikat.demon.co.uk>

In article <20000306213404.A503@beelzebub>, Greg Ward <gward@python.net>
writes
>[me]
>> So: is this true?  Does a static library under Windows need to be built
>> with library and library search directories?  Or is this an unnecessary
>> appendage that can be jettisoned?
>
...
according to the lib reference .lib files can be input to lib commands;
so you can combine libraries and .obj files to produce a new static lib.

It's not very clear, but I guess the .libs should be for static
libraries.
-- 
Robin Becker


From vanandel@ucar.edu  Tue Mar  7 16:31:08 2000
From: vanandel@ucar.edu (Joe Van Andel)
Date: Tue, 07 Mar 2000 09:31:08 -0700
Subject: [Distutils] distutils - locating include files, specifying C libraries
References: <20000301211619.A1688@beelzebub>
Message-ID: <38C52ECC.66E8EFE7@atd.ucar.edu>

This is a multi-part message in MIME format.
--------------1E265613DB92B696329ED604
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'm trying to use distutils (CVS from 3/6/2000) to build C++ extensions
that use the Numeric library.  I'm using Python 1.5.2, Redhat 6.1,
Solaris 2.6 and Gcc 2.95.2

I'm pleased that I can build and install my  extensions for both Solaris
and Linux, now that I've built workarounds for the two problems I
describe below.  Given that distutils automatically builds libraries and
objects in machine-dependent temporary directories, I find it much
easier to use than the corresponding Makefiles.


Here are two problems that should be addressed.

Problem 1 - locating Python extension include files.

Numeric has its own include files, which are installed under
/usr[/local]/include/python1.5/Numeric

I want to specify the location of the Numeric include files in an
installation/machine independent way.  I added the following into my
setup.py file:

######################

from distutils import sysconfig

#determine location of Python include files, to locate Numeric includes

config_h = sysconfig.get_config_h_filename()
py_inc = os.path.dirname(config_h)
NUM_INC = os.path.join(py_inc, 'Numeric')

#################################
I've attached a patch for sysconfig.py that defines get_python_inc(), to
provide a cleaner way to
find where the python includes are located.

This allows a user to find the python include files as follows:
py_inc = sysconfig.get_python_inc()
NUM_INC = os.path.join(py_inc, 'Numeric')

Problem 2 - specifying architecture/compiler specific libraries to
setup.py

When I link my extension on Linux (RH 6.1), I need to specify
 'libraries': ['gcc', 'stdc++','pthread'],

However, when I link my extensions on Solaris 2.6, these libraries do
not exist.

(At this point, we start approaching the complex world of GNU
'autoconf', that dynamically checks for the existence of specified
libraries! )

Here's a solution, is there a better one?

from distutils.util import get_platform
plat = get_platform()

# machine dependent C/C++ support libs
if plat == 'linux-i586' :
    CLIBS=['gcc', 'stdc++','pthread']
else:
    CLIBS=[]


.
.
.
 ext_modules = [
                      ('Perp.a1pp.pulsepairc',
                       {'sources': ['a1pp/pulsepair.cc',
                                    'a1pp/pulsepair_wrap.cc'],
                        'libraries': CLIBS,
                        },
                        ),




-- 
Joe VanAndel  	          
National Center for Atmospheric Research
http://www.atd.ucar.edu/~vanandel/
Internet: vanandel@ucar.edu
--------------1E265613DB92B696329ED604
Content-Type: text/plain; charset=us-ascii;
 name="sysconfig.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="sysconfig.patch"

*** sysconfig.py.orig	Tue Mar  7 08:44:18 2000
--- sysconfig.py	Tue Mar  7 08:45:18 2000
***************
*** 25,30 ****
--- 25,37 ----
          return os.path.join(exec_prefix,
                              "include", "python" + sys.version[:3],
                              "config.h")
+ def get_python_inc():
+     """Return full pathname of installed config.h file."""
+     if os.name == "nt":
+         return os.path.join(exec_prefix, "include")
+     else:
+         return os.path.join(exec_prefix,
+                             "include", "python" + sys.version[:3])
  
  def get_makefile_filename():
      """Return full pathname of installed Makefile from the Python build."""

--------------1E265613DB92B696329ED604--



From gward@python.net  Thu Mar  9 03:08:03 2000
From: gward@python.net (Greg Ward)
Date: Wed, 8 Mar 2000 22:08:03 -0500
Subject: [Distutils] distutils - locating include files, specifying C libraries
In-Reply-To: <38C52ECC.66E8EFE7@atd.ucar.edu>; from Joe Van Andel on Tue, Mar 07, 2000 at 09:31:08AM -0700
References: <20000301211619.A1688@beelzebub> <38C52ECC.66E8EFE7@atd.ucar.edu>
Message-ID: <20000308220803.A469@beelzebub>

On 07 March 2000, Joe Van Andel said:
> I'm trying to use distutils (CVS from 3/6/2000) to build C++ extensions
> that use the Numeric library.  I'm using Python 1.5.2, Redhat 6.1,
> Solaris 2.6 and Gcc 2.95.2

Great -- first successful build of C++ extensions, AFAIK.  I hope the
compiler interface is holding up under the strain.  Planning to try it
under Windows?

> I'm pleased that I can build and install my  extensions for both Solaris
> and Linux, now that I've built workarounds for the two problems I
> describe below.  Given that distutils automatically builds libraries and
> objects in machine-dependent temporary directories, I find it much
> easier to use than the corresponding Makefiles.

Oh good, another completely untested feature getting a workout.  The
intention of having per-architecture build directories was for
installers and/or developers to be able to do this:

  [on arch. A, eg. Linux]
  python setup.py build
  [on arch. B, eg. Solaris]
  python setup.py build

and have *no* interference between the two builds, ie. everything would
be in the build/temp.<plat> directory.  You should be able to build on
A, build on B, install on A, install on B.  Whatever.  I have not tested
any of this for real, though, and it's only been in the source since the
weekend: so, does it work for you?

> Here are two problems that should be addressed.
> 
> Problem 1 - locating Python extension include files.

Hmm, yeah, I worried about this a bit when hacking Numeric's setup
script to install header files.  Didn't have an answer then.

> I want to specify the location of the Numeric include files in an
> installation/machine independent way.  I added the following into my
> setup.py file:
[...]
> config_h = sysconfig.get_config_h_filename()
> py_inc = os.path.dirname(config_h)
> NUM_INC = os.path.join(py_inc, 'Numeric')

Nice kludge, but subtly wrong: the config.h directory is for
platform-specific header files.  You most likely want the
non-platform-specific header file directory, ie. where Python.h and
friends live.

I think your patch (add 'get_python_inc()') is 95% exactly right.
Here's my adaptation of it, with Mac support based on Corran Webster's
'_init_mac()' (checked in last night -- thanks Corran!):

  def get_python_inc (plat_specific=0):
      """Return the directory containing installed Python header files.
         If 'plat_specific' is false (the default), this is the path to the
         non-platform-specific header files, i.e. Python.h and so on;
         otherwise, this is the path to platform-specific header files
         (namely config.h)."""

      the_prefix = (plat_specific and exec_prefix or prefix)
      if os.name == "posix":
          return os.path.join (the_prefix,
                               "include", "python" + sys.version[:3])
      elif os.name == "nt":
          return os.path.join (the_prefix, "Include") # include or Include?
      elif os.name == "mac":
          return os.path.join (the_prefix, "Include")
      else:
          raise DistutilsPlatformError, \
                ("I don't know where Python installs its C header files " +
                 "on platform '%s'") % os.name


Ummm, should that be "Include" on Windows for consistency with "Lib"?
(Yes yes, I know it doesn't strictly matter, but I'm a stickler for
aesthetic consistency, even in a tty-style UI.)

'get_config_h_filename()' should change to use the new
function... there, done.  And come to think of it, why not add
'get_python_lib()'?  The 'install_py' command should probably use this
instead of some ugly GLOBAL exported by sysconfig, and it could be handy
for setup scripts that want to do naughty things but still play nice
(ie. use portable directory names).

Here's 'get_python_lib()':

  def get_python_lib (plat_specific=0, standard_lib=0):
      """Return the directory containing the Python library (standard or
         site additions).  If 'plat_specific' is true, return the directory
         containing platform-specific modules, i.e. any module from a
         non-pure-Python module distribution; otherwise, return the
         platform-shared library directory.  If 'standard_lib' is true,
         return the directory containing standard Python library modules;
         otherwise, return the directory for site-specific modules."""

      the_prefix = (plat_specific and exec_prefix or prefix)

      if os.name == "posix":
          libpython = os.path.join (the_prefix,
                                    "lib", "python" + sys.version[:3])
          if standard_lib:
              return libpython
          else:
              return os.path.join (libpython, "site-packages")

      elif os.name == "nt":
          if standard_lib:
              return os.path.join (the_prefix, "Lib")
          else:
              return the_prefix

      elif os.name == "mac":
          if platform_specific:
              if standard_lib:
                  return os.path.join (exec_prefix, "Mac", "Plugins")
              else:
                  raise DistutilsPlatformError, \
                        "OK, where DO site-specific extensions go on the Mac?"
          else:
              if standard_lib:
                  return os.path.join (prefix, "Lib")
              else:
                  raise DistutilsPlatformError, \
                        "OK, where DO site-specific modules go on the Mac?"
      else:
          raise DistutilsPlatformError, \
                ("I don't know where Python installs its library " +
                 "on platform '%s'") % os.name

  # get_python_lib ()

Hint hint: I need help with the Mac support!

> Problem 2 - specifying architecture/compiler specific libraries to
> setup.py
> 
> When I link my extension on Linux (RH 6.1), I need to specify
>  'libraries': ['gcc', 'stdc++','pthread'],

Nope, I still don't have an answer to this one.

> (At this point, we start approaching the complex world of GNU
> 'autoconf', that dynamically checks for the existence of specified
> libraries! )

Well, except for this non-answer.  If I start rewriting Autoconf in
Python for Distutils 1.0, though, Guido will kill me (there's already
too damn much code in this thing!).

> Here's a solution, is there a better one?
> 
> from distutils.util import get_platform
> plat = get_platform()
> 
> # machine dependent C/C++ support libs
> if plat == 'linux-i586' :
>     CLIBS=['gcc', 'stdc++','pthread']
> else:
>     CLIBS=[]

That would be the "everybody-has-a-personal-imake-database-in-their-
setup-script" non-solution.  Ick.  See also the pil_setup.py example in
the distutils source, which goes for the "everyone-knows-what-libraries-
they-have-installed-and-edits-the-setup-script" non-solution, which is
approximately as nasty.

So far, I have yet to be convinced that there is *any* long-term
solution short of rewriting Autoconf in Python.  (Distutils 2.0,
anyone?)  And oh yeah, this has to be an Autoconf that runs on Unix,
Windows, and Mac OS.  Good thing there's a portable C/C++ compiler
framework!

        Greg
-- 
Greg Ward - just another /P(erl|ython)/ hacker          gward@python.net
http://starship.python.net/~gward/
God is real, unless declared integer.


From jonathan.gilligan@vanderbilt.edu  Thu Mar  9 08:11:09 2000
From: jonathan.gilligan@vanderbilt.edu (Jonathan M. Gilligan)
Date: Thu, 09 Mar 2000 02:11:09 -0600
Subject: [Distutils] distutils - Filenames/Pathnames with spaces under WinNT
In-Reply-To: <20000308220803.A469@beelzebub>
References: <38C52ECC.66E8EFE7@atd.ucar.edu>
 <20000301211619.A1688@beelzebub>
 <38C52ECC.66E8EFE7@atd.ucar.edu>
Message-ID: <4.2.0.58.20000309010021.00abf720@g.mail.vanderbilt.edu>

I'm new on this list, so please forgive me if I'm treading on familiar 
ground, but I didn't see this issue raised when I browsed through the last 
month or so of archives.

Distutils for Windows NT,9x,2K seems to have a big hole in the way it forms 
command-lines for the compiler and friends: it doesn't account for the fact 
that filenames and pathnames may have spaces in them and thus may need to 
be quoted on the command-line passed to external tools (compiler, linker). 
Given that the standard Python 1.5.2 distribution installs itself on 
"C:\Program Files\Python" this leads to potentially problematic 
command-lines of the form

    cl -IC:\Program Files\Python\include
    link C:\Program Files\Python\Libs\python15.lib

Both of these command lines will fail, because cl can't find the directory 
"C:\Program" and can't find "Files\Python\include.obj" and link can't find 
"C:\Program" or "Files\Python\Libs\python15.lib". CL and LINK both reparse 
the command-line so even if "-IC:/Program Files/Python/include" is passed 
as a single argument to os.spawnv(), it is split into two by cl's 
command-line parser:

    Python 1.5.2 (#0, Feb  2 2000, 22:07:42) [MSC 32 bit (Intel)] on win32
    Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
    >>> from distutils.spawn import *
    >>> spawn(['cl','-c','-IC:/Program Files/Python/include','client.cpp'])
    Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86
    Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

    Command line warning D4024 : unrecognized source file type 
'Files/Python/include', object file assumed
    Command line warning D4027 : source file 'Files/Python/include' ignored
    client.cpp
    client.cpp(7) : fatal error C1083: Cannot open include file: 
'python.h': No such file or directory
    Traceback (innermost last):
      File "<stdin>", line 1, in ?
      File "C:\Program Files\python\python-1.5.2\distutils\spawn.py", line 
37, in spawn
        _spawn_nt (cmd, search_path, verbose, dry_run)
      File "C:\Program Files\python\python-1.5.2\distutils\spawn.py", line 
74, in _spawn_nt
        raise DistutilsExecError, \
    distutils.errors.DistutilsExecError: command 'cl' failed with exit status 2
    >>>

The command-lines should be:

    cl -I"C:\Program Files\Python\include"
    link "C:\Program Files\Python\Libs\python15.lib"

which work:

    Python 1.5.2 (#0, Feb  2 2000, 22:07:42) [MSC 32 bit (Intel)] on win32
    Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
    >>> from distutils.spawn import *
    >>> spawn(['cl','-c','-I"C:/Program Files/Python/include"','client.cpp'])
    Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86
    Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

    client.cpp
    >>>

I started hacking at the msvccompiler.py source to put quotes around 
filenames passed as arguments, but then realized that it would probably be 
better to implement a "wrapfilename(fname)" method in the ccompiler class 
and then subclass it appropriately for *ix (return fname) and WinNT (return 
'"%s"' % fname). Then every time a filename or path gets added to a 
command-line it must be processed with wrapfilename(). For instance:

    inputOpt = fileOpt + wrapfilename(srcFile)

Does this sound like a reasonable approach? Am I missing a boat somewhere?

Implementing this looks as thought it will require modifying (slightly) a 
number functions in ccompiler.py and msvccompiler.py, so I would like 
feedback from all of you more experienced folks on this list before I spend 
any time at it. I also might not be the best person to try, being a 
greenhorn and thus less prone to catch where such a modification would 
break existing code, but I am willing to make a pass at it if others don't 
have the time.

Alternately, one could modify _spawn_nt to wrap each of its arguments in 
double-quotes, but that seems potentially more problematic (Some programs 
may not transparently discard quotation marks on command-line arguments. 
Consider the behavior of the find command.).

Thanks for listening,
Jonathan Gilligan


From fdrake@acm.org  Thu Mar  9 14:16:45 2000
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 9 Mar 2000 09:16:45 -0500 (EST)
Subject: [Distutils] distutils - locating include files, specifying C libraries
In-Reply-To: <20000308220803.A469@beelzebub>
References: <20000301211619.A1688@beelzebub>
 <38C52ECC.66E8EFE7@atd.ucar.edu>
 <20000308220803.A469@beelzebub>
Message-ID: <14535.45645.333562.323633@weyr.cnri.reston.va.us>

Greg Ward writes:
 > Ummm, should that be "Include" on Windows for consistency with "Lib"?
 > (Yes yes, I know it doesn't strictly matter, but I'm a stickler for
 > aesthetic consistency, even in a tty-style UI.)

  The installer created the directory "include" on my box.
Inconsistent with "Lib", but that's deployment for you!


  -Fred

--
Fred L. Drake, Jr.	  <fdrake at acm.org>
Corporation for National Research Initiatives


From jim@interet.com  Thu Mar  9 14:40:51 2000
From: jim@interet.com (James C. Ahlstrom)
Date: Thu, 09 Mar 2000 09:40:51 -0500
Subject: [Distutils] Question about DOS/Windows static libs
References: <20000304130711.A545@beelzebub> <38C3BD69.4D59A169@interet.com> <20000306213404.A503@beelzebub>
Message-ID: <38C7B7F3.C262FC9B@interet.com>

Greg Ward wrote:
> 
> No no, I'm talking about *building* a library, not about using one.

Oh, sorry.

> Under Unix, it goes like this:
> 
>   cc -c foo1.c foo2.c foo3.c     # create *.o
>   ar -cr libfoo.a foo1.o foo2.o foo3.o
> 
> and with MSVC++'s command-line interface, I gather it's something
> sorta-kinda-vaguely like this:
> 
>   cl /c /Tcfoo1.c /Fofoo1.obj  # repeat three times
>   link foo1.obj foo2.obj foo3.obj /OUT:foo.lib

Well, no.  AFAIK "link" can create only executables or DLL's, not
libraries.  Note that, despite the name, a Dynamic Link Library is
very much like an executable and not much like a Unix static lib.

To create libraries under Windows, use the lib program:
    lib.exe /OUT:libfoo.lib foo1.obj foo2.obj foo3.obj 

Only the Windows "Great Unwashed" pay attention to this.  Normal
Windows people use the development environment.  In particular this
makes it easy to use lengthy lists of *.obj's instead of libraries.

JimA


From fdrake@acm.org  Thu Mar  9 16:39:43 2000
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 9 Mar 2000 11:39:43 -0500 (EST)
Subject: [Distutils] get_python_inc(), get_python_lib()
Message-ID: <14535.54223.40383.487230@weyr.cnri.reston.va.us>

  I was just looking at sysconfig.py again, and I'm not sure I really
like the interfaces to get_python_*().  In particular, the
plat_specific parameter seems strange, especially since it will
produce the same result in most cases.
  Perhaps the Right Way To Do It(TM) would be to drop the parameter
and return a list containing all the dirs that apply.  To locate
config.h, for instance, search each location in the list.
  I'd also rename get_python_inc() to get_python_include(), but
perhaps that's just me.  ;)


  -Fred

--
Fred L. Drake, Jr.	  <fdrake at acm.org>
Corporation for National Research Initiatives


From jonathan.gilligan@vanderbilt.edu  Thu Mar  9 19:23:30 2000
From: jonathan.gilligan@vanderbilt.edu (Jonathan M. Gilligan)
Date: Thu, 09 Mar 2000 13:23:30 -0600
Subject: [Distutils] Question about DOS/Windows static libs
 (Hairsplitting)
In-Reply-To: <38C7B7F3.C262FC9B@interet.com>
References: <20000304130711.A545@beelzebub>
 <38C3BD69.4D59A169@interet.com>
 <20000306213404.A503@beelzebub>
Message-ID: <4.3.2.20000309131642.04fd3560@g.mail.vanderbilt.edu>

While you're mostly correct, I would point out just for the sake of 
insufferable precision, that "Lib" is just an alias for "link /LIB". 
Lib.exe is just a stub that calls "link /LIB", so in the example below, you 
would just as easily put
    link /LIB /OUT:libfoo.lib foo1.obj foo2.obj foo3.obj

Jonathan

At 08:40 AM 3/9/2000, James C. Ahlstrom wrote:
>Well, no.  AFAIK "link" can create only executables or DLL's, not
>libraries.  Note that, despite the name, a Dynamic Link Library is
>very much like an executable and not much like a Unix static lib.
>
>To create libraries under Windows, use the lib program:
>     lib.exe /OUT:libfoo.lib foo1.obj foo2.obj foo3.obj
>
>Only the Windows "Great Unwashed" pay attention to this.  Normal
>Windows people use the development environment.  In particular this
>makes it easy to use lengthy lists of *.obj's instead of libraries.

===========================================================================
Jonathan M. Gilligan                     <jonathan.gilligan@vanderbilt.edu>
Research Assistant Professor of Physics                      (615) 343-6252
Dept. of Physics and Astronomy, Box 1807-B                    Fax: 343-7263
6823 Stevenson Center
Vanderbilt University, Nashville, TN 37235           Dep't Office: 322-2828



From gward@python.net  Fri Mar 10 01:00:58 2000
From: gward@python.net (Greg Ward)
Date: Thu, 9 Mar 2000 20:00:58 -0500
Subject: [Distutils] distutils - Filenames/Pathnames with spaces under WinNT
In-Reply-To: <4.2.0.58.20000309010021.00abf720@g.mail.vanderbilt.edu>; from Jonathan M. Gilligan on Thu, Mar 09, 2000 at 02:11:09AM -0600
References: <38C52ECC.66E8EFE7@atd.ucar.edu> <20000301211619.A1688@beelzebub> <38C52ECC.66E8EFE7@atd.ucar.edu> <20000308220803.A469@beelzebub> <4.2.0.58.20000309010021.00abf720@g.mail.vanderbilt.edu>
Message-ID: <20000309200058.A512@beelzebub>

On 09 March 2000, Jonathan M. Gilligan said:
> I'm new on this list, so please forgive me if I'm treading on familiar 
> ground, but I didn't see this issue raised when I browsed through the last 
> month or so of archives.
> 
> Distutils for Windows NT,9x,2K seems to have a big hole in the way it forms 
> command-lines for the compiler and friends: it doesn't account for the fact 
> that filenames and pathnames may have spaces in them and thus may need to 
> be quoted on the command-line passed to external tools (compiler, linker). 

Yeah, that did come up not *too* long ago.  It was during a big flurry
of activity on the Windows support, so no surprise that you missed it.

Bottom line: Thomas Heller submitted a patch several weeks ago, and I
*finally* got around to applying it this weekend.  It's in the CVS
version.

> I started hacking at the msvccompiler.py source to put quotes around 
> filenames passed as arguments, but then realized that it would probably be 
> better to implement a "wrapfilename(fname)" method in the ccompiler class 
> and then subclass it appropriately for *ix (return fname) and WinNT (return 
> '"%s"' % fname). Then every time a filename or path gets added to a 
> command-line it must be processed with wrapfilename(). For instance:
> 
>     inputOpt = fileOpt + wrapfilename(srcFile)
> 
> Does this sound like a reasonable approach? Am I missing a boat somewhere?

But what about arguments with spaces in them that *aren't* filenames?
(And what about spawning programs on Windows *other* than the
compiler/linker?  Granted that's not happening right now in Distutils,
but who knows what'll happen in the future?)

> Alternately, one could modify _spawn_nt to wrap each of its arguments in 
> double-quotes, but that seems potentially more problematic (Some programs 
> may not transparently discard quotation marks on command-line arguments. 
> Consider the behavior of the find command.).

That's exactly what we ended up doing.  Your point about some programs
not dealing with quote characters is a bit unsettling, though.  *sigh*

"Those who do not learn from Unix are doomed to reinvent it -- badly."

        Greg
-- 
Greg Ward - Unix weenie                                 gward@python.net
http://starship.python.net/~gward/
Earn cash in your spare time -- blackmail your friends!


From gward@python.net  Fri Mar 10 01:21:02 2000
From: gward@python.net (Greg Ward)
Date: Thu, 9 Mar 2000 20:21:02 -0500
Subject: [Distutils] Question about DOS/Windows static libs
In-Reply-To: <38C7B7F3.C262FC9B@interet.com>; from James C. Ahlstrom on Thu, Mar 09, 2000 at 09:40:51AM -0500
References: <20000304130711.A545@beelzebub> <38C3BD69.4D59A169@interet.com> <20000306213404.A503@beelzebub> <38C7B7F3.C262FC9B@interet.com>
Message-ID: <20000309202102.B512@beelzebub>

On 09 March 2000, James C. Ahlstrom said:
> Well, no.  AFAIK "link" can create only executables or DLL's, not
> libraries.  Note that, despite the name, a Dynamic Link Library is
> very much like an executable and not much like a Unix static lib.
> 
> To create libraries under Windows, use the lib program:
>     lib.exe /OUT:libfoo.lib foo1.obj foo2.obj foo3.obj 

A-ha!  I've just had one of those minor revelations that comes only
after months of being totally blind to the painfully obvious: I named
the method wrong.  It should be 'create_static_lib()', not
'link_static_lib()'.  There... it's fixed: renamed and rewritten to use
"lib.exe", not refer to any other libraries, and be consistent with the
CCompiler API.

Here's what it's supposed to do (docstring from ccompiler.py):

        """Link a bunch of stuff together to create a static library
           file.  The "bunch of stuff" consists of the list of object
           files supplied as 'objects', the extra object files supplied
           to 'add_link_object()' and/or 'set_link_objects()', the
           libraries supplied to 'add_library()' and/or
           'set_libraries()', and the libraries supplied as 'libraries'
           (if any).

           'output_libname' should be a library name, not a filename; the
           filename will be inferred from the library name.  'output_dir'
           is the directory where the library file will be put.

           'debug' is a boolean; if true, debugging information will be
           included in the library (note that on most platforms, it is the
           compile step where this matters: the 'debug' flag is included
           here just for consistency)."""

And here's the new implementation in msvccompiler.py:

    def create_static_lib (self,
                           objects,
                           output_libname,
                           output_dir=None,
                           debug=0,
                           extra_preargs=None,
                           extra_postargs=None):

        (objects, output_dir) = \
            self._fix_link_args (objects, output_dir, takes_libs=0)
        output_filename = \
            self.library_filename (output_libname, output_dir=output_dir)

        if self._need_link (objects, output_filename):
            lib_args = objects + ['/OUT:' + output_filename]
            if debug:
                pass                    # XXX what goes here?
            if extra_preargs:
                lib_args[:0] = extra_preargs
            if extra_postargs:
                lib_args.extend (extra_postargs)
            self.spawn ([self.link] + ld_args)
        else:
            self.announce ("skipping %s (up-to-date)" % output_filename)

    # create_static_lib ()

('self.link' is the full path to link.exe, found by scouring the
registry for DevStudio... or it's just "link.exe" if we didn't find
DevStudio in the registry, eg. if we don't have registry access modules
available.)

OK, just fixed the build_clib command... and PIL still builds fine (PIL,
and distributions like it that include a C library, is the whole point
of this exercise).

        Greg
-- 
Greg Ward - "always the quiet one"                      gward@python.net
http://starship.python.net/~gward/
UFO's are for real: the Air Force doesn't exist.


From gward@python.net  Fri Mar 10 01:27:32 2000
From: gward@python.net (Greg Ward)
Date: Thu, 9 Mar 2000 20:27:32 -0500
Subject: [Distutils] get_python_inc(), get_python_lib()
In-Reply-To: <14535.54223.40383.487230@weyr.cnri.reston.va.us>; from Fred L. Drake, Jr. on Thu, Mar 09, 2000 at 11:39:43AM -0500
References: <14535.54223.40383.487230@weyr.cnri.reston.va.us>
Message-ID: <20000309202732.C512@beelzebub>

On 09 March 2000, Fred L. Drake, Jr. said:
>   I was just looking at sysconfig.py again, and I'm not sure I really
> like the interfaces to get_python_*().  In particular, the
> plat_specific parameter seems strange, especially since it will
> produce the same result in most cases.
>   Perhaps the Right Way To Do It(TM) would be to drop the parameter
> and return a list containing all the dirs that apply.  To locate
> config.h, for instance, search each location in the list.

But it's not just for finding stuff -- it's also for installing stuff.
Actually, I think include files should probably always be installed to
the platform-specific directory:

  * include files are presumably only distributed with extensions
    ("non-pure distribtions")
  * we've said again and again that all modules in a non-pure
    distribution go under exec-prefix
  * one of the arguments in favour of that is so that you don't
    get version/platform mismatches
  * that argument is just as strong for C header files
  * therefore, C header files should always be installed (at least
    on Unix) to <exec-prefix>/include/python1.X/<distname>

But we still need access to both include directories, e.g. if you need
to find Python.h (or if you need to add its directory to the compiler
command line, which you most certainly do: I just haven't updated the
build_ext command to use the new function interface yet, it's still
using the UPPERCASE_GLOBALS interface).

However, for installation, we certainly care about the difference
between the platform-specific and platform-shared lib directories.
Hence the 'plat_specific' argument to 'get_python_lib()'.

>   I'd also rename get_python_inc() to get_python_include(), but
> perhaps that's just me.  ;)

Yeah, I think you're right.  One change at a time, though...  ;-)

        Greg
-- 
Greg Ward - just another /P(erl|ython)/ hacker          gward@python.net
http://starship.python.net/~gward/
I'd rather have a bottle in front of me than have to have a frontal lobotomy.


From mmuller@enduden.com  Sat Mar 11 00:56:46 2000
From: mmuller@enduden.com (Michael Muller)
Date: Fri, 10 Mar 2000 19:56:46 -0500
Subject: [Distutils] Dependency and compatibility
Message-ID: <38C999CE.569A76AB@enduden.com>

Hi all,

The package meta-info patch I sent out a while ago includes some immature
facilities for tracking project dependencies and project compatibilities,
two ideas that I'm very interested in which I'd like to seed some discussion
on in the hopes that they will be integrated in some form or another into
distutils.

Definition of terms:

_Dependencies_ are versions of external packages that a given package is
dependent upon.

A version of A a package is _Compatible_ with version B of the same package
iff A provides the same _Public Interface_ as B - A may extend B's
interface, but it may not omit any portion of it. The _Public Interface_ of
a package includes all methods and attributes that are available and not
designated as private, either explicitly in the documentation of the
package, or implicitly through the use of standard naming conventions (i.e.
names preceeded by an underscore).  It also includes the documented behavior
of methods, particularly with respect to parameter types and return values.
This subject is worthy of a much longer document, but I want to keep this
brief.

_Compatible Versions_ are versions of a package that are Compatible with a
given version of the package.

I define the _Compatibility Set_ as the inverse form of Compatible Versions:
it is the set of all versions that a package is compatible with.  If p-v1 is
compatible with p-v0, p-v0 is in p-v1's compatibility set, and p-v1 is in
p-v0's compatible versions.

If we track the dependencies and the compatibility sets of each package, it
should be possible to provide a fairly flexible system to determine whether or
not all of the required dependencies for a particular package are present, and
at least advise the user if they are not, perhaps allowing them to download
the required packages at the time of installation.

The problem is, a dependent may be compatible with many versions of a
particular dependency.  Rather than enumerating every compatibility, it
would seem desirable to define a regular-expression like syntax for
describing sets of versions, for example:

  1.20-?     matches all versions with a major number of 1 and a minor 
             number > 20
  1*         matches all versions with a major number of 1
  1.3-4*     matches 1.3.6, 1.4.1, and 1.4, but not 1.5, or 1.40

Here's an example of how such a system might function in a particular case:

   Package A version 1.2 is installed on a system and has a compatibility set
= [ '1.0.5-?', '1.1*' ] (i.e. 1.2 is compatible with all 1.0.n versions after
1.0.5, and all 1.1 versions).

   Package B version 2.0 has a dependency on package A version '1.0.9'.

In this case, the dependency is satisfied by the installed version.

This model is pretty straight-forward, however, it gets worse.  Sometimes a
compatibility break in a service package doesn't affect a particular
dependent: it doesn't matter to my package if you remove method foo() if I
don't use method foo().  For this reason, each dependency should be described
as a /set/ of compatible versions of a package, rather than a single
compatible version.

Let's consider another example:

  Package A versions 1.0.8 is installed on a system and has a compatibility
set = [ '1.0.5-7' ]

  Package A version 1.0.4 (which is not installed) has a compatibility set = [
'1.0.1-3' ]

  Package B version 2.0 (which is not affected by the interface change between
1.0.4 and 1.0.5) has a dependency on package A versions 1.0.1 _or_ 1.0.5.

Again, the dependency is satisfied.

Some issues:

-  given the variations among the ways people version software, is my notion
   of "version wildcarding" conceptually sound?
-  is it desireable (and possible) for a package to be able to specify
   wildcard dependency versions? e.g. should B be able to specify its 
   dependency on A as "1.0.1-?"?
-  is it desireable for a package to be able to explicitly ignore the
   compatibility rules of its dependencies (perhaps using wild-card version
   numbers to describe _exactly_ which versions of another package it can 
   use)?

=============================================================================
michaelMuller = mmuller@enduden.com | http://www.cloud9.net/~proteus
-----------------------------------------------------------------------------
There is no concept that is more demeaning to the human spirit than the
notion that our freedom must be limited in the interests of our own
protection.
=============================================================================


From calvin@cs.uni-sb.de  Sun Mar 12 12:50:02 2000
From: calvin@cs.uni-sb.de (Bastian Kleineidam)
Date: Sun, 12 Mar 2000 13:50:02 +0100 (CET)
Subject: [Distutils] patch for build_ext and a suggestion
Message-ID: <Pine.LNX.4.21.0003121345590.32213-100000@void.cs.uni-sb.de>

Hello,

I have a patch for distutils-20000204.tar.gz.

patch for command/build_ext.py:
1. use correct name 'libs' instead of 'libraries' in build_ext options
2. adjust a String argument in BuildExt.libs to a list
77d76
<
88d86
<
105a104,106
>         # because fancy_getopts assigns strings
>         if type(self.libs)==StringType:
>             self.libs = [self.libs]
235c236
<             libraries = build_info.get ('libraries')
---
>             libraries = build_info.get ('libs')

The second thing is a suggestion.
Bug number 2 occurs on several more places in the distutils code.
Everytime the option type is list, the fancy_getopt method stores a
string instead.
So there are two restrictions for options:
1) An option is allowed only once and 
2) an option value type has to be a string.
Both restrictions are not necessary. What I want to have is that if I 
supply mulitple --libs options, each option value gets added to a list.

In the current implementation, subsequent option calls override the old
value. If I call
# ./setup.py build_ext --libs=ssl --libs=crypto
the ssl library value gets overridden.
Here is the code snippet from fancy_getopt.py thats responsible:
        attr = attr_name[opt]
        if takes_arg[opt]:
            setattr (object, attr, val)

Solution: instead of setattr, you should call the "set_option" function
of the object with "val" as argument.
So in the example above, this is
        attr = attr_name[opt]
        if takes_arg[opt]:
            object.set_option(attr, val)

Lets look now at the set_option function. The initial implementation 
is given in class Command:
    def set_option (self, option, value):
        """Set the value of a single option for this command.  Raise
           DistutilsOptionError if 'option' is not known."""
        if not hasattr (self, option):
            raise DistutilsOptionError, \
                  "command '%s': no such option '%s'" % \
                  (self.get_command_name(), option)
        if value is not None:
            setattr (self, option, value)

This is okay if I am happy with the above mentioned restrictions. To
extend this function, you override it in a subclass, for example in the
BuildExt class:
    # somewhere in the init function is this statement:
    self.list_value_options = ["libs", "include_dirs"] # and some more
    
    # now the new set_option
    def set_option(self, option, value):
        if option in self.list_value_options:
	    getattr(self, option).append(value)
        else:
	    Command.set_option(self, option, value)

Of course the above changes need some further refinement: you have to
initialize the list_value_options with the empty list, but then a
check "self.libs is None" will fail. Use "not self.libs" instead.
Then you have to ensure that every object we supply in fancy_getopt has
this set_option method.
And so on.

What do you think of my suggestion?

Greetings,

  Bastian Kleineidam




From gward@python.net  Mon Mar 13 03:13:46 2000
From: gward@python.net (Greg Ward)
Date: Sun, 12 Mar 2000 22:13:46 -0500
Subject: [Distutils] patch for build_ext and a suggestion
In-Reply-To: <Pine.LNX.4.21.0003121345590.32213-100000@void.cs.uni-sb.de>; from Bastian Kleineidam on Sun, Mar 12, 2000 at 01:50:02PM +0100
References: <Pine.LNX.4.21.0003121345590.32213-100000@void.cs.uni-sb.de>
Message-ID: <20000312221346.A542@beelzebub>

On 12 March 2000, Bastian Kleineidam said:
> I have a patch for distutils-20000204.tar.gz.

The code has changed a lot in the last month.  I've just changed the
Distutils "Implementation status" web page to discourage people from
using the Feb 4 snapshot:

    Update! (Mar 12, 2000) No new code snapshot is available, but the
    code ha changed a lot since the last one (Feb 4). If you want to
    keep on top of changes since 0.1.3, and especially if you want to
    contribute patches, please follow the CVS tree.

So, if you're interested in following the code, you're better off
following the CVS tree.  If you want to submit a patch, *please* follow
the CVS tree and make the patch relative to a fairly recent update.
Thanks.

Oh yeah: please *always* submit either context (diff -c) or unified
(diff -u) diffs.  Absolute diffs are obsolete as soon as I add or remove
one line from the file.

> patch for command/build_ext.py:
> 1. use correct name 'libs' instead of 'libraries' in build_ext options

Hmmm, I'm not sure which is correct here -- I've been inconsistent,
using "libs" as the command option and "libraries" as the build info
dictionary key.  I prefer "libraries" myself, so I'll probably fix it
that way.  Thanks for spotting this.

> 2. adjust a String argument in BuildExt.libs to a list

Good catch -- and I think your analysis of this error is pretty good.

> So there are two restrictions for options:
> 1) An option is allowed only once and 
> 2) an option value type has to be a string.
> Both restrictions are not necessary. What I want to have is that if I 
> supply mulitple --libs options, each option value gets added to a list.

Right, I made a definite choice that fancy_getopt would *not* be an
all-singing, all-dancing Python command-line parser with typed,
aggregate options and careful type-checking.  Every time I set about
writing one of those, it takes ages to get it right and I go way
overboard.  (IOW, I've never met a type system I didn't like so much
that I immediately set about reinventing it; so far, I've managed to
restrain myself from reinventing Python's type system in the Distutils.)

> Here is the code snippet from fancy_getopt.py thats responsible:
>         attr = attr_name[opt]
>         if takes_arg[opt]:
>             setattr (object, attr, val)
> 
> Solution: instead of setattr, you should call the "set_option" function
> of the object with "val" as argument.
> So in the example above, this is
>         attr = attr_name[opt]
>         if takes_arg[opt]:
>             object.set_option(attr, val)

Interesting idea.  It sort of violates one of the design principles
behind fancy_getopt, which was that you could pass in *any* object
(well, any object that setattr works on, namely any class instance), not 
just Distutils command objects.

However, the more I think about it, the more I think your proposal just
bends the rules rather than breaking them.  First, we could say, "call
set_option if the object has it, otherwise setattr".  Second, we
document the use of set_option, and make this the way to impose a type
system on the Distutils command line.

I like this.  That leaves decisions about how strongly to type, whether
to support aggregate types, etc. etc. up to the application that uses
fancy_getopt (Distutils in this case) -- and lets fancy_getopt stay
relatively simple, as it currently is.

I think the right way to do this would be something like this:

  * tweak fancy_getopt to use 'set_option()' if it's there, setattr
    otherwise
  * add some type annotations to each command class' 'user_options'
    dictionary (eg. a fourth element of each tuple)
  * tweak fancy_getopt so it doesn't barf on those type annotations
    -- it might already accept > 3 element tuples, so this might
    not be necessary
  * change the 'set_option' method provided by Command (the base class)
    to pay attention to these type annotations

If you're interested in hacking on this, be my guest: sounds like a
useful addition.  But please do it on the current CVS tree!

Thanks!

        Greg
-- 
Greg Ward - Unix bigot                                  gward@python.net
http://starship.python.net/~gward/
No man is an island, but some of us are long peninsulas.


From calvin@cs.uni-sb.de  Mon Mar 13 13:05:08 2000
From: calvin@cs.uni-sb.de (Bastian Kleineidam)
Date: Mon, 13 Mar 2000 14:05:08 +0100 (CET)
Subject: [Distutils] Re: suggestion
In-Reply-To: <20000312221346.A542@beelzebub>
Message-ID: <Pine.LNX.4.21.0003131316130.4335-100000@void.cs.uni-sb.de>

Hi, some further additions from me:
:) > So there are two restrictions for options:
:) > 1) An option is allowed only once and 
:) > 2) an option value type has to be a string.
:) > Both restrictions are not necessary. What I want to have is that if I 
:) > supply mulitple --libs options, each option value gets added to a list.
I discovered the Command.finalize_options() function. There is implemented
a way to supply a list of values, separated by os.pathsep.
        if type (self.include_dirs) is StringType:
            self.include_dirs = string.split (self.include_dirs,
                                              os.pathsep)

So you could type
"python setup.py build_ext -I/usr/include:/usr/local/include"
Well, its not beautiful (espacially because os.pathsep has different
values on different platforms), but it works.

:) If you're interested in hacking on this, be my guest: sounds like a
:) useful addition.  But please do it on the current CVS tree!
I try to get distutils to work for my project. With the above
os.pathsep thingy, the extension of the fancy_getopt module is not the
most important thing for me right now.

What I need more and try to implement are "clean" and 
"uninstall" commands. The clean command was discussed before as I see from
the mailing list archives. The most easy way seems to be to "rm -rf" the
build/ directory.
The "uninstall" command is a bit more difficult. The Perl guys (and
girls) seem to write an uninstall script for each install command.

If you have any ideas to these two commands, let me know them.

Bastian Kleineidam



From gward@python.net  Wed Mar 15 03:56:26 2000
From: gward@python.net (Greg Ward)
Date: Tue, 14 Mar 2000 22:56:26 -0500
Subject: [Distutils] Re: Distutil patch: clean command
In-Reply-To: <Pine.LNX.4.21.0003132120280.6014-200000@void.cs.uni-sb.de>; from Bastian Kleineidam on Mon, Mar 13, 2000 at 09:24:13PM +0100
References: <Pine.LNX.4.21.0003132120280.6014-200000@void.cs.uni-sb.de>
Message-ID: <20000314225626.G460@beelzebub>

[cc'd to the distutils-sig, since this deserves a public airing]

On 13 March 2000, Bastian Kleineidam said:
> this patch is against the CVS version of March 13th.
> It implements a "clean" command which cleans everything
> generated with the "build" and "sdist" commands.

Useful addition, and definitely something I've been putting off.
However, there's no need to clean up after "sdist", since it
automatically does so itself!  (You can tell it not to with the
"--keep-tree" option.)  If "sdist" is *not* cleaning up after itself on
some platform, that's a bug.  (See the last statement of
'make_distribution()' in the "sdist" command class.)

> Additionally, I implemented the sdist option --list-only.

Procedural point: in future, please try to submit distinct changes like
this as separate patches.  I might like one change right away, but send
another back for revisions.  Bundling them together makes this hard.

As it happens, your "clean" command has a few problems, and I don't see
the point of the --list-only option.  (Partly my fault: I probably
should have taken it out when I revamped the "dist" command and turned
it into "sdist" -- I'm pretty sure it's vestigial.)

> + class clean(Command):
> + 
> +     # Hmm, split this up into clean_py,clean_ext,clean_clib,clean_sdist?
> +     # Or just clean_build,clean_sdist?

Good gravy!  No need to go overboard here; cleaning is simple enough
that it can be handled by one command.

> +     description = "clean everything we built"
> +     user_options = [
> +         ('build-base=', 'b',
> +          "base directory for build library"),
> +         ]
> + 
> +     def initialize_options(self):
> +         self.build_base = 'build'

No: 'initialize_options()' should almost always initialize everything to
None; otherwise, we have no way of knowing if the user supplied a value
when we get to 'finalize_options()'.

> +     def finalize_options(self):
> +         self.base_dir = self.distribution.name or "UNKNOWN"
> +         if self.distribution.version:
> +             self.base_dir = self.base_dir+"-"+self.distribution.version

Not necessary, since "sdist" cleans up after itself.  And it's *very*
naughty to generate a filename or directory name that's generated by
another command; if "sdist" doesn't provide a way to get that
information, add it (eg. a 'get_release_tree()' method).  But it's not
needed anyways.

But you do need to select a final value for 'build_base', and it should
come from the "build" command's 'build_base'.  Canonically:

    self.set_undefined_options ('build',
                                ('build_base', 'build_base'))

> +     def run(self):
> +         # remove the build directory
> +         self._nuke_tree(self.build_base)

Oh wait, there are two kinds of things I might want to clean in the
build base: temporary build by-products (foo.o, libbar.a, etc. -- all in
build/temp.<plat>) and the real products of the build (in build/lib or
build/platlib).  This probably should be a user option to the clean
command.  I'm not sure what the default should be: clean everything with
"--temp-only" option, or clean temp only with an "--all" option.  The
latter is safer and less typing in the "exceptional" case.

> +     def _nuke_tree(self, directory):
> +         try:
> +             self.execute (shutil.rmtree, (directory,),
> +                           "removing "+directory)
> +         except (IOError, OSError), exc:
> +             if exc.filename:
> +                 msg = "error removing %s: %s (%s)" % \
> +                        (directory, exc.strerror, exc.filename)
> +             else:
> +                 msg = "error removing %s: %s" % (directory, exc.strerror)
> +             self.warn (msg)

This looks suspiciously as though it was cut 'n pasted from the
'nuke_release_tree()' method in "sdist".  I hereby ban reuse by cut 'n
paste.  Since "nuke a directory tree" is now needed in two places, it
should be factored out into a convenience function in util.py.  (And it
should take 'verbose' and 'dry_run' flags... just follow the
well-established pattern.)

I'll happily accept a second patch!  Just keep it distinct from any
other hacks.

Now the "sdist" business...

Why is the "--list-only" option needed?  I'm pretty sure it should be
dropped, because you can achieve everything it provided (and more) with
the new "sdist" command.  Eg:

   setup.py sdist --manifest-only

generates MANIFEST from MANIFEST.in, giving you the list of files that
will be distributed.  It even tells you what's going on as it processes
the MANIFEST.in file; right now this is debugging output, but I'm
starting to think it should be preserved.  It's handy!

   setup.py -n sdist --manifest-only

This does the same, only it doesn't create MANIFEST -- just tells you
what it would have done while processing MANIFEST.in.

    setup.py -n sdist

And this tells you what "sdist" would have done in creating a
distributable archive (tarball or zip or whatever).

Is anything else needed?  Does your patch (which I haven't read closely) 
provide anything extra that's not handled by these options?

        Greg
-- 
Greg Ward - "always the quiet one"                      gward@python.net
http://starship.python.net/~gward/
Think honk if you're a telepath.


From colbert@stsci.edu  Wed Mar 15 19:10:55 2000
From: colbert@stsci.edu (Edward Colbert)
Date: Wed, 15 Mar 2000 14:10:55 -0500 (EST)
Subject: [Distutils] Distutil installation tricks
Message-ID: <200003151910.OAA19945@grail.stsci.edu>

Hi,  

I have questions rather than answers:  

We would like to use Distutils
for installation of our Python front end to IRAF (an astronomical data
reduction program).  Our front end is called PyRAF.  Upon reading the Distutil
documentation, I can figure out how to do a basic installation but there
are some files that do not seem to install easily with the current version
of Distutil (or I am missing something).

First, we need to install several data files and scripts.  One is named 
"pyraf" and is a python script.  Another is a database file called 
pyraf.Database, which is created specifically for each platform by executing a 
python script mkpyraf.Database.py.  Some other data files need to be copied
directly.

Lastly, we have three modules written in C that need to be compiled plus
a C library package that also needs to be compiled.  I can set up the include
directories and library directories for each platform, but we would like to
have a platform-independent script that probes the platform type and checks
to see where the include and library files are located and then assigns the
include and library directories before the compile and link.

Is there any way to do these things with the current Distutil without 
essentially writing my own python scripts.  I have seen some discussion about
adding provisions for scripts and data files.  What is the consensus on that?

We want to have a working installation procedure by April 15th.

I subscribe to the list, so any response to the list would be fine.

Thanks a lot,
Ed Colbert


From vanandel@ucar.edu  Wed Mar 15 20:14:01 2000
From: vanandel@ucar.edu (Joe Van Andel)
Date: Wed, 15 Mar 2000 13:14:01 -0700
Subject: [Distutils] rpath broken
Message-ID: <38CFEF09.76395E03@atd.ucar.edu>

I grabbed the latest CVS version of distutils, as of 3/15/2000.

I'm building C Python extensions under Solaris and Linux.  Under
Solaris, I need to specify the
'-R' options.  'rpath' is documented to do this, but doesn't have any
affect.

In ccompiler.py, I notice the _fix_link_args() routine manipulates
libraries and library_dirs, but doesn't use rpath.

I suspect _fix_link_args() is part of what needs to be fixed.

Anyone else using 'rpath'?



-- 
Joe VanAndel  	          
National Center for Atmospheric Research
http://www.atd.ucar.edu/~vanandel/
Internet: vanandel@ucar.edu


From calvin@cs.uni-sb.de  Thu Mar 16 00:38:01 2000
From: calvin@cs.uni-sb.de (Bastian Kleineidam)
Date: Thu, 16 Mar 2000 01:38:01 +0100 (CET)
Subject: [Distutils] patch: clean command
Message-ID: <Pine.LNX.4.21.0003160130230.16423-101000@void.cs.uni-sb.de>

  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.

--1619424764-1944824378-953167081=:16423
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hello.

Second try, this time only the clean command with suggestions from Greg.
Options for 'clean' command:
  --build-base (-b)  base directory for build library
  --build-lib        build directory for all distribution (defaults to
                     either build-purelib or build-platlib
  --build-temp (-t)  temporary build directory
  --all (-a)         clean all files, not only temporary files

I refactored the sdist.nuke_release_tree() function into
util.remove_tree(directory, verbose=0, dry_run=0).

Bastian

--1619424764-1944824378-953167081=:16423
Content-Type: APPLICATION/octet-stream; name="clean.diff.gz"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.21.0003160138010.16423@void.cs.uni-sb.de>
Content-Description: clean.diff.gz
Content-Disposition: attachment; filename="clean.diff.gz"

H4sICNwq0DgCA2NsZWFuLmRpZmYAtVfhbts2EP7dPMVFbWE7lhzJjuNEmAcU
XVpkwFJgSYAC22DIFmUTlSWBpNK4T787UpJlW3bcdRWUwDzeHb87Hu+jQh5F
4AhwZuA47HkW5yEbn/WyFY7vIORS5YrHspcKPj+vhuezdLkMkvB8FrMgQe2a
phYdUD05Ozs73vGrh0UOvwcJgAeu57suvuBdj9wTx3G+Y1Xt549AgHdJfvqu
3/eg77ouwak/Gp4L+ict4dkXA0yN45x0wbKs2opmBbMyTuJ7u8xitmSJkqAW
DH4rdaGllVpQ2hj19yQsZRICgSbv7j7e/Pnp8R7uHx4/fOjBfQphmiiYxsGS
Ab48Qt9covkXHqPrVZoLCAMVnBqAxjVfZqlQIBe0vj2P06mdkk0k0mU9aymu
Wei+Nzh2lMp5GhjnsziQEnRI7cKq45spekImZ4JniqcJjMHSehDxmEn4ymCa
81hZhWoumZikWlWi7l+FmJ52izRDZxpINm7Z0JriP4tGCE2wmUrFCqJUaIch
xHwqArGyOnaDD5wkF3dpwurT6E7bbvoL4lgHL/g01zG0QxYFeUybmgLjuLMC
LOjuOnKyXDBcC0pUThYHCgXNqBRbZjoyRZHRKKUQYAvUtjHiI6OgZRepJcA6
vTYkqYI0iVew9qZnrE7h4p/6NkXAE654EPNvrNyFtmRxpHezfEjQ05gmOvtj
ncdmBQr+0DzB2qNAUVQzNYgRT44BKJma5Aka8ISFla7JdIsS+KqWeh2Irqn1
qLOjhMGsdWiwq0LxrHX0qNPZxC/yZBfyaxBsmT4x3Sa08TkZ936hgvl1vfc1
k0xwbAOWtuPJ3LK30lpTpZPaMwtMlGCsvaVqm5Q9MTFNJStGoVhNEGun5gdb
Tbk1dfB7AqC9F0xmvWJc1H5jMC+hRLvDIMMfoy1JouNoq1Q9jrZK7YpuoA9u
37+49i+Ghm6Oo60dPwVtXfmDwX7a8lzbuzLUBWXbjpJloGYLFOi2rlYZq1r6
WSklgiiF9PvEMXLDH+WMWNI+lTaHWeR0W6nuKGFfmdj1o9izmlC/KvUeUPAB
x7uqTIhUVHFURHvzzGY3NIUWhr0xIyND3z+Ykf8partW8T89A001MnQv7GG/
X1aJOczL4AubIHcx7IQaGrQ75ICyWHWyJN9RokNpA/XPCR5zbHFOdbyVWNWH
VaNmCDBXaGuqyYZ2aW5jf9002Hyq3gdvpQVv18vWrLAVsExB+/aTToINn+71
j45NU9uAsMGhtEcJT/B65Tcsv5RzusTobEMNgI9/0H4rO4Tk7/2419HppfBa
wQyw+sKdLXsWy+8GQzj2LNZp2oevgcCrDXqkWXqh2mhdDSoQU+LkrT226b6a
YZ+XY2v+jWcWbjqUxqaYPn/+DB/vHkFR2+p5A1gEeLmFhEdqBYaZ6SYVhCFK
0VXEn9ck0dPHdugO7KF7ZQ5uUxVfup596Y7qVbwToQ4DIerz1F5XywZcLAG6
NGmDL4xlurB9PMg77hrKf8vn6+JmTIexbEDDq5E9vB6ULegnA63TabVjGzy6
SaONsP8jt2o+P0iphcZhJi2UXj3kzBDoCNwLf3DhIwMeQaCV+QZven3fvTzA
mx6xRFFL+E5wn5+4xEKdTOjAvbkNfSg8209U1MbZuTs4xyJ0BwW+OR6qEG6e
M3hjkafTsj2neDenL4pk/lIjPyvbLpGXVyOvnwvLLqj+WHhNWRyMRvbgqr/+
dNaC63oEWGpptqozTBdl9D1blC42igTwAxrbQe2zTJNl11ynaxVeKdhQlPfY
taEo7rFb3bjx6BTz/qEL9dodCme5kPyJxStr7aTwXHcimMpFUgg05dW+Sxbm
irvcAuuVd+yXyGrjJt4QQSOFdXd6TBHoSxTW3UthtTwf4rBuA4d9HxrNYXtW
q5oV0cstyFxmqGZqB9/HhD87JOIRp76Fty0WAtUsuV+wODs9KdiN6se0Wilm
WC9S2Sf/Aso9TWEHEwAA
--1619424764-1944824378-953167081=:16423--


From gward@python.net  Thu Mar 16 03:09:21 2000
From: gward@python.net (Greg Ward)
Date: Wed, 15 Mar 2000 22:09:21 -0500
Subject: [Distutils] Distutil installation tricks
In-Reply-To: <200003151910.OAA19945@grail.stsci.edu>; from Edward Colbert on Wed, Mar 15, 2000 at 02:10:55PM -0500
References: <200003151910.OAA19945@grail.stsci.edu>
Message-ID: <20000315220921.A495@beelzebub>

On 15 March 2000, Edward Colbert said:
> We would like to use Distutils for installation of our Python front
> end to IRAF (an astronomical data reduction program).  Our front end
> is called PyRAF.  Upon reading the Distutil documentation, I can
> figure out how to do a basic installation but there are some files
> that do not seem to install easily with the current version of
> Distutil (or I am missing something).

OK, you get bonus points (danger pay?) for wading through USAGE.txt.
Well done!  Better documentation coming Real Soon Now (TM).

> First, we need to install several data files and scripts.  One is named 
> "pyraf" and is a python script.  Another is a database file called 
> pyraf.Database, which is created specifically for each platform by executing a 
> python script mkpyraf.Database.py.  Some other data files need to be copied
> directly.

Installing scripts is an obvious problem with an obvious solution that
will be implemented Real Soon Now (TM).  Data files are a bit more
interesting, and you're the second person to mention having to install
data files with the Distutils lately -- so I guess it's a real issue.

So where the heck should they go?  The GNU Coding Standards recommend
that the directory be called "datadir" (in the Makefile and configure
script) and that "datadir" normally map to "$prefix/share",
ie. "/usr/local/share".  OK, this can be adapted to the Distutils way of
thinking about installation easily enough, and on Unix it'll follow the
GNU standards.  No problem.

But what about Windows and Mac OS?  Granted, most people won't be
running "setup.py install" -- that's only for people building from
source, who will be a small minority on those user-friendly,
compiler-challenged platforms.  But someone still has to create the
binary distribution, which will decided where data files should go.  So
I guess it doesn't matter that most people won't use the "install"
command directly; whoever puts together the binary dist. will use it (or 
something like it) on their behalf, so whatever the "install" command
does will propagate out to the rest of the world.

So how *should* Python module distributions be installed on Windows and
Mac OS?  OK, modules go right in $prefix (eg. "C:\Program Files\Python"
for a typical Python Windows installation) -- but what about scripts,
data files, documentation, or whatever else we might end up installing?
Should each module distribution get its own directory under $prefix?
Other ideas?  Perhaps I should wait for feedback until I've written up
the Unix installation scheme, but if anyone has firm ideas now, I'd like
to hear 'em.

> Lastly, we have three modules written in C that need to be compiled plus
> a C library package that also needs to be compiled.  I can set up the include
> directories and library directories for each platform, but we would like to
> have a platform-independent script that probes the platform type and checks
> to see where the include and library files are located and then assigns the
> include and library directories before the compile and link.

Building C libraries and extensions is handled.  *Installing* C
libraries is not, just because I didn't think it necessary -- that
wouldn't be too hard to change, but let me know if you think it *is*
generally necessary.

Probing the system to figure out what needs doing is *not* handled, and
will not be handled in Distutils 1.0 unless someone out there gets
ambitious and rewrites Autoconf in Python.  (I have assumed all along,
and repeatedly stated publicly, that I don't think there's any other way
to do it.  I'm still waiting for someone to contradict me and say, "No
no!  You're missing this simple, obvious trick that will make it all
*easy*!".)

The approach currently taken is to require users to *cough* edit the
setup script.  Just like the good ol' days before autoconf, when we all
edited Makefiles without really understanding what we were
doing... (well, *I* didn't understand what I was doing).  Distutils 1.0
will have some sort of config file mechanism; hopefully it will be
powerful enough that users will just have to edit a config file rather
than the setup script.

> We want to have a working installation procedure by April 15th.

Then I should stop dealing with this damn mailing list and go write some 
code!

        Greg
-- 
Greg Ward - Unix weenie                                 gward@python.net
http://starship.python.net/~gward/
I'd like some JUNK FOOD ... and then I want to be ALONE --


From aa8vb@yahoo.com  Fri Mar 17 14:50:33 2000
From: aa8vb@yahoo.com (Randall Hopper)
Date: Fri, 17 Mar 2000 09:50:33 -0500
Subject: [Distutils] Re: rpath broken
In-Reply-To: <38CFEF09.76395E03@atd.ucar.edu>
References: <38CFEF09.76395E03@atd.ucar.edu>
Message-ID: <20000317095033.B1061993@vislab.epa.gov>

Joe Van Andel:
 |I grabbed the latest CVS version of distutils, as of 3/15/2000.
 |
 |I'm building C Python extensions under Solaris and Linux.  Under Solaris,
 |I need to specify the '-R' options.  'rpath' is documented to do this,
 |but doesn't have any affect.
 |
 |In ccompiler.py, I notice the _fix_link_args() routine manipulates
 |libraries and library_dirs, but doesn't use rpath.
 |
 |I suspect _fix_link_args() is part of what needs to be fixed.

Just wanted to pitch in that we need this for IRIX and FreeBSD as well:

        - Solaris  -   -R
        - IRIX     -   -rpath
        - FreeBSD  -   -rpath

Randall



From gward@python.net  Sat Mar 18 15:26:48 2000
From: gward@python.net (gward@python.net)
Date: Sat, 18 Mar 2000 10:26:48 -0500
Subject: [Distutils] rpath broken
In-Reply-To: <38CFEF09.76395E03@atd.ucar.edu>; from Joe Van Andel on Wed, Mar 15, 2000 at 01:14:01PM -0700
References: <38CFEF09.76395E03@atd.ucar.edu>
Message-ID: <20000318102648.A531@beelzebub>

On 15 March 2000, Joe Van Andel said:
> I'm building C Python extensions under Solaris and Linux.  Under
> Solaris, I need to specify the
> '-R' options.  'rpath' is documented to do this, but doesn't have any
> affect.

Oops, thanks for spotting that!  That feature was only partially
implemented.

> In ccompiler.py, I notice the _fix_link_args() routine manipulates
> libraries and library_dirs, but doesn't use rpath.

Sorta.  It's really the job of 'gen_lib_options()', in ccompiler.py, and
the methods in unixccompiler and msvccompiler that call it.  Anyways,
I've fixed it and checked the change it.  Not tested though -- please
try again with the latest CVS version and let me know how it works.

BTW, Joe, you keep finding nice juicy bugs in the Distutils.  Could I
get my hands on your extensions and setup script?  The setup script
might be a nice example to distribute with the Distutils, and the whole
package would definitely be another good test case for me.

        Greg
-- 
Greg Ward - Unix weenie                                 gward@python.net
http://starship.python.net/~gward/
I always have fun because I'm out of my mind!!!


From gward@python.net  Sat Mar 18 15:44:30 2000
From: gward@python.net (gward@python.net)
Date: Sat, 18 Mar 2000 10:44:30 -0500
Subject: [Distutils] patch: clean command
In-Reply-To: <Pine.LNX.4.21.0003160130230.16423-101000@void.cs.uni-sb.de>; from Bastian Kleineidam on Thu, Mar 16, 2000 at 01:38:01AM +0100
References: <Pine.LNX.4.21.0003160130230.16423-101000@void.cs.uni-sb.de>
Message-ID: <20000318104430.B531@beelzebub>

On 16 March 2000, Bastian Kleineidam said:
> Second try, this time only the clean command with suggestions from Greg.
> Options for 'clean' command:

Great, thanks!  I've just applied your patch and checked it in.  Maybe
now I'll go test it a bit.  ;-)

        Greg
-- 
Greg Ward - deranged madman                             gward@python.net
http://starship.python.net/~gward/
Money is a powerful aphrodisiac.  But flowers work almost as well.


From calvin@cs.uni-sb.de  Sun Mar 19 15:44:44 2000
From: calvin@cs.uni-sb.de (Bastian Kleineidam)
Date: Sun, 19 Mar 2000 16:44:44 +0100 (CET)
Subject: [Distutils] an uninstall option patch
Message-ID: <Pine.LNX.4.21.0003191642200.13430-101000@void.cs.uni-sb.de>

  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.

--1619424764-551395528-953480684=:13430
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hello,

I have implemented an uninstall option. If you specify -c or
--create-uninstall to the install command, an uninstall script named
<package name>_uninstall.py will be built and it will be installed in 
install-lib resp. install-platlib. 
To uninstall your package, execute this script with python.

Note that the uninstall option requires you to supply a package name
in setup.py.

The patch is against the latest CVS snapshot.

Bastian Kleineidam

--1619424764-551395528-953480684=:13430
Content-Type: APPLICATION/octet-stream; name="uninstall-patch.gz"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.21.0003191644440.13430@void.cs.uni-sb.de>
Content-Description: uninstall-patch.gz
Content-Disposition: attachment; filename="uninstall-patch.gz"

H4sIAE3v1DgCA+1a62/juBH/vPkrJgoCW4ns+Jk4vqYFur0P+6HdAnsoFlgs
BFmiYl5kUaWkOG5x//vNkHpQspw4tynugRpBEovD4bw48xtSH+NoBzyGgKdZ
nvEoHeYxj9PMi6Kr6tkShme+kGyY7Ibj4WRyEvAwhIH0YTBgT36UBwwucND8
/v5fnwymQvL7mt+VLzYbLw6uipVw6vMCdEw4ubi4eM0C735Y5/B3TwJMYDRZ
zm6XszlMRqPRyWAwePXq7z7lseI2voXx9ZJ+Cm4XzY8SczxxxjegvtJi+HVy
i6YaDE4AQik25vL4G/gmETKDreQZc0MesX06JqWQaUn5t/L5xyTjIv6eBnHO
ySW4lT5uxjZJ5GUM7sCyrLPTqzyVVyseX7H4EZJdthYxTjiDbM1ToFUB/96z
mEmcFGgBsjWrhYBewboHhYVwPv7Q3AiJcKHzVD/iIbhu7G2Y68LdHfRcd+Px
2HV7SxykT6GISIvvoZAQUmCWzIYPbJf27ZKePonkcQaWZBvxyON7ywmNQZEO
1QDrhzY+Ro1JEgA/8lK0mxYc+u+14MgXaJQ+AUt9yZUhyVQlKXtkEo2EC2lT
rHIeBWgMyfxMyJ3V6fnJwplOa8/PRs7suvR89bHILajwZpAmzOch9+Gfyh0Q
8ZX05M5YxXaMmf3SAYPEy9Z3PQf+IWLmNHizp0x6qG/G5COLSfqSGWcpZAKS
PIMVi8S2NMoAV6V1Lo11fMkwCAZVMOFSPV/9UgOAJqxsWhGBtmNPyWwIdQZ/
bdgOBVnCds0kI3lCjrwozsjzSsKCXUNxZf3ByktZrXaXA25Gzs28dsBi6ixu
2w5IWRQOy12C0YBeJ4aHKNbZJnqBhMehKEkumyTaYPW2rDm1meGeStAELibH
Oxi3RwUG6Ib/pxrujL7Z3JnMR7X6k/mtM7muItDgiRtUsaVAUilnaUZRS/iK
CPq2oV/Jo62iuWcP2kHxQ3aVVGcgMcfqJ53KXY9QF8O3k5trZzqZdXqXPTE/
xzjt1znVaSloRBcNU7Jy4EsxG/eQi+GafrUPT7OUSrTDzlMLzqHkYusUqFNL
CN2K0zqN5IYJ6325t4wtpaz+J0rBkq9ylaNojT/X/KhIG3x+KDJ2gxw2eUq7
Hu45JoVTg/xDSHtPqtzvRShAsNsXwIEtihUEOLKDmG2Lrbo1g72gx8JBOzhr
iCRqfg6kmPoRg5Qeop3fUnfLs3VRoIZNCxnfzsBfM/9BFY49fZtBGotMR4VJ
NyS6dqRKj6ess7o6YO1Eru2Y5glp4O2v2xJQoFYy9zOlJG2iVCXOMlDSjr3U
EBHj0N2IIEdjtyWlTIh5oJGFqKxgLjcoWZSyY2Y2Z+klVdzcHTDcpVUHoKl0
qRpOrLlcWhijJlVR/F2XsnpGuMAY9A0e1b+X0Deoh64bsFV+j+CC7Gn5FmAU
WMKyG/aniG2Gly5QGJ6kFQWqyDMVy+2s3VC4JBp6ScLioI9Qg5w5/FHwuE/m
dOq9b38rJ7/BykQ/SIgmeW5x04qHyf0u+mKblOTsCcVO+/S/3Q4gA+7996cX
gg3Zqngj3gju0p3m3yZT1irGKCiZzPojR021W6SUN8BSiOy8wsOlSJSG67gz
47KEl4d90pbpjOIDuW54TFk5yJOI+/gf5T3IUSfa/z6xQMR2wERfwq+qWBuC
kE/Q98q0mFS2jZgNh6pe9btQ/HnFtTnDj0TK+s3IX+0QvBV4Qm0BHfjmPDJg
snNLosKQxdd2EG+8B1YAAC23X/zR5E7xuAEi98qlIVRdNNW8I2d5Ks+KkByf
PnDcQkHJosARJyrtKsT/oQCRb9y6upiTX92+FpNe1cIWc96wjS05NlvZ0c1y
PDrcyk4miLE05jK3RsR0UdvrCNWeoHAVuSwxgfZb1dMcAtFIcABmK/DfHK96
t5AaCC8iZCxUuU6hBFctLinLcF/hDB6zoCauVDiM9FpwUTcjZbmlrqgSkHqf
0yO5tMo28TFM0bPtppoKHVeaaQSMztnDv7+6c17bAP2RfUic3uHH7KrdZlfd
fvaC37s26XThzKb7m7TP7odgqWOfSPhedIUSXmlcPR7Or1KsNIPE8x+8e5Za
9hDQLwqQe1mDTZJnqsvRoB9rKMUW5q51BsVsCh+zgQjQv9Tgx9QimKyUjYeG
dcviWwJNX2BNyiRjWuU6uJy9cLQ78/33T1l58jLv2Bq/A5Mc6qoV1K1aGQQ0
PqKt0zZkySVWyNigIRSDsMVfA/FIJHvkIk+Ndk3j3yYjEQV68p3BqUVjLEEQ
p8XgW/zaVkqyFFMTq4Uv9v1zApUaGDQan/5P5DyMKjs7qGrwsm5ADgXzW+OX
ZPd6+KLmvA69qClvCV40wxZ2WSxn42ewy4zO3evzopkzHXWeFnXgi66TueeO
5Vow/00qX3eunzrTRa3UdObMupV661LZVSbhlWWyu0ReHsnluPJ5vFT1gavi
pL+9hoFxJkscyq9FCe/y3mzuzMf7lfrD3p3DsjwnC/JNosoLizMEaXSolOG/
KfVB9Fj5o8GswnKU+omkG+lBn8paL9VcmJdnO+TZ4LT26J4FG93W3cep/XYl
vOPTrNj6EA5n7Oyy3wRKYagc5cEG8efPn2HNdqfUovte3MuUuaSIqPTSOScN
VFtWSKqn30FhhzzRyOHGuR7tI4ffs4v+Dyl+ZaTwGwvzrsw0nznXizIzdVwU
FTK1r4leOEdqsGocxNXHbvu9ltZQa4ZwKN+w+pJaX2d4SYJhfwr9LSqFMnYy
2bIe7kbsn9Q1KNVCCZYG+zD4aP3F3hdPTxT0koR5fKZvx1HuTGF6P8vJUbjr
yEPFhX37g+Thl8F0+VVdgCNhb3mgrURTuCHdQhJEjO+HkmE7ibHZDx09Uf/x
e/YBBgcKVvvoDtnppcyDu9A5uuB1n+CFv2T6gaO80FYp+Hrq3CyeubT8ZbHY
Opnev4P4lmDVOxERXcbkBhEXybpVwQdVxMFqB5EQD2i7Tj5eQ5z6ksPB5J6V
K1C69tdejC0mz35rARwef1FzkFPzgkRxtv9IAX7MWwsjZ3G9D0Eozvh9TK1w
s/cIVYrf0t1qjHkDIyUQlDux3JOXH2J62aOJG3RurFVVvBS1LheOcpgv8igg
Tgn3H0DlWqxHgWiwQkQUF+Ee8ECtNgT4btA/6irsdQ1y+0WBb++O1VtuL/ai
iuqlDlgRvfuERlIt6gI70+V4sZyPju95CxZGlztfTubL+c0zL5vd3Drjxcx4
3Uw9mHc2hbk89CpLxH0WK0DUNdp8R6rrmNfw55ev7fd/ev4mUCcbPSrdaXUe
rW7BFZxUxx5i9SOi1xTjWLSPySj1jW34d46BGFHKus8lnWNjXlxzRKKaQfny
EOJwOuam87aTnwERNktF8igAAA==
--1619424764-551395528-953480684=:13430--


From calvin@cs.uni-sb.de  Mon Mar 20 15:10:46 2000
From: calvin@cs.uni-sb.de (Bastian Kleineidam)
Date: Mon, 20 Mar 2000 16:10:46 +0100 (CET)
Subject: [Distutils] What is the license of Distutils?
Message-ID: <Pine.LNX.4.21.0003201604330.18391-100000@void.cs.uni-sb.de>

Hello,

can I redistribute a (modified) distutils package? What files do I have to
include besides the .py sources? Or better asked, what files _should_ I
include?

Bastian Kleineidam



From calvin@cs.uni-sb.de  Tue Mar 21 00:10:36 2000
From: calvin@cs.uni-sb.de (Bastian Kleineidam)
Date: Tue, 21 Mar 2000 01:10:36 +0100 (CET)
Subject: [Distutils] Two little bugs
Message-ID: <Pine.LNX.4.21.0003210108420.1258-100000@void.cs.uni-sb.de>

There are two little bugs in the current CVS snapshot:

util.py: import sys because its used in get_platform()
spawn.py: _nt_quote_args() misses the return statement

Greetings, Bastian Kleineidam



From hoel@germanlloyd.org  Tue Mar 21 13:18:09 2000
From: hoel@germanlloyd.org (Berthold Hoellmann)
Date: Tue, 21 Mar 2000 14:18:09 +0100
Subject: [Distutils] additional Flags for build_ext
Message-ID: <38D77691.329DD519@GermanLloyd.org>

Hello,

I think it would be extremly helpfull for developing Python Extensions
to be ditributed using Distutils to have an option "--additional-flags"
where I could give addional flags for the C compiler, e.g. to ask for
specific compiling or optimization flags. What do you think about it?

Greetings

Berthold
-- 
email: hoel@GermanLloyd.org
   )
  (
C[_]  These opinions might be mine, but never those of my employer.


From gward@python.net  Wed Mar 22 01:14:58 2000
From: gward@python.net (Greg Ward)
Date: Tue, 21 Mar 2000 20:14:58 -0500
Subject: [Distutils] Installation: new code, new docs
Message-ID: <20000321201458.A575@beelzebub>

Hi all --

I've just checked in a bunch of changes to the 'install' command, the
net effect of which is that it now WORKS.  (In case you hadn't been
paying attention, I checked in a version several weeks ago that was only
half-finished and has since been abandoned.)

If you're interested in playing around: first, read the docs, which are
also a complete rewrite.  This is the nucleus of the "Installing Python
Modules" manual; so far, it only covers "alternate" and "custom"
installation.  ("Standard" installation is pretty obvious, and anyone
reading this sig should know what that means... does need to be
documented, though!)

Documentation is at

    http://www.python.org/sigs/distutils-sig/documentation.html

Code is in the CVS tree of course, and I've just put out a new snapshot
to celebrate the occasion:

    http://www.python.org/sigs/distutils-sig/implementation.html

Enjoy!

        Greg
-- 
Greg Ward - Linux geek                                  gward@python.net
http://starship.python.net/~gward/
I am NOT a nut....


From gward@python.net  Wed Mar 22 01:23:04 2000
From: gward@python.net (Greg Ward)
Date: Tue, 21 Mar 2000 20:23:04 -0500
Subject: [Distutils] Two little bugs
In-Reply-To: <Pine.LNX.4.21.0003210108420.1258-100000@void.cs.uni-sb.de>; from Bastian Kleineidam on Tue, Mar 21, 2000 at 01:10:36AM +0100
References: <Pine.LNX.4.21.0003210108420.1258-100000@void.cs.uni-sb.de>
Message-ID: <20000321202304.B600@beelzebub>

On 21 March 2000, Bastian Kleineidam said:
> There are two little bugs in the current CVS snapshot:
> 
> util.py: import sys because its used in get_platform()
> spawn.py: _nt_quote_args() misses the return statement

Thanks -- fixed 'em both.  Will be checked in later tonight when I'm
online again.

        Greg
-- 
Greg Ward - all-purpose geek                            gward@python.net
http://starship.python.net/~gward/
Never put off till tomorrow what you can put off till the day after tomorrow.


From gward@python.net  Wed Mar 22 01:49:51 2000
From: gward@python.net (Greg Ward)
Date: Tue, 21 Mar 2000 20:49:51 -0500
Subject: [Distutils] additional Flags for build_ext
In-Reply-To: <38D77691.329DD519@GermanLloyd.org>; from Berthold Hoellmann on Tue, Mar 21, 2000 at 02:18:09PM +0100
References: <38D77691.329DD519@GermanLloyd.org>
Message-ID: <20000321204951.B735@beelzebub>

On 21 March 2000, Berthold Hoellmann said:
> I think it would be extremly helpfull for developing Python Extensions
> to be ditributed using Distutils to have an option "--additional-flags"
> where I could give addional flags for the C compiler, e.g. to ask for
> specific compiling or optimization flags. What do you think about it?

Good idea, except I'd call it "--extra-args" for consistency with the
CCompiler interface.  Eg.

    python setup.py build_ext --extra-args="-O666 --funky-option"

...or something like that.  Would this be a single string to split on
spaces, or would we require multiple --extra-args arguments, or would
--extra-args somehow take a list of arguments (eg. comma-separated)?

Opinions?

        greg
-- 
Greg Ward - Linux bigot                                 gward@python.net
http://starship.python.net/~gward/
A closed mouth gathers no foot.


From gward@python.net  Wed Mar 22 01:50:37 2000
From: gward@python.net (Greg Ward)
Date: Tue, 21 Mar 2000 20:50:37 -0500
Subject: [Distutils] an uninstall option patch
Message-ID: <20000321205037.C735@beelzebub>

[oops! meant to send this to the list, not to Bastian personally...
 here 'tis...]

On 19 March 2000, Bastian Kleineidam said:
> I have implemented an uninstall option. If you specify -c or
> --create-uninstall to the install command, an uninstall script named
> <package name>_uninstall.py will be built and it will be installed in 
> install-lib resp. install-platlib. 
> To uninstall your package, execute this script with python.

Hmmm, good idea.  I've idly mused about how to uninstall module
distributions, and this option hadn't occurred to me.  So now I can see
*two* good ways to do uninstallation:

  * keep track of the files installed (eg. using Michael Muller's
    "pkginfo" patch), and have a universal uninstall script that
    digs up the list of files for a particular distribution

  * generate a custom uninstall script for each installed
    module distribution

In terms of correctness -- do we uninstall exactly the right files? --
they're equivalent; you write a list of files to the disk at
installation time and retrieve it later.

For user convenience, I *think* that Bastian's "custom script" approach
would have a slight edge: as long as people know to type (eg.)
"/usr/local/lib/python1.6/site-packages/uninstall_foo", they're fine.
On the other hand, a single global uninstall script could go in a
central location, so just "pymod_uninstall foo" might do the trick.
HmmMMMmm.

Also strikes me that the code might be a tad cleaner for a global
uninstall script: no need to generate Python code, you just need to
generate a list of filenames somewhere in the pkginfo.

Opinions?

        Greg
-- 
Greg Ward - Unix bigot                                  gward@python.net
http://starship.python.net/~gward/
BE ALERT!!!!  (The world needs more lerts ...)


From vanandel@ucar.edu  Wed Mar 22 22:58:04 2000
From: vanandel@ucar.edu (Joe Van Andel)
Date: Wed, 22 Mar 2000 15:58:04 -0700
Subject: [Distutils] Installation: new code, new docs
References: <20000321201458.A575@beelzebub>
Message-ID: <38D94FFC.56FE2C6E@atd.ucar.edu>

> I've just checked in a bunch of changes to the 'install' command, the
> net effect of which is that it now WORKS.  

Sorry to be the bearer of bad news, but I'm not sure about that . . .

I removed my distutils distribution, and re-synced with CVS.  Here's the
tail end of
% rm -fr build
% python setup.py install

running install_lib
Traceback (innermost last):
  File "setup.py", line 22, in ?
    packages = ['distutils', 'distutils.command'],
  File "distutils/core.py", line 98, in setup
    dist.run_commands ()
  File "distutils/core.py", line 531, in run_commands
    self.run_command (cmd)
  File "distutils/core.py", line 580, in run_command
    cmd_obj.run ()
  File "distutils/command/install.py", line 361, in run
    self.run_peer ('install_lib')
  File "distutils/core.py", line 877, in run_peer
    self.distribution.run_command (command)
  File "distutils/core.py", line 578, in run_command
    cmd_obj = self.find_command_obj (command)
  File "distutils/core.py", line 508, in find_command_obj
    cmd_obj = self.create_command_obj (command)
  File "distutils/core.py", line 490, in create_command_obj
    klass = self.find_command_class (command)
  File "distutils/core.py", line 468, in find_command_class
    raise DistutilsModuleError, \
distutils.errors.DistutilsModuleError: invalid command 'install_lib' (no
class '
install_lib' in module 'distutils.command.install_lib')

=========================================================
"python setup.py install_py " did work, however, the result was that
distutils seems broken.

On my extensions:

% python setup.py build
Traceback (innermost last):
  File "setup.py", line 72, in ?
    ext_modules = [
  File "/usr/lib/python1.5/site-packages/distutils/core.py", line 81, in
setup
    dist = klass (attrs)
  File "/usr/lib/python1.5/site-packages/distutils/core.py", line 245,
in __init__
    raise DistutilsOptionError, \
distutils.errors.DistutilsOptionError: invalid distribution option
'install_path'


-- 
Joe VanAndel  	          
National Center for Atmospheric Research
http://www.atd.ucar.edu/~vanandel/
Internet: vanandel@ucar.edu


From calvin@cs.uni-sb.de  Thu Mar 23 00:05:06 2000
From: calvin@cs.uni-sb.de (Bastian Kleineidam)
Date: Thu, 23 Mar 2000 01:05:06 +0100 (CET)
Subject: [Distutils] What is the license of Distutils?
Message-ID: <Pine.LNX.4.21.0003230102250.12411-100000@void.cs.uni-sb.de>

Haaa, made the same mistake, wanted to send to the list, not just to Greg!
Forgive me.

:) apparently it's not *too* big a burden.)  And what modifications do you
:) want to distribute?  I like most of your patches/ideas, so if there are
:) some you're holding back, please share them!
Ok, here is a list what I have done, patches will follow (and if you have 
some ideas, they will be applied):

(1) I implemented an uninstall option. Currently this is a Python script
with a list of installed files. I like more the idea of separating the
uninstall script and just write the list of files in a file because with
my previous attempt you can not delete the Python uninstall script itself
since its running (well, under Linux this actually works - a script that
deletes itself, but not under Windows).
So I better store just a list of installed files.

(2) There is a --destdir option to install in another directory. This is
not the same as supplying the --prefix and --exec-prefix options.
I need this to generate Debian packages easily with
./setup.py install --destdir=`pwd`/debian/tmp

(3) Very crude script support. You supply a list of 'scripts' and
'programs' and they will be installed in effective_prefix/bin
(effective_prefix is either sys.prefix or sys.exec_prefix)
for Unix and in effective_prefix for Windows. You can customize this with
--install-bin.
Why is the install directory effective_prefix under Windows? On my Win98
box this is the directory where python.exe is and I assume the user has
the python executable in his/her PATH.
If you supply a 'script', the string @INSTALL_BIN@ gets replaced with 
the value of install_bin.

(4) As you see from (3) the install command handles now systems with
os.name=='nt' where the default install_lib and install_platlib are
both effective_prefix/lib.

:) I will ask, though, that you *not* install the distutils into anyone's
:) Python installation: I want to reserve that privilege for myself and,
:) ultimately, the Python 1.6 makefile.
I will fix that in my distribution.

My program where I use the distutils is a link checker and located at
http://linkchecker.sourceforge.net/

Bastian



From mmuller@enduden.com  Thu Mar 23 00:55:44 2000
From: mmuller@enduden.com (Michael Muller)
Date: Wed, 22 Mar 2000 19:55:44 -0500
Subject: [Distutils] an uninstall option patch
References: <20000321205037.C735@beelzebub>
Message-ID: <38D96B90.9575215@enduden.com>

Obviously, I'm biased on this issue ;-).  However, these approaches are
equivalent in that they both track the set of installed files: an "uninstall"
script just wraps a function around this set.  Meta-info is more general: you
can use it to uninstall, you can also use it to find out which package a
particular file belongs to, or to verify a file's checksum if you believe that
it may have been corrupted.  

The two approaches are not incompatible: why not provide both?

Greg Ward wrote:
> Hmmm, good idea.  I've idly mused about how to uninstall module
> distributions, and this option hadn't occurred to me.  So now I can see
> *two* good ways to do uninstallation:
> 
>   * keep track of the files installed (eg. using Michael Muller's
>     "pkginfo" patch), and have a universal uninstall script that
>     digs up the list of files for a particular distribution
> 
>   * generate a custom uninstall script for each installed
>     module distribution
> 

=============================================================================
michaelMuller = mmuller@enduden.com | http://www.cloud9.net/~proteus
-----------------------------------------------------------------------------
Those who do not understand Unix are condemned to reinvent it, poorly.
                -- Henry Spencer
=============================================================================


From gward@python.net  Thu Mar 23 04:19:17 2000
From: gward@python.net (Greg Ward)
Date: Wed, 22 Mar 2000 23:19:17 -0500
Subject: [Distutils] Installation: new code, new docs
In-Reply-To: <38D94FFC.56FE2C6E@atd.ucar.edu>; from Joe Van Andel on Wed, Mar 22, 2000 at 03:58:04PM -0700
References: <20000321201458.A575@beelzebub> <38D94FFC.56FE2C6E@atd.ucar.edu>
Message-ID: <20000322231917.B3513@beelzebub>

On 22 March 2000, Joe Van Andel said:
> I removed my distutils distribution, and re-synced with CVS.  Here's the
> tail end of
> % rm -fr build
> % python setup.py install
> 
> running install_lib
> Traceback (innermost last):
[...]
>   File "distutils/core.py", line 468, in find_command_class
>     raise DistutilsModuleError, \
> distutils.errors.DistutilsModuleError: invalid command 'install_lib' (no
> class '
> install_lib' in module 'distutils.command.install_lib')

Oops!  My mistake -- fixed, will check it in shortly. 

> "python setup.py install_py " did work, however, the result was that
> distutils seems broken.

Hmmm, something wrong with your "cvs update" then -- install_py is gone,
history, dead, deleted, removed, shuffled-off-its-mortal-coil.  That is
an EX-module!

Well, try again after I checkin the fix.

Thanks --

        Greg
-- 
Greg Ward - Unix weenie                                 gward@python.net
http://starship.python.net/~gward/
All things are possible -- except skiing through a revolving door.


From gward@python.net  Thu Mar 23 04:12:15 2000
From: gward@python.net (Greg Ward)
Date: Wed, 22 Mar 2000 23:12:15 -0500
Subject: [Distutils] What is the license of Distutils?
In-Reply-To: <Pine.LNX.4.21.0003230102250.12411-100000@void.cs.uni-sb.de>; from Bastian Kleineidam on Thu, Mar 23, 2000 at 01:05:06AM +0100
References: <Pine.LNX.4.21.0003230102250.12411-100000@void.cs.uni-sb.de>
Message-ID: <20000322231215.A3513@beelzebub>

On 23 March 2000, Bastian Kleineidam said:
> (1) I implemented an uninstall option. Currently this is a Python script
> with a list of installed files. I like more the idea of separating the
> uninstall script and just write the list of files in a file because with
> my previous attempt you can not delete the Python uninstall script itself
> since its running (well, under Linux this actually works - a script that
> deletes itself, but not under Windows).
> So I better store just a list of installed files.

Hmmm, that's a good point.  I was leaning towards Michael's "do 'em
both" suggestion, but that implies installing a trivial uninstall script
for every distribution: if the uninstall script is one of the files
installed for a distribution, then it can't do a full uninstall because
of this restriction.  A global uninstall script it is, then.  

> (2) There is a --destdir option to install in another directory. This is
> not the same as supplying the --prefix and --exec-prefix options.
> I need this to generate Debian packages easily with
> ./setup.py install --destdir=`pwd`/debian/tmp

Shouldn't be necessary any more -- please take a good look at the new
installation code and documentation.

> (3) Very crude script support. You supply a list of 'scripts' and
> 'programs' and they will be installed in effective_prefix/bin
> (effective_prefix is either sys.prefix or sys.exec_prefix)
> for Unix and in effective_prefix for Windows. You can customize this with
> --install-bin.

That'll have to change with the new installation stuff.

> Why is the install directory effective_prefix under Windows? On my Win98
> box this is the directory where python.exe is and I assume the user has
> the python executable in his/her PATH.
> If you supply a 'script', the string @INSTALL_BIN@ gets replaced with 
> the value of install_bin.

Irrelevant now -- again, try the new "install" command and see if it
works any better!

        Greg
-- 
Greg Ward -  geek                             gward@python.net
http://starship.python.net/~gward/
If you can read this, thank a programmer.


From calvin@cs.uni-sb.de  Thu Mar 23 10:40:49 2000
From: calvin@cs.uni-sb.de (Bastian Kleineidam)
Date: Thu, 23 Mar 2000 11:40:49 +0100 (CET)
Subject: [Distutils] Installation: new code, new docs
In-Reply-To: <20000322231917.B3513@beelzebub>
Message-ID: <Pine.LNX.4.21.0003231139030.14526-100000@void.cs.uni-sb.de>

:) > "python setup.py install_py " did work, however, the result was that
:) > distutils seems broken.
:) 
:) Hmmm, something wrong with your "cvs update" then -- install_py is gone,
:) history, dead, deleted, removed, shuffled-off-its-mortal-coil.  That is
:) an EX-module!
Perhaps the install_py.pyc is still there. I had to delete it by hand.

Bastian



From calvin@cs.uni-sb.de  Thu Mar 23 11:28:49 2000
From: calvin@cs.uni-sb.de (Bastian Kleineidam)
Date: Thu, 23 Mar 2000 12:28:49 +0100 (CET)
Subject: [Distutils] Optimize patch
Message-ID: <Pine.LNX.4.21.0003231224210.14661-101000@void.cs.uni-sb.de>

  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.

--1619424764-1159763615-953810928=:14661
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hello,

I found this in compileall.py.
We can tell if we run under python -O by looking at __builtin__.__debug__.

Bastian Kleineidam

--1619424764-1159763615-953810928=:14661
Content-Type: APPLICATION/octet-stream; name="patch.optimize.gz"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.21.0003231228480.14661@void.cs.uni-sb.de>
Content-Description: 
Content-Disposition: attachment; filename="patch.optimize.gz"

H4sICM762TgCA3BhdGNoLm9wdGltaXplAM1TUW+bMBB+Hr/iK1WVNAVCkoV1
SPkJe9tDpGqyHGInpxmDsNFEf/1sSKqko5rWl+6EBOe7+767j/OepETcFNiT
sa0lZZKqocP8xZ0XVVlyvZ+TNpYrxRTtkrq7zK8tlfQs/loTzGazf+X59P3Y
4htvsFxhschXWb54xDJN0yCO4/c0cQW4zNN1vjoBzq6t73b9OVp/Re96Pudm
KdxXHADuORtJGKFk4ihrUiK/CHmTTVWi7tgpDCrrqrE4ucHDVfIpyNiuJWVJ
M3bN1QNWDSRIo2qtdBDmNaO3W2y3WxRcTyy4MW0pYI9k4As0d17J65r04QbT
X0du3RCjEmSLKPsySPBHHwNNpVV3HsZRiJ7Ba0IO1IAXtnX6d+Dwi+ODIzAu
XT7Fq/wHNhtMXOIkD24wZm5mJjU2MLZx7SeNqBUvBKYyGgqHVzG5D0br8cZx
/wdL/lOwvn8PN1BF5+Eif3gfvVH/2sJdZ0U8lLo+cWdC3EFG/SZlyyh7HNmk
j1dV4gHTi+1LGNuLXXtgDO42ISxCuO0Lq/B/lfc30C8np9MEAAA=
--1619424764-1159763615-953810928=:14661--


From calvin@cs.uni-sb.de  Thu Mar 23 11:32:19 2000
From: calvin@cs.uni-sb.de (Bastian Kleineidam)
Date: Thu, 23 Mar 2000 12:32:19 +0100 (CET)
Subject: [Distutils] mkpath patch
Message-ID: <Pine.LNX.4.21.0003231228510.14661-101000@void.cs.uni-sb.de>

  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.

--1619424764-1260604193-953811139=:14661
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hello,

this patch lets the mkpath() function return all created directories. You
will need that if you want to generate a list of installed files and
directories.

Bastian

--1619424764-1260604193-953811139=:14661
Content-Type: APPLICATION/octet-stream; name="patch.mkpath.gz"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.21.0003231232190.14661@void.cs.uni-sb.de>
Content-Description: 
Content-Disposition: attachment; filename="patch.mkpath.gz"

H4sICNj72TgCA3BhdGNoLm1rcGF0aADFVFFvmzAQfh6/4tYoImRASdJ2GVIf
qjXTXiZVVd66KLLgklglNjqbbfn3s8G00KZqtWna94Bt+L678302Od9sIKIM
cq50pXmhYkl8e/qwPLXPuDx0CPv7kundc4o3Ho9fjfNuuavgGyOYzmAySWcX
6WQO0yRJvCiK3pCkp5+myaf0/KLRj/uoq5nNw7M51EuoMYCf6BOCkBoqxcUW
GBBmFSn+A4EVW1O13u0DQ3cKwfYIlyBVbAuKhaS9ncDIfgi89y2Pbx44XOWc
HAEkuRCX4Pup4bcg1BWJR/XN1fLr+vPt4mq5uI63qF2AoxKnGu2Q5SFoxoug
U6MqC97KHdNSlKHc2ckKjmIASrPsHuQGCinQmEEKtISMkGms/Wn6aWbRv+un
RZMyX9clmKpXf9fkXrw/6PhT/f9o/7Hj/TEJ50lzvK07djntuuP2ac3J6bCm
SqReP6mmw9NXFtJewLq/douB9+EZo9uRmJUlitxx+zz8lWGpbUAkkhTCyIxC
hmAGpSk4lp0YVwjX7dX/wgtcNOLvHryAk0xWRV5vtSkN/KHyUxiqExi2Trmc
jw5adE/BneWtjFETt+UX/R9A84eCUR3uN0lU6OdIBQAA
--1619424764-1260604193-953811139=:14661--


From vanandel@ucar.edu  Thu Mar 23 16:33:27 2000
From: vanandel@ucar.edu (Joe Van Andel)
Date: Thu, 23 Mar 2000 09:33:27 -0700
Subject: [Distutils] Installation: new code, new docs
References: <20000321201458.A575@beelzebub> <38D94FFC.56FE2C6E@atd.ucar.edu> <20000322231917.B3513@beelzebub>
Message-ID: <38DA4757.4DBB60E0@atd.ucar.edu>

My extension modules are installed in
/usr/local/python/lib/python1.5/site-packages/Perp/{sub_package}

As of 3/23/00, the CVS version of distutils now complains:

 python setup.py build
Traceback (innermost last):
  File "setup.py", line 72, in ?
    ext_modules = [
  File "/usr/lib/python1.5/site-packages/distutils/core.py", line 81, in
setup
    dist = klass (attrs)
  File "/usr/lib/python1.5/site-packages/distutils/core.py", line 245,
in __init__
    raise DistutilsOptionError, \
distutils.errors.DistutilsOptionError: invalid distribution option
'install_path'


'install_path' is documented in USAGE.txt, and worked before.

-- 
Joe VanAndel  	          
National Center for Atmospheric Research
http://www.atd.ucar.edu/~vanandel/
Internet: vanandel@ucar.edu


From calvin@cs.uni-sb.de  Fri Mar 24 17:15:45 2000
From: calvin@cs.uni-sb.de (Bastian Kleineidam)
Date: Fri, 24 Mar 2000 18:15:45 +0100 (CET)
Subject: [Distutils] _nt_quote_args patch
Message-ID: <Pine.LNX.4.21.0003241813520.17441-100000@void.cs.uni-sb.de>

Hello,

You should return the args variable in _nt_quote_args, not None.

Bastian Kleineidam

diff -rc distutils.orig/distutils/spawn.py distutils.quote/distutils/spawn.py
*** distutils.orig/distutils/spawn.py	Thu Mar 23 11:36:18 2000
--- distutils.quote/distutils/spawn.py	Thu Mar 23 13:02:47 2000
***************
*** 55,61 ****
      for i in range (len (args)):
          if string.find (args[i], ' ') != -1:
              args[i] = '"%s"' % args[i]
!     return 
  
  def _spawn_nt (cmd,
                 search_path=1,
--- 55,61 ----
      for i in range (len (args)):
          if string.find (args[i], ' ') != -1:
              args[i] = '"%s"' % args[i]
!     return args
  
  def _spawn_nt (cmd,
                 search_path=1,



From calvin@cs.uni-sb.de  Fri Mar 24 17:19:26 2000
From: calvin@cs.uni-sb.de (Bastian Kleineidam)
Date: Fri, 24 Mar 2000 18:19:26 +0100 (CET)
Subject: [Distutils] Opinion on uninstall
Message-ID: <Pine.LNX.4.21.0003241815460.17441-100000@void.cs.uni-sb.de>

Hello,

here are some thoughts about an uninstall enhancement. If you supply
it as an option to install.py (e.g. --create-uninstall), you can not be
sure that the user always turns this option on. Suppose he ran the
install command without --create-uninstall and some files got
installed. Now he runs it again, but with --create-uninstall. The
result is that no new files will be copied and the file list of (newly)
installed files is empty. So your package list of installed files is
empty and therefore incorrect.
Solution: either you turn on self.force or you dont supply an option
and write the package list every time you run the install command.
I like the second solution more.

A second problem with installation of Debian packages:
I can install everything in `pwd`/debian/tmp with --home or supply my
own install directories. But then the uninstall information is
incorrect. When the Debian package gets installed the package files are
still pointing to `pwd`/debian/tmp.
This is the point where my --destdir=<destpath> option kicks in. 
The destpath prefix gets stripped off the package file list.
If I run "./setup.py install --destdir=`pwd`/debian/tmp" a file installed
as "`pwd`/debian/tmp/usr/lib/python1.5/foo.py" is listed in the package
file list as "/usr/lib/python1.5/foo.py".

Greetings, Bastian



From gward@python.net  Sat Mar 25 02:36:35 2000
From: gward@python.net (Greg Ward)
Date: Fri, 24 Mar 2000 21:36:35 -0500
Subject: [Distutils] Installation: new code, new docs
In-Reply-To: <38DA4757.4DBB60E0@atd.ucar.edu>; from Joe Van Andel on Thu, Mar 23, 2000 at 09:33:27AM -0700
References: <20000321201458.A575@beelzebub> <38D94FFC.56FE2C6E@atd.ucar.edu> <20000322231917.B3513@beelzebub> <38DA4757.4DBB60E0@atd.ucar.edu>
Message-ID: <20000324213635.A481@beelzebub>

On 23 March 2000, Joe Van Andel said:
> My extension modules are installed in
> /usr/local/python/lib/python1.5/site-packages/Perp/{sub_package}
> 
> As of 3/23/00, the CVS version of distutils now complains:
>     raise DistutilsOptionError, \
> distutils.errors.DistutilsOptionError: invalid distribution option
> 'install_path'

Oops, shoulda mentioned that on the list: I unilaterally and arbitrarily
changed the name of that option to 'extra_path', since I think that's a
bit more descriptive.  (So I guess it wasn't *completely* arbitrary.)

I could put in a backwards compatibility hack if the change is a huge
burden (I don't think it should be!), but my excuse for not doing so is
that the version number is still < 1.0, and if you follow the CVS code
periodic breakage is just a fact of life.

        Greg
-- 
Greg Ward - just another /P(erl|ython)/ hacker          gward@python.net
http://starship.python.net/~gward/
Yield to temptation; it may not pass your way again.


From vanandel@ucar.edu  Mon Mar 27 18:16:25 2000
From: vanandel@ucar.edu (Joe Van Andel)
Date: Mon, 27 Mar 2000 11:16:25 -0700
Subject: [Distutils] Installation: new code, new docs
References: <20000321201458.A575@beelzebub> <38D94FFC.56FE2C6E@atd.ucar.edu> <20000322231917.B3513@beelzebub> <38DA4757.4DBB60E0@atd.ucar.edu> <20000324213635.A481@beelzebub>
Message-ID: <38DFA579.8B5820AF@atd.ucar.edu>

This is a multi-part message in MIME format.
--------------B5E0D3A06DAD98A6E9881B43
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

>Oops, shoulda mentioned that on the list: I unilaterally and arbitrarily
>changed the name of that option to 'extra_path', since I think that's a
>bit more descriptive.  (So I guess it wasn't *completely* arbitrary.)

I've attached a patch for the USAGE.txt document, to reflect this
change.

 


-- 
Joe VanAndel  	          
National Center for Atmospheric Research
http://www.atd.ucar.edu/~vanandel/
Internet: vanandel@ucar.edu
--------------B5E0D3A06DAD98A6E9881B43
Content-Type: text/plain; charset=us-ascii;
 name="USAGE.udiff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="USAGE.udiff"

--- USAGE.txt.orig	Mon Mar 27 10:18:58 2000
+++ USAGE.txt	Mon Mar 27 10:26:27 2000
@@ -708,7 +708,7 @@
      "/usr/local/lib/python1.5/site-packages"]
     [DOS/Windows default: 'prefix', eg. "C:\Python"]
     [actually it gets more complicated in the presence of the
-     'install_path' option; see below]
+     'extra_path' option; see below]
 
   install_site_platlib:
     base installation directory for third-party extension modules
@@ -716,18 +716,18 @@
      "/usr/local.plat/lib/python1.5/site-packages"]
     [DOS/Windows default: 'exec_prefix', eg. "C:\Python"]
 
-  install_path:
+  extra_path:
     information about extra intervening directories to put between
     'install_lib' and 'install_sitelib', along with a .pth file to
     ensure that those directories wind up in sys.path.  Can be a 1- or
     2-tuple, or a comma-delimited string with 1 or 2 parts.  The
     1-element case is simpler: the .pth file and directory have the same
-    name (except for ".pth").  Eg. if install_path is "foo" or ("foo",),
+    name (except for ".pth").  Eg. if extra_path is "foo" or ("foo",),
     then Distutils sets 'install_site_lib' to 'install_lib' +
     "site-packages/foo", and puts foo.path in the "site-packages"
     directory; it contains just "foo".  The 2-element case allows the
     .pth file and intervening directories to be named differently; eg.
-    if 'install_path' is ("foo","foo/bar/baz") (or "foo,foo/bar/baz"),
+    if 'extra_path' is ("foo","foo/bar/baz") (or "foo,foo/bar/baz"),
     then Distutils will set 'install_site_lib' to 'install_lib' +
     "site-packages/foo/bar/baz", and put "foo.pth" containing
     "foo/bar/baz" in the "site-packages" directory.

--------------B5E0D3A06DAD98A6E9881B43--



From thomas.heller@ion-tof.com  Tue Mar 28 10:12:22 2000
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Tue, 28 Mar 2000 12:12:22 +0200
Subject: [Distutils] Problems on NT
Message-ID: <00a701bf989e$1be943b0$4500a8c0@thomasnotebook>

1. msvccompiler.py defines a method _find_exe(),
but uses find_exe().

2. The python/libs directory is no longer
included in library_dirs when linking extensions.

Thomas Heller




From thomas.heller@ion-tof.com  Tue Mar 28 10:25:03 2000
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Tue, 28 Mar 2000 12:25:03 +0200
Subject: [Distutils] More problems?
Message-ID: <00d301bf989f$e16d6c50$4500a8c0@thomasnotebook>

How is the --library_dirs resp. -L
option supposed to be used?

When I type
  python setup.py install build_ext -L=./Libs
I get the following linker command line:

... /LIBPATH:= /LIBPATH:. /LIBPATH:/ /LIBPATH:L /LIBPATH:i (and so on)

Thomas Heller




From godzilla@netmeg.net (Les Schaffer)  Tue Mar 28 18:58:07 2000
From: godzilla@netmeg.net (Les Schaffer) (Les Schaffer)
Date: Tue, 28 Mar 2000 13:58:07 -0500 (EST)
Subject: [Distutils] patch to change order of -I's in build_ext.py
Message-ID: <14561.191.229869.353493@gargle.gargle.HOWL>

the following one line patch fixes a problem when using distutils to
build CVS releases of Numerical Python.

what was happening is this: changes were being made to the Numeric API
-- changes reflected in the .h files in subdir Include -- but the
distutils script build_ext.py was placing -I/usr/include/python1.5
__before__ the local -IInclude, hence killing the compile process when
API changes occured.

the change below adds -I/usr/include/python1.5 to the end of the list
self.include_dir rather than the beginning. perhaps you pros in
distutils SIG have a better fix than this hack???

les schaffer



*** build_ext.py~    Sun Jan 30 13:34:12 2000
--- build_ext.py     Tue Mar 28 13:30:03 2000
***************
*** 99,105 ****
              self.include_dirs = string.split (self.include_dirs,
                                                os.pathsep)
  
!         self.include_dirs.insert (0, py_include)
          if exec_py_include != py_include:
              self.include_dirs.insert (0, exec_py_include)
  
--- 99,105 ----
              self.include_dirs = string.split (self.include_dirs,
                                                os.pathsep)
  
!         self.include_dirs.append(py_include)
          if exec_py_include != py_include:
              self.include_dirs.insert (0, exec_py_include)


From gward@python.net  Wed Mar 29 02:23:21 2000
From: gward@python.net (Greg Ward)
Date: Tue, 28 Mar 2000 21:23:21 -0500
Subject: [Distutils] Installation: new code, new docs
In-Reply-To: <38DFA579.8B5820AF@atd.ucar.edu>; from Joe Van Andel on Mon, Mar 27, 2000 at 11:16:25AM -0700
References: <20000321201458.A575@beelzebub> <38D94FFC.56FE2C6E@atd.ucar.edu> <20000322231917.B3513@beelzebub> <38DA4757.4DBB60E0@atd.ucar.edu> <20000324213635.A481@beelzebub> <38DFA579.8B5820AF@atd.ucar.edu>
Message-ID: <20000328212321.A634@beelzebub>

On 27 March 2000, Joe Van Andel said:
> >Oops, shoulda mentioned that on the list: I unilaterally and arbitrarily
> >changed the name of that option to 'extra_path', since I think that's a
> >bit more descriptive.  (So I guess it wasn't *completely* arbitrary.)
> 
> I've attached a patch for the USAGE.txt document, to reflect this
> change.

OK, thanks -- it's checked in now.

        Greg
-- 
Greg Ward - Linux geek                                  gward@python.net
http://starship.python.net/~gward/
Beware of altruism.  It is based on self-deception, the root of all evil.


From gward@python.net  Wed Mar 29 03:30:52 2000
From: gward@python.net (Greg Ward)
Date: Tue, 28 Mar 2000 22:30:52 -0500
Subject: [Distutils] Optimize patch
In-Reply-To: <Pine.LNX.4.21.0003231224210.14661-101000@void.cs.uni-sb.de>; from Bastian Kleineidam on Thu, Mar 23, 2000 at 12:28:49PM +0100
References: <Pine.LNX.4.21.0003231224210.14661-101000@void.cs.uni-sb.de>
Message-ID: <20000328223052.A862@beelzebub>

On 23 March 2000, Bastian Kleineidam said:
> I found this in compileall.py.
> We can tell if we run under python -O by looking at __builtin__.__debug__.

Cool!  Thanks for finding this -- I've just applied (approximately) your
patch.  Had to fix distutils.util.copy_tree so it returned the list of
*all* files copied, not just those that *needed* to be copied.
(Otherwise, running "python setup.py install ; python -O setup.py
install" didn't compile to .pyo, because it didn't install any .py
files.)  It's all checked in now...

        Greg
-- 
Greg Ward - just another /P(erl|ython)/ hacker          gward@python.net
http://starship.python.net/~gward/
God made machine language; all the rest is the work of man.


From gward@python.net  Wed Mar 29 03:33:37 2000
From: gward@python.net (Greg Ward)
Date: Tue, 28 Mar 2000 22:33:37 -0500
Subject: [Distutils] mkpath patch
In-Reply-To: <Pine.LNX.4.21.0003231228510.14661-101000@void.cs.uni-sb.de>; from Bastian Kleineidam on Thu, Mar 23, 2000 at 12:32:19PM +0100
References: <Pine.LNX.4.21.0003231228510.14661-101000@void.cs.uni-sb.de>
Message-ID: <20000328223337.B862@beelzebub>

On 23 March 2000, Bastian Kleineidam said:
> this patch lets the mkpath() function return all created directories. You
> will need that if you want to generate a list of installed files and
> directories.

Yup, and it's also consistent with many of the other functions in
distutils.util: the general trend is to return the list of files (or
directories) that you affected/created.

One inconsistency: 'mkpath()' always returns the empty list if 'dry_run'
is true.  This is not a very big deal, IMHO.

Incidentally, I don't think you want to include directories in the
list-of-things-created.  For creation/installation, it's obvious that
directories need to be created to hold the files that are supposed to be
in them.  For uninstallation, the uninstallation code should be smart
enough to remove directories that it renders empty.  That's the approach
I took in adapting your "clean" command: after cleaning is done, it
attempts to remove the "build" directory, and doesn't care if it fails.
I think a similar approach would work for uninstallation.

Anyways, the mkpath patch is checked in now.  Thanks!

        Greg
-- 
Greg Ward - Linux geek                                  gward@python.net
http://starship.python.net/~gward/
Sure, I'm paranoid... but am I paranoid ENOUGH?


From gward@python.net  Wed Mar 29 03:50:50 2000
From: gward@python.net (Greg Ward)
Date: Tue, 28 Mar 2000 22:50:50 -0500
Subject: [Distutils] Problems on NT
In-Reply-To: <00a701bf989e$1be943b0$4500a8c0@thomasnotebook>; from Thomas Heller on Tue, Mar 28, 2000 at 12:12:22PM +0200
References: <00a701bf989e$1be943b0$4500a8c0@thomasnotebook>
Message-ID: <20000328225050.A1109@beelzebub>

On 28 March 2000, Thomas Heller said:
> 1. msvccompiler.py defines a method _find_exe(),
> but uses find_exe().

Easy fix -- thanks.  Will check it in shortly.

> 2. The python/libs directory is no longer
> included in library_dirs when linking extensions.

Hmmm.  Was it ever?  And why is this necessary?  Is it so extensions can 
link against Python.dll, or is it something else?

Anyone out there been following the recent CVS tumult and trying to
build stuff on Windows?

Thomas (or anyone else on a Windows box with access to the anonymous CVS
tree), if you're feeling hardy, you could try rolling back the
command/build_ext.py file one revision at a time until either 1) the
problem goes away or 2) things blow up horribly because of other
incompatibilities.  If #2 occurs, try rolling back all of Distutils a
week at a time, or maybe 2-3 days at a time.  Let me know if you want
help with the CVS trickery to do this.

        Greg
-- 
Greg Ward - Unix nerd                                   gward@python.net
http://starship.python.net/~gward/
A day without sunshine is like night.


From gward@python.net  Wed Mar 29 03:54:09 2000
From: gward@python.net (Greg Ward)
Date: Tue, 28 Mar 2000 22:54:09 -0500
Subject: [Distutils] More problems?
In-Reply-To: <00d301bf989f$e16d6c50$4500a8c0@thomasnotebook>; from Thomas Heller on Tue, Mar 28, 2000 at 12:25:03PM +0200
References: <00d301bf989f$e16d6c50$4500a8c0@thomasnotebook>
Message-ID: <20000328225409.B1109@beelzebub>

On 28 March 2000, Thomas Heller said:
> How is the --library_dirs resp. -L
> option supposed to be used?

Just like the -L option to Unix linkers:

  -L/foo/bar -L/ding/dong

However, I don't think I ever really finished implementing it -- I was
pretty sure it would be needed at some point, but never actually got to
the point where *I* needed it!

> When I type
>   python setup.py install build_ext -L=./Libs
> I get the following linker command line:
> 
> ... /LIBPATH:= /LIBPATH:. /LIBPATH:/ /LIBPATH:L /LIBPATH:i (and so on)

And obviously (*giggle*) I never tested it.  D'ohh!

But I'm tired now and going to bed soon.  If I don't get a patch before
tomorrow evening (say, 2000 GMT) then I'll fix it myself.

        Greg
-- 
Greg Ward - Unix nerd                                   gward@python.net
http://starship.python.net/~gward/
We have always been at war with Oceania.


From gward@python.net  Wed Mar 29 04:00:21 2000
From: gward@python.net (Greg Ward)
Date: Tue, 28 Mar 2000 23:00:21 -0500
Subject: [Distutils] patch to change order of -I's in build_ext.py
In-Reply-To: <14561.191.229869.353493@gargle.gargle.HOWL>; from Les Schaffer on Tue, Mar 28, 2000 at 01:58:07PM -0500
References: <14561.191.229869.353493@gargle.gargle.HOWL>
Message-ID: <20000328230021.A1137@beelzebub>

On 28 March 2000, Les Schaffer said:
> what was happening is this: changes were being made to the Numeric API
> -- changes reflected in the .h files in subdir Include -- but the
> distutils script build_ext.py was placing -I/usr/include/python1.5
> __before__ the local -IInclude, hence killing the compile process when
> API changes occured.
> 
> the change below adds -I/usr/include/python1.5 to the end of the list
> self.include_dir rather than the beginning. perhaps you pros in
> distutils SIG have a better fix than this hack???

That looks like a reasonable fix.  Heck, I'd much rather write
"list.append" then "list.insert" -- fewer things to remember.

I'll check the change in shortly, but it won't show up in Distutils
0.1.x.

BTW, Is anyone in the NumPy community keeping on top of Distutils?
There have been a *lot* of changes since 0.1.3 was released in January,
and I have been rather free with making incompatible changes (because
there's no way I'm gonna be able to get away with them after Python
1.6/Distutils 1.0 are out).  I've also been keeping my
examples/numpy_setup.py script up-to-date with the changes, in hopes
that some eager NumPy hacker will keep an eye on the changes in
Distutils and be ready to update NumPy's real setup script when the time
comes.  Am I being overly optimistic?

        Greg
-- 
Greg Ward - Unix bigot                                  gward@python.net
http://starship.python.net/~gward/
Very few profundities can be expressed in less than 80 characters.


From thomas.heller@ion-tof.com  Wed Mar 29 09:12:02 2000
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Wed, 29 Mar 2000 11:12:02 +0200
Subject: [Distutils] Problems on NT
References: <00a701bf989e$1be943b0$4500a8c0@thomasnotebook> <20000328225050.A1109@beelzebub>
Message-ID: <00ca01bf995e$d8f147d0$4500a8c0@thomasnotebook>

> > 2. The python/libs directory is no longer
> > included in library_dirs when linking extensions.
> 
> Hmmm.  Was it ever?  And why is this necessary?  Is it so extensions can 
> link against Python.dll, or is it something else?
> 
> Anyone out there been following the recent CVS tumult and trying to
> build stuff on Windows?
> 
> Thomas (or anyone else on a Windows box with access to the anonymous CVS
> tree), if you're feeling hardy, you could try rolling back the
> command/build_ext.py file one revision at a time until either 1) the
> problem goes away or 2) things blow up horribly because of other
> incompatibilities.  If #2 occurs, try rolling back all of Distutils a
> week at a time, or maybe 2-3 days at a time.  Let me know if you want
> help with the CVS trickery to do this.
The problem occurred after cvs revision 1.24 of build_ext.py.

Don't know about unix, but on Windows extensions must be linked against
python15.lib (or python15_d.lib if building debug versions).
The names of the libraries do not need to be supplied on the command line,
they are built with compiler pragmas into the object-files.
However they must be found, so the directory must be included in the
library search path.

msvccompiler.__init__ (on line 162) does this:
        self.add_library_dir( os.path.join( sys.exec_prefix, 'libs' ) )

(If I understood distutils design philosophy correctly, this probably
belongs into build_ext, because it is python extension specific, on
the other hand, it may be NT specific).

This dir is later *overwritten* in ccompiler.set_library_dirs(),
which is called from build_ext, line 185:
        if self.library_dirs is not None:
            self.compiler.set_library_dirs (self.library_dirs)

Some lines above (line 146) I find the following code:
        # Simplify the following logic (eg. don't have to worry about
        # appending to None)
        if self.libraries is None:
            self.libraries = []
        if self.library_dirs is None:
            self.library_dirs = []
        if self.rpath is None:
            self.rpath = []

So, if I change the code around line 185 to:
        if self.library_dirs:
            self.compiler.set_library_dirs (self.library_dirs)
then it works because no library_dirs are specified in the setup_script
or from the command line, but IMO the bug is still there.
I'll leave it up to you to find the correct fix for this.
BTW: Another small bug in build_ext.py:
    self.build_extensions()
should be
    self.build_extensions (self.extensions)

Thomas



From robin@jessikat.demon.co.uk  Wed Mar 29 06:47:46 2000
From: robin@jessikat.demon.co.uk (Robin Becker)
Date: Wed, 29 Mar 2000 07:47:46 +0100
Subject: [Distutils] Problems on NT
In-Reply-To: <20000328225050.A1109@beelzebub>
References: <00a701bf989e$1be943b0$4500a8c0@thomasnotebook>
 <20000328225050.A1109@beelzebub>
Message-ID: <DIMaDDASca44Ew4q@jessikat.demon.co.uk>

In article <20000328225050.A1109@beelzebub>, Greg Ward
<gward@python.net> writes
>On 28 March 2000, Thomas Heller said:
>> 1. msvccompiler.py defines a method _find_exe(),
>> but uses find_exe().
>
>Easy fix -- thanks.  Will check it in shortly.
>
>> 2. The python/libs directory is no longer
>> included in library_dirs when linking extensions.
>
>Hmmm.  Was it ever?  And why is this necessary?  Is it so extensions can 
>link against Python.dll, or is it something else?
>
>Anyone out there been following the recent CVS tumult and trying to
>build stuff on Windows?
>
>Thomas (or anyone else on a Windows box with access to the anonymous CVS
>tree), if you're feeling hardy, you could try rolling back the
>command/build_ext.py file one revision at a time until either 1) the
>problem goes away or 2) things blow up horribly because of other
>incompatibilities.  If #2 occurs, try rolling back all of Distutils a
>week at a time, or maybe 2-3 days at a time.  Let me know if you want
>help with the CVS trickery to do this.
>
>        Greg
libs is supposed to hold stuff ending in .lib under win32. These could
be static libraries or the export library for .dlls or other .pyds which
another extension might want to be linked against.
-- 
Robin Becker


Return-Path: <vanandel@ucar.edu>
Delivered-To: distutils-sig@python.org
Received: from ntserv4.seqnet.net (ntserv4.seqnet.net [207.174.23.6])
	by dinsdale.python.org (Postfix) with ESMTP id 7A9631CE74
	for <distutils-sig@python.org>; Tue, 28 Mar 2000 23:16:07 -0500 (EST)
Received: from ucar.edu (vc3-1-162.dsl.seqnet.net [206.168.103.250])
	by ntserv4.seqnet.net (Build 98 8.9.3/NT-8.9.3) with ESMTP id VAA00028;
	Tue, 28 Mar 2000 21:28:26 -0700
Message-ID: <38E18385.D40BFF48@ucar.edu>
Date: Tue, 28 Mar 2000 21:16:05 -0700
From: Joseph VanAndel <vanandel@ucar.edu>
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Greg Ward <gward@python.net>
Subject: Re: [Distutils] patch to change order of -I's in build_ext.py
References: <14561.191.229869.353493@gargle.gargle.HOWL> <20000328230021.A1137@beelzebub>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: distutils-sig-admin@python.org
Errors-To: distutils-sig-admin@python.org
X-BeenThere: distutils-sig@python.org
X-Mailman-Version: 2.0beta1
Precedence: bulk
List-Id: Module Distribution Utilities for Python <distutils-sig.python.org>

Greg Ward wrote:

> 
> BTW, Is anyone in the NumPy community keeping on top of Distutils?
> There have been a *lot* of changes since 0.1.3 was released in January,
> and I have been rather free with making incompatible changes (because
> there's no way I'm gonna be able to get away with them after Python
> 1.6/Distutils 1.0 are out).  I've also been keeping my
> examples/numpy_setup.py script up-to-date with the changes, in hopes
> that some eager NumPy hacker will keep an eye on the changes in
> Distutils and be ready to update NumPy's real setup script when the time
> comes.  Am I being overly optimistic?
> 

I simply used your examples/numpy_setup.py script with the latest
Numeric Python CVS version, and it worked (Solaris 2.6 and RH6.1). 
There was a message from one frustrated Numeric Python users that didn't
care for the pace of changes in distutils, since Numeric Python doesn't
ship with a Makefile anymore.  But as of this morning (3/28/00), I could
grab the latest distutils, install them, copy examples/numpy_setup.py to
Numeric/setup.py, and build.


From gward@cnri.reston.va.us  Wed Mar 29 19:05:26 2000
From: gward@cnri.reston.va.us (Greg Ward)
Date: Wed, 29 Mar 2000 14:05:26 -0500
Subject: [Distutils] Distutils now in Python CVS tree
Message-ID: <20000329140525.A5842@cnri.reston.va.us>

Hi all --

Distutils is now available through the Python CVS tree *in addition to
its own CVS tree*.  That is, if you keep on top of developments in the
Python CVS tree, then you will be tracking the latest Distutils code in
Lib/distutils.  Or, you can keep following the Distutils through its own
CVS tree.  (This is all done through one itty-bitty little symlink in
the CNRI CVS repository, and It Just Works.  Cool.)

Note that only the 'distutils' subdirectory of the distutils
distribution is tracked by Python: that is, changes to the
documentation, test suites, and example setup scripts are *not*
reflected in the Python CVS tree.

If you follow neither Python nor Distutils CVS updates, this doesn't
affect you.

If you've been following Distutils CVS updates, you can continue to do so
as you've always done (and as is documented on the Distutils "Anonymous
CVS" web page).

If you've been following Python CVS updates, then you are now following
most Distutils CVS updates too -- as long as you do "cvs update -d", of
course.  If you're interested in following updates in the Distutils
documentation, tests, examples, etc. then you should follow the
Distutils CVS tree directly.

If you've been following *both* Python and Distutils CVS updates, and
hacking on the Distutils, then you should pick one or the other as your
working directory.  If you submit patches, it doesn't really matter if
they're relative to the top of the Python tree, the top of the Distutils
tree, or what -- I'll probably figure it out.  However, it's probably
best to continue sending Distutils patches to distutils-sig@python.org,
*or* direct to me (gward@python.net) for trivial patches.  Unless Guido
says otherwise, I don't see a compelling reason to send Distutils
patches to patches@python.org.

In related news, the distutils-checkins list is probably going to go
away, and all Distutils checkin messages will go python-checkins
instead.  Let me know if you avidly follow distutils-checkins, but do
*not* want to follow python-checkins -- if lots of people respond
(doubtful, as distutils-checkins only had 3 subscribers last I
checked!), we'll reconsider.

        Greg


From thomas.heller@ion-tof.com  Wed Mar 29 19:26:05 2000
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Wed, 29 Mar 2000 21:26:05 +0200
Subject: [Distutils] Patch for NT
Message-ID: <040001bf99b4$a0c08dc0$4500a8c0@thomasnotebook>

The attached patch fixes the followoing problems:
1. self.build_extensions - (which I reported already)
2. The python library directory is now again used (also already reported by me)
3. Debug and Release versions of python extensions under windows are now
compiled in different directories (as it should be!).
4. Unneeded junk from the MSVC linker (.lib and .exp files) are now created in the
temporary build directory.

diff -cr distutils/command/build_ext.py distutils.new/command/build_ext.py
*** distutils/command/build_ext.py Wed Mar 29 10:33:48 2000
--- distutils.new/command/build_ext.py Wed Mar 29 21:16:16 2000
***************
*** 125,130 ****
--- 125,141 ----
          # XXX how the heck are 'self.define' and 'self.undef' supposed to
          # be set?
  
+         if self.library_dirs is None:
+             self.library_dirs = []
+         # for extensions under windows use different directories
+         # for Release and Debug builds.
+         # also Python's library directory must be appended to library_dirs
+         if os.name == 'nt':
+             self.library_dirs.append (os.path.join(sys.exec_prefix, 'libs'))
+             if self.debug:
+                 self.build_temp = os.path.join (self.build_temp, "Debug")
+             else:
+                 self.build_temp = os.path.join (self.build_temp, "Release")
      # finalize_options ()
      
  
***************
*** 189,195 ****
              self.compiler.set_link_objects (self.link_objects)
  
          # Now actually compile and link everything.
!         self.build_extensions ()
  
      # run ()
  
--- 200,206 ----
              self.compiler.set_link_objects (self.link_objects)
  
          # Now actually compile and link everything.
!         self.build_extensions (self.extensions)
  
      # run ()
  
***************
*** 313,318 ****
--- 324,336 ----
                  else:
                      modname = string.split (extension_name, '.')[-1]
                      extra_args.append('/export:init%s'%modname)
+                 # the MSVC linker generates unneeded .lib and .exp files,
+                 # which cannot be suppressed by any linker switches.
+                 # So make sure they are generated in the temporary
+                 # build directory
+                 implib_dir = os.path.join(self.build_temp,\
+                                           self.get_ext_libname(extension_name))
+                 extra_args.append ('/IMPLIB:' + implib_dir)
              # if MSVC
  
              fullname = self.get_ext_fullname (extension_name)
***************
*** 351,356 ****
--- 369,385 ----
      def get_ext_filename (self, ext_name):
          from distutils import sysconfig
          ext_path = string.split (ext_name, '.')
+         # extensions in debug_mode are named 'module_d.pyd' under windows
+         if os.name == 'nt' and self.debug:
+             return apply (os.path.join, ext_path) + '_d' + sysconfig.SO
          return apply (os.path.join, ext_path) + sysconfig.SO
+ 
+     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'
  
  # class BuildExt
diff -cr distutils/msvccompiler.py distutils.new/msvccompiler.py
*** distutils/msvccompiler.py Wed Mar 29 09:01:40 2000
--- distutils.new/msvccompiler.py Wed Mar 29 20:58:54 2000
***************
*** 319,333 ****
              raise TypeError, "'output_dir' must be a string or None"
          if output_dir is not None:
              output_filename = os.path.join (output_dir, output_filename)
  
          if self._need_link (objects, output_filename):
  
              if debug:
                  ldflags = self.ldflags_shared_debug
-                 # XXX not sure this belongs here
-                 # extensions in debug_mode are named 'module_d.pyd'
-                 basename, ext = os.path.splitext (output_filename)
-                 output_filename = basename + '_d' + ext
              else:
                  ldflags = self.ldflags_shared
  
--- 319,331 ----
              raise TypeError, "'output_dir' must be a string or None"
          if output_dir is not None:
              output_filename = os.path.join (output_dir, output_filename)
+         else:
+             output_dir = os.path.dirname (output_filename)
  
          if self._need_link (objects, output_filename):
  
              if debug:
                  ldflags = self.ldflags_shared_debug
              else:
                  ldflags = self.ldflags_shared
  


Thomas Heller
ION-TOF GmbH



From fdrake@acm.org  Wed Mar 29 19:28:19 2000
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Wed, 29 Mar 2000 14:28:19 -0500 (EST)
Subject: [Distutils] Distutils now in Python CVS tree
In-Reply-To: <20000329140525.A5842@cnri.reston.va.us>
References: <20000329140525.A5842@cnri.reston.va.us>
Message-ID: <14562.22867.998809.897214@seahag.cnri.reston.va.us>

Greg Ward writes:
 > Distutils is now available through the Python CVS tree *in addition to
 > its own CVS tree*.  That is, if you keep on top of developments in the
 > Python CVS tree, then you will be tracking the latest Distutils code in
 > Lib/distutils.  Or, you can keep following the Distutils through its own
 > CVS tree.  (This is all done through one itty-bitty little symlink in
 > the CNRI CVS repository, and It Just Works.  Cool.)

Greg,
  You may want to point out the legalese requirements for patches to
the Python tree.  ;(  That means the patches should probably go to
patches@python.org or you should ensure an archive of all the legal
statements is maintained at CNRI.


  -Fred

--
Fred L. Drake, Jr.	  <fdrake at acm.org>
Corporation for National Research Initiatives



From mhammond@skippinet.com.au  Thu Mar 30 12:02:46 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Thu, 30 Mar 2000 22:02:46 +1000
Subject: [Distutils] Patch for NT
In-Reply-To: <040001bf99b4$a0c08dc0$4500a8c0@thomasnotebook>
Message-ID: <ECEPKNMJLHAPFFJHDOJBKEIHCHAA.mhammond@skippinet.com.au>

PiAzLiBEZWJ1ZyBhbmQgUmVsZWFzZSB2ZXJzaW9ucyBvZiBweXRob24gZXh0ZW5zaW9ucyB1bmRl
ciANCj4gd2luZG93cyBhcmUgbm93DQo+IGNvbXBpbGVkIGluIGRpZmZlcmVudCBkaXJlY3Rvcmll
cyAoYXMgaXQgc2hvdWxkIGJlISkuDQoNCkhvdyBhYm91dCB1c2luZyB0aGUgc2FtZSBjb252ZW50
aW9uIFB5dGhvbiBpdHNlbGYgZG9lcz8NCg0KKiBEZWJ1ZyBhbmQgcmVsZWFzZSBvdXRwdXRzIGdv
IGludG8gdGhlIHNhbWUgZGlyZWN0b3J5IChhcyB0aGV5IGhhdmUgZGlmZmVyZW50IG5hbWVzIC0g
X2QgZm9yIGRlYnVnKS4gIFRoaXMgYWxsb3dzIHBlb3BsZSB0byBhZGQgdGhlIGJ1aWxkIGRpcmVj
dG9yeSB0byB0aGVpciBzeXMucGF0aCwgYW5kIGhhdmUgaXQgd29yayBmb3IgYm90aCBkZWJ1ZyBh
bmQgcmVsZWFzZS4NCg0KKiBCdWlsZFxUZW1wXFJlbGVhc2UgYW5kIEJ1aWxkXFRlbXBcRGVidWcg
YXJlIHdoZXJlIHRoZSBpbnRlcm1lZGlhdGUgZmlsZXMgZ28uICBUaGlzIG1ha2VzIGl0IGVhc3kg
dG8gbWFudWFsbHkgY2xlYW4geW91ciBmaWxlIHN5c3RlbSAtIG9uZSBkaXJlY3RvcnkgYW5kIGFs
bCB0ZW1wIGZpbGVzIGFyZSBnb25lLg0KDQpNYXJrLg0K



From thomas.heller@ion-tof.com  Thu Mar 30 13:19:58 2000
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Thu, 30 Mar 2000 15:19:58 +0200
Subject: [Distutils] Patch for NT
References: <ECEPKNMJLHAPFFJHDOJBKEIHCHAA.mhammond@skippinet.com.au>
Message-ID: <011901bf9a4a$a69519f0$4500a8c0@thomasnotebook>

> > 3. Debug and Release versions of python extensions under
> > windows are now
> > compiled in different directories (as it should be!).
>
> How about using the same convention Python itself does?
>
> * Debug and release outputs go into the same directory (as they have different names - _d for debug).  This allows people to add
the build directory to their sys.path, and have it work for both debug and release.
>
> * Build\Temp\Release and Build\Temp\Debug are where the intermediate files go.  This makes it easy to manually clean your file
system - one directory and all temp files are gone.
>
> Mark.


It seems my description was unclear:
Intermediate files go into build\temp.win32\Release\... or build\temp.win32\Debug\...
These are: .obj, .lib, .exp files.

Debug and Release outputs go into the same directory, debug versions have _d appended.

Cleaning files: distutils now has a clean command (which will delete build\temp.win32 directory): Manual cleaning not needed.

Thomas



From mhammond@skippinet.com.au  Thu Mar 30 13:18:14 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Thu, 30 Mar 2000 23:18:14 +1000
Subject: [Distutils] Patch for NT
In-Reply-To: <011901bf9a4a$a69519f0$4500a8c0@thomasnotebook>
Message-ID: <ECEPKNMJLHAPFFJHDOJBOEIICHAA.mhammond@skippinet.com.au>

PiBJdCBzZWVtcyBteSBkZXNjcmlwdGlvbiB3YXMgdW5jbGVhcjoNCg0KT3IgbXkgcmVhZGluZyB3
YXMgdG9vIHF1aWNrIDotKQ0KDQpMb29rcyBwZXJmZWN0IDotKQ0KDQpNYXJrLg0K



From vanandel@ucar.edu  Thu Mar 30 15:48:36 2000
From: vanandel@ucar.edu (Joe Van Andel)
Date: Thu, 30 Mar 2000 08:48:36 -0700
Subject: [Distutils] build_ext.py rev 1.27 :distutils broken
Message-ID: <38E37754.CCA9B1A9@atd.ucar.edu>

I updated my distutils from cvs and installed them.  Now, when I try to
build my application, I get:
===========================================================
running build_ext
Traceback (innermost last):
  File "setup.py", line 69, in ?
    ext_modules = [
  File "/usr/lib/python1.5/site-packages/distutils/core.py", line 98, in
setup
    dist.run_commands ()
  File "/usr/lib/python1.5/site-packages/distutils/core.py", line 533,
in run_co
mmands
    self.run_command (cmd)
  File "/usr/lib/python1.5/site-packages/distutils/core.py", line 582,
in run_co
mmand
    cmd_obj.run ()
  File "/usr/lib/python1.5/site-packages/distutils/command/install.py",
line 364
, in run
    self.run_peer ('build')
  File "/usr/lib/python1.5/site-packages/distutils/core.py", line 899,
in run_pe
er
    self.distribution.run_command (command)
  File "/usr/lib/python1.5/site-packages/distutils/core.py", line 582,
in run_co
mmand
    cmd_obj.run ()
  File "/usr/lib/python1.5/site-packages/distutils/command/build.py",
line 95, i
n run
    self.run_peer ('build_ext')
  File "/usr/lib/python1.5/site-packages/distutils/core.py", line 899,
in run_pe
er
    self.distribution.run_command (command)
  File "/usr/lib/python1.5/site-packages/distutils/core.py", line 582,
in run_co
mmand
    cmd_obj.run ()
  File
"/usr/lib/python1.5/site-packages/distutils/command/build_ext.py", line
1
92, in run
    self.build_extensions ()
TypeError: not enough arguments; expected 2, got 1
=========================================================================

cvs diff -r1.25 build_ext.py shows (among other differences):

         # Now actually compile and link everything.
-        self.build_extensions (self.extensions)
+        self.build_extensions ()

Restoring the old version of this line seems to fix the problem.

Not to be picky, but I'd certainly appreciate better regression testing
on distutils, so these trival errors don't occur.   

Would you consider tagging CVS revisions for additional sub-releases,
like
Distutils_0_1_3a, so we'd know what it likely to be stable?  As it is, I
think I'll have to save a working copy of distutils, before I update
from CVS.
 



-- 
Joe VanAndel  	          
National Center for Atmospheric Research
http://www.atd.ucar.edu/~vanandel/
Internet: vanandel@ucar.edu


From gward@cnri.reston.va.us  Thu Mar 30 20:00:32 2000
From: gward@cnri.reston.va.us (Greg Ward)
Date: Thu, 30 Mar 2000 15:00:32 -0500
Subject: [Distutils] Re: build_ext.py rev 1.27 :distutils broken
In-Reply-To: <38E37754.CCA9B1A9@atd.ucar.edu>; from vanandel@atd.ucar.edu on Thu, Mar 30, 2000 at 08:48:36AM -0700
References: <38E37754.CCA9B1A9@atd.ucar.edu>
Message-ID: <20000330150032.D6035@cnri.reston.va.us>

On 30 March 2000, Joe Van Andel said:
> I updated my distutils from cvs and installed them.  Now, when I try to
> build my application, I get:
[...]
> "/usr/lib/python1.5/site-packages/distutils/command/build_ext.py", line
> 1
> 92, in run
>     self.build_extensions ()
> TypeError: not enough arguments; expected 2, got 1

Arghh!  Sorry about that: sloppy and inexcusable.  Somebody slap me with
a wet noodle.  Fixed in CVS now.

> Not to be picky, but I'd certainly appreciate better regression testing
> on distutils, so these trival errors don't occur.   

That's a completely fair complaint, and one that I hope to start
addressing Real Soon Now with a proper test suite.  However, right now
I'm smack dab in the middle of adding the "bdist" command with the
ability to create a "dumb" binary distribution -- a tarball or zip file
that you unpack in $prefix or $exec_prefix to "install" a module
distribution.  (This is a stepping stone on the way to creating a
"smart" binary distribution, like an RPM or Wise installed for Windows.)

Adding support for this has meant revisiting a lot of stable code, and
taking advantage of the revisiting to refactor, rethink, and otherwise
raise hell.  Long term, this is a good thing, but in the short term, the
lack of a test suite makes it a wee bit dangerous -- eg. I risk causing
stupid breakage in the CVS tree that brave adventurers like you might
stumble upon.

This *particular* bit of breakage was *really* stupid, and there's no
need for a test suite to catch it: I should have just gone and done a
quick build of NumPy or PIL to make sure it was still working.  I
didn't, and I feel (and look) stupid.  Sorry again.

However, when you follow the CVS tree day-to-day, you've got to expect
some breakage.  I *really* appreciate the fact that you and a few other
folks *are* following the CVS day-to-day, and I apologize for wasting
your time with trivial breakage like this.  I'll try to only check in
real serious breakage in the future, to give you guys something to sink
your teeth into.  >grin<

> Would you consider tagging CVS revisions for additional sub-releases,
> like
> Distutils_0_1_3a, so we'd know what it likely to be stable?  As it is, I
> think I'll have to save a working copy of distutils, before I update
> from CVS.

Hmmm... that's an idea.  I think I prefer the dated snapshot approach,
though.  I got lazy there because a number of people told me it wasn't
really necessary, but I think it might be after all.  A dated snapshot
just says, "Here, the code was fairly stable and seemed to be working
when I made this" -- which I think is what you want.  I have explicitly
*not* tagged the tree when making a snapshot, and I have deleted old
snapshots -- that's to remind myself (and anyone else who cares) that
these are *not* releases.

So I probably *should* have made a snapshot before I started breaking
things to support the "bdist" command -- too late now, unless I indulge
in some CVS-sponsored time travel.  I *will* make a snapshot when the
create-a-dumb-binary-distribution stuff is working.  It's entirely
possible that that snapshot will be the same as what's included in the
snapshot Guido will create soon (tomorrow?) called "Python 1.6 alpha1".
;-)

        Greg
-- 
Greg Ward - software developer                    gward@cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                           voice: +1-703-620-8990
Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913


From gward@python.net  Fri Mar 31 03:54:14 2000
From: gward@python.net (Greg Ward)
Date: Thu, 30 Mar 2000 22:54:14 -0500
Subject: [Distutils] Re: Patch for NT
In-Reply-To: <040001bf99b4$a0c08dc0$4500a8c0@thomasnotebook>; from Thomas Heller on Wed, Mar 29, 2000 at 09:26:05PM +0200
References: <040001bf99b4$a0c08dc0$4500a8c0@thomasnotebook>
Message-ID: <20000330225414.A787@beelzebub>

On 29 March 2000, Thomas Heller said:
> The attached patch fixes the followoing problems:
> 1. self.build_extensions - (which I reported already)
> 2. The python library directory is now again used (also already reported by me)
> 3. Debug and Release versions of python extensions under windows are now
> compiled in different directories (as it should be!).
> 4. Unneeded junk from the MSVC linker (.lib and .exp files) are now created in the
> temporary build directory.

Thanks!  I see a few potential problems here (maybe -- remember, I'm not
a Windows user, so if these sound like trying to apply The Unix Way to
Windows, tell me).

> +             if self.debug:
> +                 self.build_temp = os.path.join (self.build_temp, "Debug")
> +             else:
> +                 self.build_temp = os.path.join (self.build_temp, "Release")

So you'll have build directories build/temp.nt/Debug and
build/temp.nt/Release -- is that somehow better than build/temp.nt-debug
and build/temp.nt-release?  I was kinda thinking along the latter lines;
I don't *think* it makes any difference, apart from aesthetics.  Does
it?  I'm guessing that The Microsoft Way would be to create an
unnecessarily deep hierarchy.

> diff -cr distutils/msvccompiler.py distutils.new/msvccompiler.py
> *** distutils/msvccompiler.py Wed Mar 29 09:01:40 2000
> --- distutils.new/msvccompiler.py Wed Mar 29 20:58:54 2000
[...]
> --- 319,331 ----
>               raise TypeError, "'output_dir' must be a string or None"
>           if output_dir is not None:
>               output_filename = os.path.join (output_dir, output_filename)
> +         else:
> +             output_dir = os.path.dirname (output_filename)

What does this add?  The name 'output_dir' isn't referenced anywhere
after this point.

I fixed the stupid 'build_extensions' bug differently, so that part of
your patch is unneeded.  (Thanks anyway. ;-)

There, I've just applied your patch, discarded the unneeded
'build_extensions' and 'output_dir' bits, and checked it all in.  Looks
like it all still works for me under Linux...

Thanks again!

        Greg
-- 
Greg Ward - Unix bigot                                  gward@python.net
http://starship.python.net/~gward/
God is real, unless declared integer.


From gward@python.net  Fri Mar 31 03:26:04 2000
From: gward@python.net (Greg Ward)
Date: Thu, 30 Mar 2000 22:26:04 -0500
Subject: [Distutils] Beginning of support for binary distributions
Message-ID: <20000330222604.A730@beelzebub>

Hi all --

I've just checked in the beginnings of support for creating "built
distributions" (aka binary distributions, but of course they aren't
necessarily binary -- you might want to distribute something that is
immediately installable but contains only Python code).

This consists of two commands so far, 'bdist' and 'bdist_dumb'.  These
follow the model of the 'build' and 'install' families, where there is
one high-level coordinator, and "sub-commands" that do the real work.
So far, obviously, there's only one bdist sub-command, and all it
creates are "dumb" built distributions -- tarballs and zip files that
you unpack from <prefix> or <exec-prefix>.

There are a number of obvious weaknesses to this, but this was intended
more as a warm-up exercise than the real thing.  First of all, the end
user has to somehow know to chdir to Python's <prefix> or <exec-prefix>
and unpack the dumb distribution there.  Worse, they have to know to
sometimes chdir to to <prefix>, and sometimes <exec-prefix> -- assuming
there's even a difference on their system.  Anyways, as I said, this is
*not* the be-all, end-all to creating built Python module distributions!
However, it's all that I could whip up in three evenings.

If you'd like to try it out, please do!  Here's the basic idea:

    python setup.py bdist
or:
    python setup.py bdist --formats=gztar    # or zip, tar, or ztar

The default format is currently gztar for Unix, zip for Windows.
Obviously, that will have to get a bit more complicated: we'll want to
create an RPM on RPM-based systems, a Debian package on Debian systems,
a BSD package on BSD systems, some sort of executable installer
(probably Wise) on Windows systems, etc.  But for now, you get either a
tarball or a zipfile, and if you don't specify --formats, you get
whatever is sensible on your current OS.

For example, if I go to my NumPy 15.2 directory (which is identical to
the NumPy 15.2 distribution, *except* I use the example NumPy setup
script included with the Distutils!) and run this:

  $ python setup.py bdist 

then I get (roughly) this output:

  [...build output omitted...]
  creating build/bdist
  creating build/bdist/lib
  creating build/bdist/lib/python1.5
  creating build/bdist/lib/python1.5/site-packages
  creating build/bdist/lib/python1.5/site-packages/Numeric
  hard linking build/lib.linux-i586/ArrayPrinter.py -> build/bdist/lib/python1.5/site-packages/Numeric
  hard linking build/lib.linux-i586/FFT.py -> build/bdist/lib/python1.5/site-packages/Numeric
  [...and so on, for all modules that NumPy would install...]
  changing into 'build/bdist'
  tar -cf /scratch/python/Numerical-15.2/Numerical-15.2.linux-i586.tar .
  gzip /scratch/python/Numerical-15.2/Numerical-15.2.linux-i586.tar
  changing back to '/scratch/python/Numerical-15.2'

and the resulting tarball, Numerical-15.2.linux-i586.tar.gz, looks like
this:

  $ tar tzf Numerical-15.2.linux-i586.tar.gz
  ./
  lib/
  lib/python1.5/
  lib/python1.5/site-packages/
  lib/python1.5/site-packages/Numeric/
  lib/python1.5/site-packages/Numeric/ArrayPrinter.py
  lib/python1.5/site-packages/Numeric/FFT.py
  lib/python1.5/site-packages/Numeric/LinearAlgebra.py
  [...]
  lib/python1.5/site-packages/Numeric/ranlib.so
  lib/python1.5/site-packages/Numeric/arrayfns.so

which reduces installing Numerical Python to a mere

  $ cd `python -c "import sys; print sys.exec_prefix"`
  $ tar xzvf /scratch/python/Numerical-15.2/Numerical-15.2.linux-i586.tar.gz

OK, OK, so it's not immediately obvious that this is better than a
simple "python setup.py install".  ;-)  But think of the possibilities!

Known bugs:

  * if a distribution needs a .pth file, it is neither created nor
    included in the built distribution

Feel free to add to this list...

        Greg
-- 
Greg Ward - just another /P(erl|ython)/ hacker          gward@python.net
http://starship.python.net/~gward/
If it can't be expressed in figures, it is not science--it is opinion.


From mhammond@skippinet.com.au  Fri Mar 31 05:21:32 2000
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Fri, 31 Mar 2000 15:21:32 +1000
Subject: [Distutils] Re: Patch for NT
In-Reply-To: <20000330225414.A787@beelzebub>
Message-ID: <ECEPKNMJLHAPFFJHDOJBGEKDCHAA.mhammond@skippinet.com.au>

> So you'll have build directories build/temp.nt/Debug and
> build/temp.nt/Release -- is that somehow better than
> build/temp.nt-debug
> and build/temp.nt-release?  I was kinda thinking along
> the latter lines;
> I don't *think* it makes any difference, apart from
> aesthetics.  Does

Nope - just aesthetics.  This is my preference, as it is a single
directory to ignore, rather than 2 :-)

> I'm guessing that The Microsoft Way would be to create an
> unnecessarily deep hierarchy.

Actually, by default it is very shallow - all temp and output files
go into either ".\Release" or ".\Debug" - adding the intermediate
layers (and sneaking them into Python itself) is my doing :-)

But given the 2 alternatives above, my preference is so slight it is
barely worth mentioning :-)

I can't answer your other question...

Mark.




From thomas.heller@ion-tof.com  Fri Mar 31 07:17:27 2000
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Fri, 31 Mar 2000 09:17:27 +0200
Subject: [Distutils] Re: Patch for NT
References: <040001bf99b4$a0c08dc0$4500a8c0@thomasnotebook> <20000330225414.A787@beelzebub>
Message-ID: <00c701bf9ae1$2bfe52f0$4500a8c0@thomasnotebook>

> > diff -cr distutils/msvccompiler.py distutils.new/msvccompiler.py
> > *** distutils/msvccompiler.py Wed Mar 29 09:01:40 2000
> > --- distutils.new/msvccompiler.py Wed Mar 29 20:58:54 2000
> [...]
> > --- 319,331 ----
> >               raise TypeError, "'output_dir' must be a string or None"
> >           if output_dir is not None:
> >               output_filename = os.path.join (output_dir, output_filename)
> > +         else:
> > +             output_dir = os.path.dirname (output_filename)
> 
> What does this add?  The name 'output_dir' isn't referenced anywhere
> after this point.
Not needed any longer. You are right.

> There, I've just applied your patch, discarded the unneeded
> 'build_extensions' and 'output_dir' bits, and checked it all in.  Looks
> like it all still works for me under Linux...
> 
I did an cvs update this morning, and it works. Thanks!

Thomas



From robin@jessikat.demon.co.uk  Fri Mar 31 07:11:02 2000
From: robin@jessikat.demon.co.uk (Robin Becker)
Date: Fri, 31 Mar 2000 08:11:02 +0100
Subject: [Distutils] FreeBSD
Message-ID: <sQ1qDJAG+E54EwVg@jessikat.demon.co.uk>

I'm trying to port stuff from Win32 to FreeBSD. Distutils is fine with
win32, but can I use it with freebsd? I notice that earlier methods used
a universal makefile and Setup.in and involved a lot of technology ie
libtool etc etc
-- 
Robin Becker


From thomas.heller@ion-tof.com  Fri Mar 31 16:05:44 2000
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Fri, 31 Mar 2000 18:05:44 +0200
Subject: [Distutils] distutils should use new winreg module on NT
Message-ID: <032a01bf9b2a$f873e5e0$4500a8c0@thomasnotebook>

This patch changes msvccompiler.py so that the new winreg module
is used if available. Otherwise, win32reg and win32con is used.

*** msvccompiler.py Fri Mar 31 18:01:20 2000
--- msvccompiler.new.py Fri Mar 31 17:55:02 2000
***************
*** 16,21 ****
--- 16,47 ----
  from distutils.ccompiler import \
       CCompiler, gen_preprocess_options, gen_lib_options
  
+ try:
+     import winreg
+     _HKEY_CLASSES_ROOT = winreg.HKEY_CLASSES_ROOT
+     _HKEY_LOCAL_MACHINE = winreg.HKEY_LOCAL_MACHINE
+     _HKEY_CURRENT_USER = winreg.HKEY_CURRENT_USER
+     _HKEY_USERS = winreg.HKEY_USERS
+     _RegOpenKeyEx = winreg.OpenKeyEx
+     _RegEnumKey = winreg.EnumKey
+     _RegEnumValue = winreg.EnumValue
+     _RegError = winreg.error
+     _can_read_reg = 1
+ except ImportError:
+     try:
+         import win32api
+         import win32con
+         _HKEY_CLASSES_ROOT = win32con.HKEY_CLASSES_ROOT
+         _HKEY_LOCAL_MACHINE = win32con.HKEY_LOCAL_MACHINE
+         _HKEY_CURRENT_USER = win32con.HKEY_CURRENT_USER
+         _HKEY_USERS = win32con.HKEY_USERS
+         _RegOpenKeyEx = win32api.RegOpenKeyEx
+         _RegEnumKey = win32api.RegEnumKey
+         _RegEnumValue = win32api.RegEnumValue
+         _RegError = win32api.error
+         _can_read_reg = 1
+     except ImportError:
+         _can_read_reg = 0
  
  def get_devstudio_versions ():
      """Get list of devstudio versions from the Windows registry.  Return a
***************
*** 24,53 ****
         a registry-access module) or the appropriate registry keys weren't
         found."""
  
!     try:
!         import win32api
!         import win32con
!     except ImportError:
          return []
  
      K = 'Software\\Microsoft\\Devstudio'
      L = []
!     for base in (win32con.HKEY_CLASSES_ROOT,
!                  win32con.HKEY_LOCAL_MACHINE,
!                  win32con.HKEY_CURRENT_USER,
!                  win32con.HKEY_USERS):
          try:
!             k = win32api.RegOpenKeyEx(base,K)
              i = 0
              while 1:
                  try:
!                     p = win32api.RegEnumKey(k,i)
                      if p[0] in '123456789' and p not in L:
                          L.append(p)
!                 except win32api.error:
                      break
                  i = i + 1
!         except win32api.error:
              pass
      L.sort()
      L.reverse()
--- 50,76 ----
         a registry-access module) or the appropriate registry keys weren't
         found."""
  
!     if not _can_read_reg:
          return []
  
      K = 'Software\\Microsoft\\Devstudio'
      L = []
!     for base in (_HKEY_CLASSES_ROOT,
!                  _HKEY_LOCAL_MACHINE,
!                  _HKEY_CURRENT_USER,
!                  _HKEY_USERS):
          try:
!             k = _RegOpenKeyEx(base,K)
              i = 0
              while 1:
                  try:
!                     p = _RegEnumKey(k,i)
                      if p[0] in '123456789' and p not in L:
                          L.append(p)
!                 except _RegError:
                      break
                  i = i + 1
!         except _RegError:
              pass
      L.sort()
      L.reverse()
***************
*** 61,70 ****
         a list of strings; will be empty list if unable to access the
         registry or appropriate registry keys not found."""
         
!     try:
!         import win32api
!         import win32con
!     except ImportError:
          return []
  
      L = []
--- 84,90 ----
         a list of strings; will be empty list if unable to access the
         registry or appropriate registry keys not found."""
         
!     if not _can_read_reg:
          return []
  
      L = []
***************
*** 74,89 ****
      K = ('Software\\Microsoft\\Devstudio\\%s\\' +
           'Build System\\Components\\Platforms\\Win32 (%s)\\Directories') % \
          (version,platform)
!     for base in (win32con.HKEY_CLASSES_ROOT,
!                  win32con.HKEY_LOCAL_MACHINE,
!                  win32con.HKEY_CURRENT_USER,
!                  win32con.HKEY_USERS):
          try:
!             k = win32api.RegOpenKeyEx(base,K)
              i = 0
              while 1:
                  try:
!                     (p,v,t) = win32api.RegEnumValue(k,i)
                      if string.upper(p) == path:
                          V = string.split(v,';')
                          for v in V:
--- 94,109 ----
      K = ('Software\\Microsoft\\Devstudio\\%s\\' +
           'Build System\\Components\\Platforms\\Win32 (%s)\\Directories') % \
          (version,platform)
!     for base in (_HKEY_CLASSES_ROOT,
!                  _HKEY_LOCAL_MACHINE,
!                  _HKEY_CURRENT_USER,
!                  _HKEY_USERS):
          try:
!             k = _RegOpenKeyEx(base,K)
              i = 0
              while 1:
                  try:
!                     (p,v,t) = _RegEnumValue(k,i)
                      if string.upper(p) == path:
                          V = string.split(v,';')
                          for v in V:
***************
*** 91,99 ****
                              L.append(v)
                          break
                      i = i + 1
!                 except win32api.error:
                      break
!         except win32api.error:
              pass
      return L
  
--- 111,119 ----
                              L.append(v)
                          break
                      i = i + 1
!                 except _RegError:
                      break
!         except _RegError:
              pass
      return L
  


Disclaimer:

I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.

Thomas Heller




From vanandel@ucar.edu  Fri Mar 31 17:04:31 2000
From: vanandel@ucar.edu (Joe Van Andel)
Date: Fri, 31 Mar 2000 10:04:31 -0700
Subject: [Distutils] FreeBSD
References: <sQ1qDJAG+E54EwVg@jessikat.demon.co.uk>
Message-ID: <38E4DA9F.ABC9A035@atd.ucar.edu>

Robin Becker wrote:
> 
> I'm trying to port stuff from Win32 to FreeBSD. Distutils is fine with
> win32, but can I use it with freebsd? I notice that earlier methods used
> a universal makefile and Setup.in and involved a lot of technology ie
> libtool etc etc

I use distutils on Linux and it works fine for building extensions to
Python.  Since distutils uses Python code, and doesn't rely on make or
libtools, I think it should work fine on FreeBSD.

I don't think distutils is going to replace 'make' for general
development in the immediate future, but it works great for building
Python extensions.


-- 
Joe VanAndel  	          
National Center for Atmospheric Research
http://www.atd.ucar.edu/~vanandel/
Internet: vanandel@ucar.edu


From jlj@cfd1.cfdrc.com  Fri Mar 31 17:41:03 2000
From: jlj@cfd1.cfdrc.com (Lyle Johnson)
Date: Fri, 31 Mar 2000 11:41:03 -0600
Subject: [Distutils] Will Distutils-1.0 be available outside of Python 1.6?
Message-ID: <002301bf9b38$49466fd0$4e574dc0@coltrane.cfdrc.com>

I saw the announcement a few days back about the Distutils CVS tree being
merged back into the Python 1.6 CVS tree. I was wondering if the plans for
"Distutils-1.0" include:

 (1) it being available as a separate package, and,
 (2) compatibility with Python 1.5.2.

I'm still testing against the Distutils-0.1.3 drop, which of course meets
both of the above requirements. But I wasn't sure how to proceed with
regards to looking at the more recent snapshot(s) and/or the CVS version of
Distutils. I am anticipating that *some* of my end-users will not
immediately upgrade to Python 1.6 when it is released, and I don't want to
make that a requirement since the extension code itself (i.e. my stuff)
doesn't require Python 1.6.