From robin@jessikat.fsnet.co.uk  Fri Dec  1 06:37:01 2000
From: robin@jessikat.fsnet.co.uk (Robin Becker)
Date: Fri Dec  1 06:37:01 2000
Subject: [Distutils] clibs
Message-ID: <msXosJAO04J6Ewe8@jessikat.fsnet.co.uk>

I've managed to get a PIL setup mostly working with the new 
Imaging-1.1.1 but I fail to see how to automate the
libImaging/libImaging build. I see there is a build_clib command, but
how should clibs be specified in the setup.py?

I looked for the sig archives, but got a server down message.
-- 
Robin Becker


From gward@mems-exchange.org  Fri Dec  1 10:15:01 2000
From: gward@mems-exchange.org (Greg Ward)
Date: Fri Dec  1 10:15:01 2000
Subject: [Distutils] Re: [Python-Dev] PEP 229 and 222
In-Reply-To: <014301c05b6e$269716a0$e000a8c0@thomasnotebook>; from thomas.heller@ion-tof.com on Fri, Dec 01, 2000 at 09:10:21AM +0100
References: <200011282213.OAA31146@slayer.i.sourceforge.net> <20001128171735.A21996@kronos.cnri.reston.va.us> <200011282301.SAA03304@cj20424-a.reston1.va.home.com> <20001128215748.A22105@kronos.cnri.reston.va.us> <20001130181438.A21596@ludwig.cnri.reston.va.us> <014301c05b6e$269716a0$e000a8c0@thomasnotebook>
Message-ID: <20001201101452.A26074@ludwig.cnri.reston.va.us>

On 01 December 2000, Thomas Heller said:
> Distutils currently only supports build_*** commands for
> C-libraries and Python extensions.
> 
> Shouldn't there also be build commands for shared libraries,
> executable programs and static Python binaries?

Andrew and I talked about this a bit yesterday, and the proposed
interface is as follows:

    python setup.py build_ext --static

will compile all extensions in the current module distribution, but
instead of creating a .so (.pyd) file for each one, will create a new
python binary in build/bin.<plat>.

Issue to be resolved: what to call the new python binary, especially
when installing it (presumably we *don't* want to clobber the stock
binary, but supplement it with (eg.) "foopython").

Note that there is no provision for selectively building some extensions
as shared.  This means that Andrew's Distutil-ization of the standard
library will have to override the build_ext command and have some extra
way to select extensions for shared/static.  Neither of us considered
this a problem.

> BTW: Distutils-sig seems pretty dead these days...

Yeah, that's a combination of me playing on other things and python.net
email being dead for over a week.  I'll cc the sig on this and see if
this interface proposal gets anyone's attention.

        Greg


From thomas.heller@ion-tof.com  Fri Dec  1 10:46:01 2000
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Fri Dec  1 10:46:01 2000
Subject: [Distutils] Re: [Python-Dev] PEP 229 and 222
References: <200011282213.OAA31146@slayer.i.sourceforge.net> <20001128171735.A21996@kronos.cnri.reston.va.us> <200011282301.SAA03304@cj20424-a.reston1.va.home.com> <20001128215748.A22105@kronos.cnri.reston.va.us> <20001130181438.A21596@ludwig.cnri.reston.va.us> <014301c05b6e$269716a0$e000a8c0@thomasnotebook> <20001201101452.A26074@ludwig.cnri.reston.va.us>
Message-ID: <000701c05bad$c0c68780$e000a8c0@thomasnotebook>

(damn, the original reply was killed by a crash of outlook express.
Have to type it all again).
> On 01 December 2000, Thomas Heller said:
> > Distutils currently only supports build_*** commands for
> > C-libraries and Python extensions.
> > 
> > Shouldn't there also be build commands for shared libraries,
> > executable programs and static Python binaries?
> 
> Andrew and I talked about this a bit yesterday, and the proposed
> interface is as follows:
> 
>     python setup.py build_ext --static
> 
> will compile all extensions in the current module distribution, but
> instead of creating a .so (.pyd) file for each one, will create a new
> python binary in build/bin.<plat>.
> 
What do you mean by 'static'?

On windows, there are three possibilities for extensions to live in:

1. pythonxx.dll (the usual python interpreter)

2. separate shared extension module 'zlib.pyd'

3. python.exe (which loads pythonxx.dll, and call Py_Main)

4. SpecialPython.exe (which has the python interpreter built in
   as well as other extension modules. *ALL* extension modules have
   to be builtin on windows, because backlinking into executables
   does not work!)

1) is what Andrew cares about (on windows), 2) is already handled
by distutils, 3) and 4) is what I am interested in!

> Issue to be resolved: what to call the new python binary, especially
> when installing it (presumably we *don't* want to clobber the stock
> binary, but supplement it with (eg.) "foopython").
> 
> Note that there is no provision for selectively building some extensions
> as shared.  This means that Andrew's Distutil-ization of the standard
> library will have to override the build_ext command and have some extra
> way to select extensions for shared/static.  Neither of us considered
> this a problem.
> 
> > BTW: Distutils-sig seems pretty dead these days...
> 
> Yeah, that's a combination of me playing on other things and python.net
> email being dead for over a week.  I'll cc the sig on this and see if
> this interface proposal gets anyone's attention.
> 

Thomas



From hoel@germanlloyd.org  Fri Dec  1 11:28:01 2000
From: hoel@germanlloyd.org (Berthold =?iso-8859-1?q?H=F6llmann?=)
Date: Fri Dec  1 11:28:01 2000
Subject: [Distutils] module embedding with distutils?
Message-ID: <sed7fcun6o.fsf@pc961225.GermanLloyd.de>

Hello,

How can I say distutils to build a python interpreter with my own
extension module linked statically. I must do some malloc debugging im
my module and want to link dmalloc with the module, but there seems to
be no success, I guess there are some initializations missing. I can't
find any hint in their documentation.

Thanks

Berthold
-- 
       email: hoel@GermanLloyd.org
   )   tel. : +49 (40) 3 61 49 - 73 74
  (
C[_]  These opinions might be mine, but never those of my employer.


From croy@dstc.edu.au  Mon Dec  4 05:44:06 2000
From: croy@dstc.edu.au (Clinton Roy)
Date: Mon Dec  4 05:44:06 2000
Subject: [Distutils] passing swig an include list
Message-ID: <3spuj8xy99.fsf@sunset.dstc.edu.au>

Hello all, 

is there an easy way to pass swig a -I option? Or maybe run the
preprocessor over the main .i file before calling swig on it?

thanks for any insights :)
-- 
Clinton Roy

I speak for me and myself, but not my shadow.


From robin@jessikat.fsnet.co.uk  Mon Dec  4 11:33:01 2000
From: robin@jessikat.fsnet.co.uk (Robin Becker)
Date: Mon Dec  4 11:33:01 2000
Subject: [Distutils] documentation on building cLibs
Message-ID: <Ao5hNuA6b8K6Ewja@jessikat.fsnet.co.uk>

can anyone tell me how to specify a cLib to be built and/or used by one
or more of my c extensions?
-- 
Robin Becker


From calvin@cs.uni-sb.de  Tue Dec  5 12:20:01 2000
From: calvin@cs.uni-sb.de (Bastian Kleineidam)
Date: Tue Dec  5 12:20:01 2000
Subject: [Distutils] Make setup.py work with all versions of Distutils
Message-ID: <Pine.LNX.4.21.0012051815310.26371-100000@earth.cs.uni-sb.de>

Hello developers,

some of you may have noticed that the Distutils allow customized command
classes by inheriting them. This is extremely powerful especially when
it comes to compatibility fixes.

I'll summarize all of my custom functions which will work around a
number of unknown/known/fixed bugs in the Distutils.
If you want to be compatible with older versions of the Distutils, you 
can include them in your setup.py file.


1) Distutils traceback when DISTUTILS_DEBUG is set. This is a known 
   but unfixed bug.
   
   Just override the dump_dirs function in install.py with your own:

from distutils.core import DEBUG
import string

class MyInstall(install):
    def dump_dirs (self, msg):
        if DEBUG:
            from distutils.fancy_getopt import longopt_xlate
            print msg + ":"
            for opt in self.user_options:
                opt_name = opt[0]
                if opt_name[-1] == "=":
                    opt_name = opt_name[0:-1]
                if self.negative_opt.has_key(opt_name):
                    opt_name = string.translate(self.negative_opt[opt_name],
                                                longopt_xlate)
                    val = not getattr(self, opt_name)
                else:
                    opt_name = string.translate(opt_name, longopt_xlate)
                    val = getattr(self, opt_name)
                print "  %s: %s" % (opt_name, val)


2) the 'config' target does not initialize all values. This is a known
   and fixed bug (fixed in version 1.0.1):
   
import string,os
from types import StringType

class MyConfig(config):
    def finalize_options(self):
        """fix up types of option values. This is cut'n'paste from
	   Distutils 1.0.1"""
        if self.include_dirs is None:
            self.include_dirs = self.distribution.include_dirs or []
        elif type(self.include_dirs) is StringType:
            self.include_dirs = string.split(self.include_dirs, os.pathsep)

        if self.libraries is None:
            self.libraries = []
        elif type(self.libraries) is StringType:
            self.libraries = [self.libraries]

        if self.library_dirs is None:
            self.library_dirs = []
        elif type(self.library_dirs) is StringType:
            self.library_dirs = string.split(self.library_dirs, os.pathsep)

3) Use this only if you have man(1) files and you want to build RPM
   packages.
   The bdist_rpm command cannot handle man pages.
   Whats happening here? The rpm command calls
   python setup.py install --root=... --record=INSTALLED_FILES
   In INSTALLED_FILES are now all installed files listed inclusive a
   man page, for example ./usr/man/man1/myprog.1
   But this man page gets compressed by rpm and we have now
   ./usr/man/man1/myprog.1.gz
   This makes subsequent 'rpm' commands fail which are based on the
   filenames found in INSTALLED_FILES.
   
   Below you see a quick and very dirty hack: just append ".gz" to all
   man file names in the INSTALLED_FILES index.
   Of course the proper solution would be to define multiple handler
   classes for all kinds of documentation (man pages, info pages, html
   pages ...). But thats a long way to go.

from types import StringType
import os,re

class LCInstallData(install_data):
    """My own data installer to handle .man pages"""
    def run (self):
        self.mkpath(self.install_dir)
        for f in self.data_files:
            if type(f) == StringType:
                # it's a simple file, so copy it
                if self.warn_dir:
                    self.warn("setup script did not provide a directory for "
                              "'%s' -- installing right in '%s'" %
                              (f, self.install_dir))
                self._install_file(f, self.install_dir)
            else:
                # it's a tuple with path to install to and a list of files
                dir = f[0]
                if not os.path.isabs(dir):
                    dir = os.path.join(self.install_dir, dir)
                elif self.root:
                    dir = change_root(self.root, dir)
                self.mkpath(dir)
                for data in f[1]:
                    self._install_file(data, dir)

    def _install_file(self, filename, dirname):
        (out, _) = self.copy_file(filename, dirname)
        # match for man pages .[0-9]
        if re.search(r'/man/.+\.\d$', out):
            out = out+".gz"
        self.outfiles.append(out)



From mal@lemburg.com  Wed Dec  6 11:59:04 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed Dec  6 11:59:04 2000
Subject: [Distutils] Accessing config.h options ?
Message-ID: <3A2E6FE8.CBC27DEF@lemburg.com>

I'm currently trying to start looking into auto-configuration...
is there a way to access the parsed config.h file from within
the "config" command instance ?

Also, the config class doesn't allow defining macros (e.g. to
enable full __GNU__ support in gcc). Is there a way to define
per-compiler define symbols in the setup() constructor or by 
subclassing compiler classes ?

Thanks,
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company:                                        http://www.egenix.com/
Consulting:                                    http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From mal@lemburg.com  Wed Dec  6 12:01:33 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed Dec  6 12:01:33 2000
Subject: [Distutils] Auto configuration
References: <3A2E6FE8.CBC27DEF@lemburg.com>
Message-ID: <3A2E7065.A9B628A2@lemburg.com>

How can I enable running the "config" command prior to
all "build" commands ?

Thanks,
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company:                                        http://www.egenix.com/
Consulting:                                    http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From calvin@cs.uni-sb.de  Wed Dec  6 12:33:00 2000
From: calvin@cs.uni-sb.de (Bastian Kleineidam)
Date: Wed Dec  6 12:33:00 2000
Subject: [Distutils] Auto configuration
In-Reply-To: <3A2E7065.A9B628A2@lemburg.com>
Message-ID: <Pine.LNX.4.21.0012061827220.25637-100000@earth.cs.uni-sb.de>

>How can I enable running the "config" command prior to
>all "build" commands ?
Suppose your custom "config" command writes out a file "configdata". When
running the install command you can check if this file exists and if not
raise an exception which demands to run "python setup.py config":

class MyDistribution(Distribution):
    def __init__(self, attrs=None):
        Distribution.__init__(self, attrs=attrs)
        self.config_file = "configdata"

    def run_commands(self):
        if "config" not in self.commands:
            if not os.path.exists(self.config_file):
                raise SystemExit, "please run 'python setup.py config'"
        Distribution.run_commands(self)

class MyConfig(config):
    def run(self):
        # ... write "configdata" file 


Bastian



From mal@lemburg.com  Wed Dec  6 13:57:01 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed Dec  6 13:57:01 2000
Subject: [Distutils] Auto configuration
References: <Pine.LNX.4.21.0012061827220.25637-100000@earth.cs.uni-sb.de>
Message-ID: <3A2E8B88.8DE87695@lemburg.com>

Bastian Kleineidam wrote:
> 
> >How can I enable running the "config" command prior to
> >all "build" commands ?
> Suppose your custom "config" command writes out a file "configdata". When
> running the install command you can check if this file exists and if not
> raise an exception which demands to run "python setup.py config":
> 
> class MyDistribution(Distribution):
>     def __init__(self, attrs=None):
>         Distribution.__init__(self, attrs=attrs)
>         self.config_file = "configdata"
> 
>     def run_commands(self):
>         if "config" not in self.commands:
>             if not os.path.exists(self.config_file):
>                 raise SystemExit, "please run 'python setup.py config'"
>         Distribution.run_commands(self)
> 
> class MyConfig(config):
>     def run(self):
>         # ... write "configdata" file

Thanks for the example. What I was thinking of is a little
different though: I have a configuration class which will
do some environment testing in order to determine flags
and options for the build_ext class. Now in order to have
this information available before the build I need to 
assure that the config command is executed before the
build step.

After some hacking I found that the following trick enables
this:

from distutils.command.config import config
from distutils.command.build import build

class autoconf(config):

    def run(self):

	...config code...
        build_ext = self.distribution.reinitialize_command('build_ext')
        # Set options
        build_ext.define = mydefines

class autoconf_build(build):

    def run(self):

        self.run_command('autoconf')
        build.run(self)

and then in setup():

       cmdclass = {'autoconf': autoconf,
                   'build': autoconf_build},

With this setup you can execute "setup.py bdist_rpm" and the
autoconf command will get executed automatically or you can
run "setup.py autoconf --autoconf-option build" to pass
additional options to the autoconf command. 

Unfortunately, bdist_rpm doesn't seem to inherit the command
options you passed to the setup.py script -- the build is
done in a separate process which is invoked by RPM rather
than from the original setup.py process.

Thanks,
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company:                                        http://www.egenix.com/
Consulting:                                    http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From pete@shinners.org  Fri Dec  8 02:48:00 2000
From: pete@shinners.org (Pete Shinners)
Date: Fri Dec  8 02:48:00 2000
Subject: [Distutils] data_files problem
Message-ID: <000901c060eb$b3e6c3c0$0200a8c0@localdomain>

i'm using the "data_files" argument to try and copy
extra files into my installation folder...

setup (name = "pygame",
       ...
       data_files = [['pygame', data_files]]
     )  

my data_files variable is just a list of filenames i want
copied into the package installation directory.


under windows, this is working perfectly. under linux, this
installs my data files to "/usr/pygame". not very good. it
would seem like the windows behaviour would be what is wanted.

is there any way i can get this working with the current
version of distutils? some sort of "if not sys.platform == 'win32':"
and put the full path into this argument?

is there a way for my distutils script to find the directory
where packages will be installed to? if i knew that i could
get it hacked in on my own.




From paulp@ActiveState.com  Fri Dec  8 17:49:01 2000
From: paulp@ActiveState.com (Paul Prescod)
Date: Fri Dec  8 17:49:01 2000
Subject: [Distutils] Testing
Message-ID: <3A3165F9.171672FF@ActiveState.com>

Should there be a "test" command for distutils? It could test whether a
module was properly built and installed or not.

 Paul


From akuchlin@mems-exchange.org  Fri Dec  8 17:52:01 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Fri Dec  8 17:52:01 2000
Subject: [Distutils] Testing
In-Reply-To: <3A3165F9.171672FF@ActiveState.com>; from paulp@ActiveState.com on Fri, Dec 08, 2000 at 02:51:37PM -0800
References: <3A3165F9.171672FF@ActiveState.com>
Message-ID: <20001208175110.O9944@kronos.cnri.reston.va.us>

On Fri, Dec 08, 2000 at 02:51:37PM -0800, Paul Prescod wrote:
>Should there be a "test" command for distutils? It could test whether a
>module was properly built and installed or not.

Coincidentally this was discussed last Tuesday at a face-to-face
meeting with the Pythoneers, and the opinion was generally "yes".
This arose out of discussion of a unit testing framework, so consensus
would have to be reached on that first -- writing the Distutils "test"
command would then be fairly simple, I think.

--amk



From gustav@morpheus.demon.co.uk  Sat Dec  9 15:53:01 2000
From: gustav@morpheus.demon.co.uk (Paul Moore)
Date: Sat Dec  9 15:53:01 2000
Subject: [Distutils] How do I find out the compiler?
Message-ID: <MGECLEMDOABNHEGBLKFDKENCCEAA.gustav@morpheus.demon.co.uk>

Hi,
I'm writing a setup.py for the DCOracle extension library. As usual, it was
almost trivial :-) But there was one issue which I didn't resolve. The
Oracle client libraries are supplied in two forms, for MSVC and for Borland
C. As I am using MSVC, I set the library_dirs to the MSVC directory. But I
would like to make this portable. For that I need to determine whether the
user is running MSVC or Borland C. How do I do that within setup.py?

Thanks,
Paul Moore



From rasumner@iname.com  Sun Dec 10 15:18:00 2000
From: rasumner@iname.com (Reuben Sumner)
Date: Sun Dec 10 15:18:00 2000
Subject: [Distutils] Compiling with mingw32
Message-ID: <009a01c062e6$0dc6b3e0$a3fd0a0a@rsumner.ilndc.com>

After some work I am happy to report successful compilation of a simple
module using Python 2.0, distutils and mingw32.  If somebody needs the
libpython20.a, I have one which seems to work.

find_config_files in dist.py needed a little tweaking to actually read
pydistutils.cfg from sys.prefix as the doc string had promised.
Incidentally I don't generally put the python DLLs in my path, but just the
python executables.  While most things work fine in this configuration,
sys.prefix is not one of them.

Is there a reason that MANIFEST.in isn't a default file to be included when
making a source distribution?

Reuben



From mfletch@tpresence.com  Mon Dec 11 03:35:01 2000
From: mfletch@tpresence.com (Mike Fletcher)
Date: Mon Dec 11 03:35:01 2000
Subject: [Distutils] Specifying a dependency for rebuilding an extension?
Message-ID: <CC59868A0A76D311B1F50090277B321C1F3738@VRTMAIL>

I've just noticed that with PyOpenGL, changing a source file that's included
by the "declared" source file for an extension doesn't cause the
recompilation of the extension.

i.e.
	_openglmodule.c
	_opengl_nummodule.c # includes _openglmodule.c

The extension only declares _opengl_nummodule.c as a source file.  Is there
some way to declare that the "rule" for the extension should trigger if the
given file has changed?

Is there a better way? Thoughts appreciated,
Mike

__________________________________
 Mike C. Fletcher
 Designer, VR Plumber
 http://members.home.com/mcfletch


From R.Liebscher@gmx.de  Mon Dec 11 03:58:00 2000
From: R.Liebscher@gmx.de (Rene Liebscher)
Date: Mon Dec 11 03:58:00 2000
Subject: [Distutils] Specifying a dependency for rebuilding an extension?
References: <CC59868A0A76D311B1F50090277B321C1F3738@VRTMAIL>
Message-ID: <3A349682.14DE15A5@gmx.de>

Mike Fletcher wrote:
> 
> I've just noticed that with PyOpenGL, changing a source file that's included
> by the "declared" source file for an extension doesn't cause the
> recompilation of the extension.
> 
> i.e.
>         _openglmodule.c
>         _opengl_nummodule.c # includes _openglmodule.c
> 
> The extension only declares _opengl_nummodule.c as a source file.  Is there
> some way to declare that the "rule" for the extension should trigger if the
> given file has changed?

AFAIK there is no way to do so.
But I think it would be easy to add it to distutils.

First we need to extend the Extension class to hold the names
of files on which the extension depends.
(This would mean included c-files, header-files ...)

It could look like this:
Extension(
	sources=["foo.c"], 
	depends_on=["config.h","bar.c"], 
	...
)
or for Mike's example
Extension(
	sources=["_opengl_nummodule.c"], 
	depends_on=["_openglmodule.c"], 
	...
)

Then we had to extend build_ext so it checks these files too.

And if it finds it has to rebuild the extension module
(because these additional dependencies),
build_ext had to set the force flag to the compiler before
calling compile() with it.


Kind regards
Rene Liebscher


From thomas.heller@ion-tof.com  Mon Dec 11 04:22:01 2000
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Mon Dec 11 04:22:01 2000
Subject: [Distutils] Specifying a dependency for rebuilding an extension?
References: <CC59868A0A76D311B1F50090277B321C1F3738@VRTMAIL> <3A349682.14DE15A5@gmx.de>
Message-ID: <013601c06353$bb0cd670$e000a8c0@thomasnotebook>

Rene Liebscher wrote:
> Mike Fletcher wrote:
> > 
> > I've just noticed that with PyOpenGL, changing a source file that's included
> > by the "declared" source file for an extension doesn't cause the
> > recompilation of the extension.
> > 
> > i.e.
> >         _openglmodule.c
> >         _opengl_nummodule.c # includes _openglmodule.c
> > 
> > The extension only declares _opengl_nummodule.c as a source file.  Is there
> > some way to declare that the "rule" for the extension should trigger if the
> > given file has changed?
> 
> AFAIK there is no way to do so.
Correct.

> But I think it would be easy to add it to distutils.
This of course means that it is also easy to add it to the setup-script,
since you can override the distutils commands with your own.
class my_build_ext(distutils.command.build_ext):
      ...

setup(...
      cmdclass = {'build_ext': my_build_ext},
      ...)

> 
> First we need to extend the Extension class to hold the names
> of files on which the extension depends.
> (This would mean included c-files, header-files ...)
> 
> It could look like this:
> Extension(
> sources=["foo.c"], 
> depends_on=["config.h","bar.c"], 
> ...
> )
> or for Mike's example
> Extension(
> sources=["_opengl_nummodule.c"], 
> depends_on=["_openglmodule.c"], 
> ...
> )
IMO better would be to let sources be instances of a SourceFile
class, which would depend on other (Source)files.

Thomas



From phrxy@csv.warwick.ac.uk  Tue Dec 12 11:23:00 2000
From: phrxy@csv.warwick.ac.uk (John J. Lee)
Date: Tue Dec 12 11:23:00 2000
Subject: [Distutils] Extensions with cygwin on Python 2.0
Message-ID: <Pine.SOL.4.30.0012121604310.581-100000@mimosa.csv.warwick.ac.uk>

What is the current situation with building extensions with Distutils on
cygwin with the normal MSVC-built Python 2.0 windows binaries?  I can
build extensions okay (I think) using a makefile, but I'm trying to figure
out how to use Distutils to do the same thing: is cygwin supported at all?

Reading a couple of messages here from a month or two ago about building
Python itself on cygwin, I saw a comment from someone that he didn't know
if cygwin built extensions worked reliably with the normal MSVC python 2.0
binary.  As far as I know, they do, but I take it from the comment that
there isn't any support in Distutils yet?  Does it fit in well with the
existing structure, since it's kind of two platforms in one, if you see
what I mean?  Is it likely to be supported in the near future?

Note that this is using dllwrap -mno-cygwin, which doesn't use any of the
POSIX stuff from cygwin, which would mean you'd have to have cygwin1.dll
to use the extension for no particular reason.  The only reason I'm using
cygwin rather than mingw32 is that it has a convenient command line.

Thanks for any help


John




From R.Liebscher@gmx.de  Wed Dec 13 06:19:01 2000
From: R.Liebscher@gmx.de (Rene Liebscher)
Date: Wed Dec 13 06:19:01 2000
Subject: [Distutils] Extensions with cygwin on Python 2.0
References: <Pine.SOL.4.30.0012121604310.581-100000@mimosa.csv.warwick.ac.uk>
Message-ID: <3A375A38.61ADA82A@gmx.de>

"John J. Lee" wrote:
> 
> What is the current situation with building extensions with Distutils on
> cygwin with the normal MSVC-built Python 2.0 windows binaries?  I can
> build extensions okay (I think) using a makefile, but I'm trying to figure
> out how to use Distutils to do the same thing: is cygwin supported at all?
> 
> Reading a couple of messages here from a month or two ago about building
> Python itself on cygwin, I saw a comment from someone that he didn't know
> if cygwin built extensions worked reliably with the normal MSVC python 2.0
> binary.  As far as I know, they do, but I take it from the comment that
> there isn't any support in Distutils yet?  Does it fit in well with the
> existing structure, since it's kind of two platforms in one, if you see
> what I mean?  Is it likely to be supported in the near future?
Distutils supports cygwin and mingw32 for 6 months or so.

The message you read 
(http://mail.python.org/pipermail/distutils-sig/2000-November/001727.html)
is about compiling the whole python using cygwin. 

> 
> Note that this is using dllwrap -mno-cygwin, which doesn't use any of the
> POSIX stuff from cygwin, which would mean you'd have to have cygwin1.dll
> to use the extension for no particular reason.  The only reason I'm using
> cygwin rather than mingw32 is that it has a convenient command line.

You have to specify 
--compiler=cygwin for cygwin using cygwin1.dll
or
--compiler=mingw32 for cygwin without using cygwin1.dll (or for mingw32)

What you need is a library libpython20.a which serves as import
library for python20.dll.

If you don't want to create this library for your own you may ask Reuben
Sumner
(see
http://mail.python.org/pipermail/distutils-sig/2000-December/001783.html)
for it.


(Greg, it may be a good idea to put this library on the download page of
distutils or python.)


Kind regards
Rene Liebscher


From hoel@germanlloyd.org  Wed Dec 13 09:36:02 2000
From: hoel@germanlloyd.org (Berthold =?iso-8859-1?q?H=F6llmann?=)
Date: Wed Dec 13 09:36:02 2000
Subject: [Distutils] Unix permissions of installed files
Message-ID: <seelzcz94x.fsf@pc961225.GermanLloyd.de>

Hello,

Depending on the users umask settings, or the accress rights of the
files to be installed, users installing software have to invoke chmod
to get access permissions rights corrected for some files. This is
especially true for *.pth files which get no read permissions for
world. This step is often forgotten by the users. Is there a distutils
way to get this right, or do I have to to extend my setuppy's?

Thanks

Berthold
-- 
       email: hoel@GermanLloyd.org
   )   tel. : +49 (40) 3 61 49 - 73 74
  (
C[_]  These opinions might be mine, but never those of my employer.


From pete@wile.visionart.com  Thu Dec 14 14:52:02 2000
From: pete@wile.visionart.com (Pete J Shinners)
Date: Thu Dec 14 14:52:02 2000
Subject: [Distutils] problems on irix
Message-ID: <10012141154.ZM40521@wile.visionart.com>

i am using the distutils that comes with the python2.0 release.
on irix there seems to be a problem with variable name expansion.
all the installations go to funky directories like this...

$platbase/lib/python$py_version_short/site-packages
$base/include/python$py_version_short/$dist_name

this makes it kind of difficult, because i then have to go back
and cp -r these mean paths to where the install should have gone.

btw, my python is installed to /usr/local, so these paths should
be expanding to something like

/usr/local/lib/python2.0/site-packages
/usr/local/include/python2.0

has this been fixed? can it be fixed soon?
thanks


From aa8vb@yahoo.com  Sun Dec 17 08:26:01 2000
From: aa8vb@yahoo.com (Randall Hopper)
Date: Sun Dec 17 08:26:01 2000
Subject: [Distutils] Listing & deinstalling modules
Message-ID: <20001217082512.A1569135@vislab.epa.gov>

I just read the latest inst.pdf (well written BTW), and I have a few questions:
  
  1) How do I list what 3rd-party Python modules have been installed in a
     Python directory via distutils (and their versions)?

  2) How do I remove a particular installed module (e.g. Numeric-16.0), say
     for example, so I can upgrade to the next version without version
     conflicts?

Is there a file where this information is stored on an install?

Randall

-- 
Randall Hopper
aa8vb@yahoo.com


From pearu@ioc.ee  Mon Dec 18 06:39:01 2000
From: pearu@ioc.ee (Pearu Peterson)
Date: Mon Dec 18 06:39:01 2000
Subject: [Distutils] build_ext -L option bug?
Message-ID: <Pine.LNX.4.10.10012181333420.19059-100000@kev.ioc.ee>

Hi!

When I do

$ python setup.py build_ext -L/opt/gmp/lib

on Linux running RH with latest Python 2.0, then I get

Traceback (most recent call last):
  File "setup.py", line 18, in ?
    ext_modules = [ gmpy_ext ]
  File "/opt/Python-2.0/lib/python2.0/distutils/core.py", line 138, in
setup
    dist.run_commands()
  File "/opt/Python-2.0/lib/python2.0/distutils/dist.py", line 829, in
run_commands
    self.run_command(cmd)
  File "/opt/Python-2.0/lib/python2.0/distutils/dist.py", line 849, in
run_command
    cmd_obj.run()
  File "/opt/Python-2.0/lib/python2.0/distutils/command/build_ext.py",
line 225, in run
    self.build_extensions()
  File "/opt/Python-2.0/lib/python2.0/distutils/command/build_ext.py",
line 441, in build_extensions
    build_temp=self.build_temp)
  File "/opt/Python-2.0/lib/python2.0/distutils/ccompiler.py", line 662,
in link_shared_object
    extra_preargs, extra_postargs, build_temp)
  File "/opt/Python-2.0/lib/python2.0/distutils/unixccompiler.py", line
208, in link
    (libraries, library_dirs, runtime_library_dirs) = \
  File "/opt/Python-2.0/lib/python2.0/distutils/ccompiler.py", line 430,
in _fix_lib_args
    library_dirs = list (library_dirs) + (self.library_dirs or [])
TypeError: can only concatenate list (not "string") to list

Is this distutils bug? Or what I am doing wrong?

Thanks,
	Pearu

setup.py contains:

import sys
from distutils.core import setup, Extension

if sys.version.find('MSC')==-1:
    gmpy_ext = Extension('gmpy', sources=['gmpy.c'],
        libraries=['gmp'])
else:
    gmpy_ext = Extension('gmpy', sources=['gmpy.c'],
        include_dirs=['.'])

setup (name = "gmpy",
       version = "0.4",
       description = "GMP-3 to Python-2 interface",
       maintainer = "Alex Martelli",
       maintainer_email = "aleaxit@yahoo.com",
       url = "http://gmpy.sourceforge.net/",
       
       ext_modules = [ gmpy_ext ]
)



From martin@loewis.home.cs.tu-berlin.de  Mon Dec 18 09:00:01 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Mon Dec 18 09:00:01 2000
Subject: [Distutils] Including documentation into a Windows installer
Message-ID: <200012181356.OAA15103@loewis.home.cs.tu-berlin.de>

I'm trying to get a number of files into the binary package which are
considered as documentation.

For RPMs, I simply do

[bdist_rpm]
doc_files = ANNOUNCE,CREDITS,LICENCE,README,README.dom,README.pyexpat,README.sgmlop,doc,demo,test

Even though some of these names are actually directories, the RPM
building process uses the source distribution to determine which files
to include. Specifically, these names get listed as %doc directives,
which are then installed into /usr/doc/<package>.

Since there is no dedicated documentation directory on Windows, I'd
like to put these files into a directory xmldoc next to the _xmlplus
directory which is the Python package. I managed to compute the list
of file names and directories myself using the FileList class.

How can I get a set of files into the Windows installer, while
preserving the directory structure?

Any help appreciated,
Martin


From aa8vb@yahoo.com  Mon Dec 18 09:27:02 2000
From: aa8vb@yahoo.com (Randall Hopper)
Date: Mon Dec 18 09:27:02 2000
Subject: [Distutils] Re: problems on irix
In-Reply-To: <10012141154.ZM40521@wile.visionart.com>; from
 pete@wile.visionart.com on Thu, Dec 14, 2000 at 11:54:19AM -0800
References: <10012141154.ZM40521@wile.visionart.com>
Message-ID: <20001218092619.A1718265@vislab.epa.gov>

Pete J Shinners:
 |i am using the distutils that comes with the python2.0 release.
 |on irix there seems to be a problem with variable name expansion.
 |all the installations go to funky directories like this...
 |
 |$platbase/lib/python$py_version_short/site-packages
 |$base/include/python$py_version_short/$dist_name
...
 |btw, my python is installed to /usr/local, so these paths should
 |be expanding to something like
...
 |has this been fixed? can it be fixed soon?

I'm running Python 2.0 distutils on IRIX with no problems.  Distutils
builds install to the correct directory (the one I installed Python to).
I'm one satisfied customer.  Note that I built with --prefix and
--exec-prefix, but that's probably not relevent.

Do a "which python" (or "whence python" for sh/ksh/bash).  Are you sure
you're running "python setup.py install" using the python binary you think
you are?

Also, run that python and try:

   > python
   Python 2.0 (#2, Nov  1 2000, 12:06:44) [C] on irix646-n32
   Type "copyright", "credits" or "license" for more information.
   >>> import sys
   >>> print sys.prefix
   /home/rhh/software/python2
   >>> print sys.exec_prefix
   /home/rhh/software/python2/PLATFORM/plat-irix646-n32
 
You probably should read:
     http://www.python.org/sigs/distutils-sig/doc/inst.pdf
and check out the --home and --prefix options.  Also read up on config
files.  Sounds like they might be useful to you.

Good luck.

-- 
Randall Hopper
aa8vb@yahoo.com


From thomas.heller@ion-tof.com  Mon Dec 18 10:45:01 2000
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Mon Dec 18 10:45:01 2000
Subject: [Distutils] Including documentation into a Windows installer
References: <200012181356.OAA15103@loewis.home.cs.tu-berlin.de>
Message-ID: <00c701c06909$5a712300$e000a8c0@thomasnotebook>

> I'm trying to get a number of files into the binary package which are
> considered as documentation.
> 
> For RPMs, I simply do
> 
> [bdist_rpm]
> doc_files = ANNOUNCE,CREDITS,LICENCE,README,README.dom,README.pyexpat,README.sgmlop,doc,demo,test
> 
> Even though some of these names are actually directories, the RPM
> building process uses the source distribution to determine which files
> to include. Specifically, these names get listed as %doc directives,
> which are then installed into /usr/doc/<package>.
> 
> Since there is no dedicated documentation directory on Windows, I'd
> like to put these files into a directory xmldoc next to the _xmlplus
> directory which is the Python package. I managed to compute the list
> of file names and directories myself using the FileList class.
> 
> How can I get a set of files into the Windows installer, while
> preserving the directory structure?
The windows installer is similar to the install command.
The install command:
1. Runs build to build everything and install it into build\libxxx directory
2. Copies the build\libxxx directory somewhere into the python path.

The bdist_wininst command:
1. Runs build to build everything and install it into build\libxxx directory.
2. Build a zip-file from the build\libxxx directory, and append this
to the exe-stub to create the windows installer.

The windows installer, on the target system:
Simply unpacks everything on the python path.

So your only choice is to somehow copy your files
into the build directory, and you are done.
Maybe you need to write a special install_docs
class to do this...

Thomas



From martin@loewis.home.cs.tu-berlin.de  Mon Dec 18 12:45:01 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Mon Dec 18 12:45:01 2000
Subject: [Distutils] Including documentation into a Windows installer
In-Reply-To: <00c701c06909$5a712300$e000a8c0@thomasnotebook>
 (thomas.heller@ion-tof.com)
References: <200012181356.OAA15103@loewis.home.cs.tu-berlin.de> <00c701c06909$5a712300$e000a8c0@thomasnotebook>
Message-ID: <200012181739.SAA15807@loewis.home.cs.tu-berlin.de>

> Maybe you need to write a special install_docs class to do this...

Indeed, that is the solution. Rene Liebscher uses an advanced
install_data command for PyOpenGL; I incorporated that into PyXML.

Still, I'd prefer if distutils had direct support for documentation
files, and would always find the right location for them on the
different systems.

Regards,
Martin


From Mike.Olson@fourthought.com  Wed Dec 20 00:12:01 2000
From: Mike.Olson@fourthought.com (Mike Olson)
Date: Wed Dec 20 00:12:01 2000
Subject: [Distutils] Re: 4suite for Mac
References: <3A3F8835.A82E48D4@golden.net> <3A3FA13F.BA29ED41@FourThought.com> <3A403D9B.A18424F4@FourThought.com>
Message-ID: <3A403F81.A25703E4@FourThought.com>

Mike Olson wrote:

I guess I need to go to sleep or something.  I'll try this again.

Sorry for the spam

Mike

> 
> Mike Olson wrote:
> 
> So I go and send it to the wrong address.  Now I will post this message
> to distutils.
> 
> Mike
> 
> >
> > Robert Hahn wrote:
> > >
> > > Hi, guys.
> >
> > Hi Robert,
> >
> >   Thanks for the interest in 4Suite.  However, I'd like to defer your
> > question to python's distutils SIG.  4Suite uses distutils to build its
> > C code, and install itself.  I do try to follow the distutils list
> > (though I sometimes fall behind), and I think I remember someone saying
> > they did some work to get some things to compile on the Mac (thoug not
> > 4Suite).  I'm hoping they pop up and give you some help.  Unfortuatly I
> > haven't used a Mac since the Mac plus line so I won't be too much help.
> >
> > Mike
> >
> > >
> > > I've been looking for a quick way to get XSLT processing for the Mac,
> > > and thought that 4Suite might be the fastest way to go.  I see, however,
> > > that installation isn't straightforward for me. :/
> > >
> > > If we assume that I can compile the bits written in C, then what,
> > > theoretically, has to change in setup.py so that installation would be
> > > flawless.
> > >
> > > Pls. note: I'm new at programming, but am willing to learn.  I've
> > > downloaded Apple's MPW kit (contains a free C compiler), but don't know
> > > how to use it... yet.
> > >
> > > OTOH, if you know of some other XSLT software for the Mac that would
> > > have a lower barrier to use, I would appreciate some leads...
> > >
> > > thx,
> > > Robert Hahn
> >
> > --
> > Mike Olson                               Principal Consultant
> > mike.olson@fourthought.com               (303)583-9900 x 102
> > Fourthought, Inc.                         http://Fourthought.com
> > Software-engineering, knowledge-management, XML, CORBA, Linux, Python
> 
> --
> Mike Olson                               Principal Consultant
> mike.olson@fourthought.com               (303)583-9900 x 102
> Fourthought, Inc.                         http://Fourthought.com
> Software-engineering, knowledge-management, XML, CORBA, Linux, Python

-- 
Mike Olson				 Principal Consultant
mike.olson@fourthought.com               (303)583-9900 x 102
Fourthought, Inc.                         http://Fourthought.com 
Software-engineering, knowledge-management, XML, CORBA, Linux, Python


From pete@shinners.org  Wed Dec 20 02:20:02 2000
From: pete@shinners.org (Pete Shinners)
Date: Wed Dec 20 02:20:02 2000
Subject: [Distutils] error adding library dirs on commandline
Message-ID: <00b601c06a55$c7449960$0200a8c0@localdomain>

on running under windows here. whenever i try to add library directories
to build_ext on the commandline i'm getting an error.

File "c:\python\lib\distutils\command\build_ext.py", line 159, in finalize_options
    self.library_dirs.append(os.path.join(sys.exec_prefix, 'libs'))
AttributeError: append

it turns out that library_dirs is a string type. in build_ext.py
line 143 it looks like the code is checking for strings in
self.libraries. from my quick look it would solve the problem to
also check library_dirs also.

also, the commandline help for -L says to pass all library
directories in a semicolon separated list. when i do this the
self.library_dirs is still just a string containing my list with
the semicolons. (it wouldn't seem like this gets split later on?)

using multiple include paths with the semicolons does appear to
work correctly. although i would probably prefer to allow multiple
-I flags. (currently the 'last' -I flag overrides the previous)


am i correct in guessing these commandline arguments aren't used
too often? i'm thinking i'll just parse -I and -L arguments off
of the commandline myself for now. although i'm also seeking 
better advice :]




From paulp@ActiveState.com  Thu Dec 21 01:49:07 2000
From: paulp@ActiveState.com (Paul Prescod)
Date: Thu Dec 21 01:49:07 2000
Subject: [Distutils] Including documentation into a Windows installer
References: <200012181356.OAA15103@loewis.home.cs.tu-berlin.de> <00c701c06909$5a712300$e000a8c0@thomasnotebook> <200012181739.SAA15807@loewis.home.cs.tu-berlin.de>
Message-ID: <3A41A7DB.2E5F8D8D@ActiveState.com>

"Martin v. Loewis" wrote:
> 
> ....
> 
> Still, I'd prefer if distutils had direct support for documentation
> files, and would always find the right location for them on the
> different systems.

I strongly agree that distutils (and Python) needs first-class support
for extension documentation!

 Paul Prescod


From paulp@ActiveState.com  Thu Dec 21 01:56:02 2000
From: paulp@ActiveState.com (Paul Prescod)
Date: Thu Dec 21 01:56:02 2000
Subject: [Distutils] Bdist_notsodumb
Message-ID: <3A41A993.1C2666B2@ActiveState.com>

I've got this idea and I'd like to have it either shot-down or verified.
The idea is that instead of supporting more and more binary dist
packaging mechanisms, we would distribute Python extensions as a
zipfile. (I choose zip because Python has a standard zipfile module but
I don't think it has a tar module)

In the root directory of the zipfile would be an "install.py". That
would install the module in the Python distribution that it is launched
from. Installing the module would consist of unzipping and running
"install.py". Because install.py would always be in the same place, the
downloading and installing of Python extensions could be automated. The
procedure would be identical on all platforms. The majority of the
infrastructure used by the install scripts could live in Python itself.

In summary, why wouldn't we define a binary structure for Python
extensions rather than worrying about the vagaries of each platform's
package mechanism?

 Paul Prescod


From R.Liebscher@gmx.de  Wed Dec 27 05:37:01 2000
From: R.Liebscher@gmx.de (Rene Liebscher)
Date: Wed Dec 27 05:37:01 2000
Subject: [Distutils] installer does not see current Pythons
Message-ID: <3A49C4D4.270F8A2B@gmx.de>

Any ideas how to solve this, or needs this for
some users a special distribution as zip-file.

> Support Request #110549, was updated on 2000-Dec-22 17:22
> You can respond by visiting: 
> http://sourceforge.net/support/?func=detailsupport&support_id=110549&group_id=5988
> 
> Category: None
> Status: Open
> Priority: 5
> Summary: installer does not see current Pythons
> 
> By: fredy
> Date: 2000-Dec-22 17:22
> 
> Message:
> Logged In: YES 
> user_id=20580
> Browser: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
>
> I downloaded PyOpenGL-1.5.6b1.win32-py1.5.2.exe and 
> executed it on my Windows NT 4.0 machine.  When the 
> installer displays the "select python installation to 
> use" screen it fails to list anything and I am 
> blocked, even though I have both Python 1.5.2 and 1.6 
> installed, along with whatever Python comes with Zope 
> 2.2.  What can I do now to install PyOpenGL?
> 


Kind regards

Rene Liebscher