From Phil.Rittenhouse@dspfactory.com  Tue Aug  6 12:26:15 2002
From: Phil.Rittenhouse@dspfactory.com (Phil Rittenhouse)
Date: Tue Aug  6 11:26:15 2002
Subject: [Distutils] Installing without administrator privileges
Message-ID: <OF7E8D9DF7.046F4F3F-ON85256C0D.0050168E@dspfactory.com>

Hi all,

I encountered the following problem when trying to install a package I had
generated
with distutils:

When the installer was run, it would go through the steps nicely, but
towards the end, it
generated two errors:
        "Could not open key
Software\Microsoft\Windows\CurrentVersion\Uninstall"
        "Could not create key  dsp-py2.1"

At first I thought the problem might be the result of installing Python as
Administrator, and the
package as just a user, so I re-installed Python as a user, but I still got
the same error.  I ran
my test on Win2K with both Python 2.1 and 2.2, and I always got the same
result.

I tracked the code generating the error to install.c in
distutils-1.0.2/misc (see below).
I did some digging and it appears that to use KEY_ALL_ACCESS, the code must
be running
with Administrator privileges.   I checked the CVS archives to see if
KEY_ALL_ACCESS is
still being used, and it hasn't been changed.

I made the following changes to install.c (from Distutils 1.0.2),
recompiled, and it  works now.

796c796
<                         KEY_CREATE_SUB_KEY,
---
>                         KEY_ALL_ACCESS,
806c806
<                           KEY_WRITE,
---
>                           KEY_ALL_ACCESS,
1177c1177
<                KEY_WRITE,
---
>                KEY_ALL_ACCESS,
1208c1208
<                KEY_WRITE,
---
>                KEY_ALL_ACCESS,


I chose KEY_CREATE_SUB_KEY for the open, since that is the only operation
that will be performed
on it.   For the new key itself, I chose KEY_WRITE, since that was also the
minimal operation.  While I
was at it, I changed the code for deleting the registry key and value to
also use the minimal KEY_WRITE.
The last two changes allowed the uninstaller to work properly when run as a
normal user.


I'm no expert on distutils or the registry, so please let me know if I've
missed something obvious.

Thanks!
Phil


------------  install.c  ------------------------
<SNIP>
  result = RegOpenKeyEx(HKEY_LOCAL_MACHINE,
                 KeyName,
                 0,
                 KEY_ALL_ACCESS,
                 &hKey);

    if (result != ERROR_SUCCESS)
     MessageBox(GetFocus(), "Could not open key", KeyName, MB_OK);

    sprintf(buffer, "%s-py%d.%d", meta_name, py_major, py_minor);

    result = RegCreateKeyEx(hKey, buffer,
                   0, NULL, 0,
                   KEY_ALL_ACCESS,
                   NULL,
                   &hSubkey,
                   &disposition);

    if (result != ERROR_SUCCESS)
     MessageBox(GetFocus(), "Could not create key", buffer, MB_OK);
<SNIP>
--------------------------------------------------------------------




From robin@jessikat.fsnet.co.uk  Tue Aug  6 12:55:01 2002
From: robin@jessikat.fsnet.co.uk (Robin Becker)
Date: Tue Aug  6 11:55:01 2002
Subject: [Distutils] build_clib
Message-ID: <U7+U5fADD$T9EwE4@jessikat.demon.co.uk>

Would it be a good idea to allow for extra_compile_arg(ument)s in the build_clib
command. I find I need this when I want to compile with symbols, 
but don't want full debugging.

I think that this can be done using something like

        extra_args = build_info.get('extra_compile_args',[])
        if os.environ.has_key('CFLAGS'):
        extra_args.extend(string.split(os.environ['CFLAGS']))
        objects = self.compiler.compile(sources,
                                output_dir=self.build_temp,
                                macros=macros,
                                include_dirs=include_dirs,
                                debug=self.debug,
                                extra_postargs=extra_args)

near line 225 in build_clib.
-- 
Robin Becker


From fasching@design.lbl.gov  Thu Aug 15 04:46:55 2002
From: fasching@design.lbl.gov (Damon Fasching)
Date: Thu Aug 15 03:46:55 2002
Subject: [Distutils] Is there a good way to change compiler options yet?
Message-ID: <Pine.SOL.3.96.1020815001723.2580A-100000@design.lbl.gov>

Hi,

This topic has come up before...but the thread from April 2001 may no
longer be authoritative (though it is consistent with Greg's comments in
unixccompiler.py), and Albert's posting from April 2002 did not get a
response, so here it is again.  Is there a way to override the default 
compiler options used by distutils when building a C extension module...or 
should I try Marc's hack from April 2001?

I've tried a couple of things.  To turn off debug I tried making a
setup.cfg with

[build]
debug=0

but -g is still passed to the compiler...failure. (What should those lines
do in the .cfg file if not turn off debug info?)

Even if this had helped, it would not have helped twiddle the opt level,
which I also would like to do, because there is no --blah option to build
corresponding to optimization.  Sooo, to turn off optimization, I tried
adding a

extra_compile_args=["-O0"]

directive to my setup Extension command.  That, unfortunately, did not
remove the original optimization option which distutils was giving to the
compiler.  It did, however, add a -O0 to the end of the compile command.

This suggests a possible very simple solution, unless I am completely
missing something, which is likely the case...

How about having distutils pass NO default arguments to the compiler?
Then, extra_compile_args could be used to define whatever options are
desired.

Thanks for your wisdom,
 Damon

---------

May the lights in The Land of Plenty
  shine on the Truth some day		L Cohen



From eric@aquameta.com  Fri Aug 16 12:20:03 2002
From: eric@aquameta.com (Eric Hanson)
Date: Fri Aug 16 11:20:03 2002
Subject: [Distutils] 4Suite bcpp build looking for WinMain
Message-ID: <20020816151923.A91857@aquameta.com>

Hi,

I'm building 4suite on Windows98 using Borland's free compiler v5.5.
I converted the Python22.lib to python22_bcpp.lib with coff2omf, and now
here's what I'm getting.

C:\home\eric\4Suite>python setup.py build --compiler=bcpp
developer mode enabled (CVS directory found)
running build
running build_py
running build_ext
--SNIP WARNINGS--
Warning W8004 Ft\Server\Server\Drivers\Postgres\escapeandsplit.c 180:
'dict' is assigned a value that is never used in function 
initEscapeAndSplitcrunning build_scripts
build\temp.win32-2.2\scripts\4odb.c:
Warning W8004 build\temp.win32-2.2\scripts\4odb.c 16: 'i' is assigned a
value that is never used in function main
Error: Unresolved external 'WinMain' referenced from
C:\BCC55\LIB\C0W32.OBJ
error: command 'ilink32.exe' failed with exit status 2

Any ideas what might be wrong?  It's like it thinks it's a Windows
application, but I tried adding the -TC flag to bcppcompiler.py in the
self.compile_options, no dice.

Regards,
Eric
-- 
Eric Hanson
eric@aquameta.com
http://www.aquameta.com/~eric/



From jeremy.kloth@fourthought.com  Fri Aug 16 13:48:01 2002
From: jeremy.kloth@fourthought.com (Jeremy Kloth)
Date: Fri Aug 16 12:48:01 2002
Subject: [Distutils] 4Suite bcpp build looking for WinMain
References: <20020816151923.A91857@aquameta.com>
Message-ID: <001d01c24544$7b5b7840$1a01a8c0@zeus>

Eric Hanson wrote:
> running build_scripts
> build\temp.win32-2.2\scripts\4odb.c:
> Warning W8004 build\temp.win32-2.2\scripts\4odb.c 16: 'i' is assigned
> a value that is never used in function main
> Error: Unresolved external 'WinMain' referenced from
> C:\BCC55\LIB\C0W32.OBJ
> error: command 'ilink32.exe' failed with exit status 2
>
> Any ideas what might be wrong?  It's like it thinks it's a Windows
> application, but I tried adding the -TC flag to bcppcompiler.py in the
> self.compile_options, no dice.
>

Actually, our scripts are Windows applications.  Our build_scripts command
uses .link_executable method on the compilier to create them.  I'd suggest
looking there to see if the correct options are used for building an
application use Borland's tools.  I don't think too many people use that
feature of the compiliers so it could be wrong.

--
Jeremy Kloth
Fourthought, Inc.
http://fourthought.com, http://4suite.org



From eric@aquameta.com  Fri Aug 16 16:26:05 2002
From: eric@aquameta.com (Eric Hanson)
Date: Fri Aug 16 15:26:05 2002
Subject: [Distutils] 4Suite bcpp build looking for WinMain
In-Reply-To: <001d01c24544$7b5b7840$1a01a8c0@zeus>; from jeremy.kloth@fourthought.com on Fri, Aug 16, 2002 at 10:46:33AM -0600
References: <20020816151923.A91857@aquameta.com> <001d01c24544$7b5b7840$1a01a8c0@zeus>
Message-ID: <20020816192457.A17079@aquameta.com>

Jeremy Kloth (jeremy.kloth@fourthought.com) wrote:
> Eric Hanson wrote:
> > running build_scripts
> > build\temp.win32-2.2\scripts\4odb.c:
> > Warning W8004 build\temp.win32-2.2\scripts\4odb.c 16: 'i' is assigned
> > a value that is never used in function main
> > Error: Unresolved external 'WinMain' referenced from
> > C:\BCC55\LIB\C0W32.OBJ
> > error: command 'ilink32.exe' failed with exit status 2
> >
> > Any ideas what might be wrong?  It's like it thinks it's a Windows
> > application, but I tried adding the -TC flag to bcppcompiler.py in the
> > self.compile_options, no dice.
> >
> 
> Actually, our scripts are Windows applications.  Our build_scripts command
> uses .link_executable method on the compilier to create them.  I'd suggest
> looking there to see if the correct options are used for building an
> application use Borland's tools.  I don't think too many people use that
> feature of the compiliers so it could be wrong.

Hmm, still haven't figured it out.  Here's the code you're refering to.

# Now compile and link it
objects = self.compiler.compile([source],
    output_dir=self.build_temp,
    debug=self.debug,
    )
self.compiler.link_executable(objects, progname,
    output_dir=self.build_dir,
    debug=self.debug,
    )

I tried adding the -W flag for a windows target as both a extra_prearg
and extra_postarg in compiler.compile ().  Didn't help.

Here's the link_executable syntax:

link_executable(self, objects, output_progname, output_dir=None,
libraries=None, library_dirs=None, runtime_library_dirs=None, debug=0,
extra_preargs=None, extra_postargs=None) from
distutils.ccompiler.CCompiler

Any ideas?

Thanks,
Eric


From mdehoon@ims.u-tokyo.ac.jp  Sun Aug 18 23:06:32 2002
From: mdehoon@ims.u-tokyo.ac.jp (Michiel Jan Laurens de Hoon)
Date: Sun Aug 18 22:06:32 2002
Subject: [Distutils] How to specify the compiler
Message-ID: <3D6052CF.7080404@ims.u-tokyo.ac.jp>

I am trying to use distutils to install a Python extension module. The 
extension module needs gcc to compile. Unfortunately, on my unix system, 
distutils uses the standard C compiler cc instead of gcc, and the 
compilation fails. The gcc compiler is available on our system; however, 
I don't know how to tell distutils to use gcc instead of cc.

Some people on comp.lang.python have told me that distutils looks for 
the environment variable CC, and uses the corresponding compiler for the 
build process. However, I couldn't get this to work on my Unix system. 
Both set CC=gcc and setenv CC gcc didn't have any effect. Likewise, 
export CC=gcc is ignored on my Cygwin system.

In an effort to get to the bottom of this, I looked at the distutils 
source code. As far as I can tell, distutils calls customize_compiler, 
which calls get_config_vars, which calls _init_posix, which calls 
parse_makefile. This then finds the arguments supplied to 
get_config_vars from the python Makefile. Does anybody know where the 
checks for the environment variables are made? If no such checks are 
made, is this something that should be added to distutils? I am willing 
to spend some time on this to get this working.

Below I copied some output of my trials with distutils.


Thanks in advance,

--Michiel.
University of Tokyo, Human Genome Center


blue{mdehoon}23: set CC=gcc
blue{mdehoon}24: python setup.py build
running build
running build_py
not copying Pycluster/__init__.py (output up-to-date)
running build_ext
building 'Pycluster.cluster' extension
cc -DNDEBUG -O -OPT:Olimit=0 -Iranlib/src -I/usr/local/include/python2.2 
-c cluster.c -o build/temp.irix64-6.5-2.2/cluster.o

... and so on

With setenv CC gcc, I get the same result:

blue{mdehoon}6: setenv CC gcc
blue{mdehoon}7: python setup.py build
running build
running build_py
not copying Pycluster/__init__.py (output up-to-date)
running build_ext
building 'Pycluster.cluster' extension
cc -DNDEBUG -O -OPT:Olimit=0 -Iranlib/src -I/usr/local/include/python2.2 
-c clus
ter.c -o build/temp.irix64-6.5-2.2/cluster.o
... and so on.

I have tried export CC=bcc32 before on Cygwin, just to see what would 
happen, but that also got ignored by distutils:

mdehoon@GINSENG ~/Cluster-1.01
$ export CC=bcc32

mdehoon@GINSENG ~/Cluster-1.01
$ bcc32 -v
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
Error E2266: No file names given

mdehoon@GINSENG ~/Cluster-1.01
$ python setup.py build
running build
running build_py
creating build
creating build/lib.cygwin-1.3.12-i686-2.2
creating build/lib.cygwin-1.3.12-i686-2.2/Pycluster
copying Pycluster/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/Pycluster
running build_ext
building 'Pycluster.cluster' extension
creating build/temp.cygwin-1.3.12-i686-2.2
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT 
-Iranlib/src -I/usr/include/python2.2 -c cluster.c -o 
build/temp.cygwin-1.3.12-i686-2.2/cluster.o
... and so on




From pearu@cens.ioc.ee  Mon Aug 19 04:13:02 2002
From: pearu@cens.ioc.ee (Pearu Peterson)
Date: Mon Aug 19 03:13:02 2002
Subject: [Distutils] How to specify the compiler
In-Reply-To: <3D6052CF.7080404@ims.u-tokyo.ac.jp>
Message-ID: <Pine.LNX.4.21.0208191005340.15171-100000@cens.kybi>

Hi,

I have used the following hack to replace gcc with g++ in my setup.py 
files. You can easily change it to you needs, I believe.

Pearu

#+++HACK: replace linker gcc with g++ +++++++++++
disable_opt = 0
gcc_exe = 'gcc'
gpp_exe = 'g++'

from distutils import sysconfig
save_init_posix = sysconfig._init_posix
def my_init_posix():
    save_init_posix()
    g = sysconfig._config_vars
    for n,r in [('LDSHARED',gpp_exe),('CC',gcc_exe)]:
        if g[n][:3]=='gcc':
            print 'my_init_posix: changing %s = %r'%(n,g[n]),
            g[n] = r+g[n][3:]
            print 'to',`g[n]`
    if disable_opt and g['OPT'][:15]=='-DNDEBUG -g -O3':
        print 'my_init_posix: changing OPT =',`g['OPT']`,
        g['OPT'] = ' -DNDEBUG -g '+g['OPT'][15:]
        print 'to',`g['OPT']`
sysconfig._init_posix = my_init_posix

#++++++++++++++++++++++++



From R.Liebscher@gmx.de  Mon Aug 19 05:06:02 2002
From: R.Liebscher@gmx.de (Rene Liebscher)
Date: Mon Aug 19 04:06:02 2002
Subject: [Distutils] How to specify the compiler
References: <3D6052CF.7080404@ims.u-tokyo.ac.jp>
Message-ID: <3D60A775.523E0E06@gmx.de>

see below for comments.

Michiel Jan Laurens de Hoon wrote:
> 
> I am trying to use distutils to install a Python extension module. The
> extension module needs gcc to compile. Unfortunately, on my unix system,
> distutils uses the standard C compiler cc instead of gcc, and the
> compilation fails. The gcc compiler is available on our system; however,
> I don't know how to tell distutils to use gcc instead of cc.
> 
> Some people on comp.lang.python have told me that distutils looks for
> the environment variable CC, and uses the corresponding compiler for the
> build process. However, I couldn't get this to work on my Unix system.
> Both set CC=gcc and setenv CC gcc didn't have any effect. Likewise,
> export CC=gcc is ignored on my Cygwin system.
> 
> In an effort to get to the bottom of this, I looked at the distutils
> source code. As far as I can tell, distutils calls customize_compiler,
> which calls get_config_vars, which calls _init_posix, which calls
> parse_makefile. This then finds the arguments supplied to
> get_config_vars from the python Makefile. Does anybody know where the
> checks for the environment variables are made? If no such checks are
> made, is this something that should be added to distutils? I am willing
> to spend some time on this to get this working.
> 
> Below I copied some output of my trials with distutils.
> 
> Thanks in advance,
> 
> --Michiel.
> University of Tokyo, Human Genome Center
> 
> blue{mdehoon}23: set CC=gcc
> blue{mdehoon}24: python setup.py build
> running build
> running build_py
> not copying Pycluster/__init__.py (output up-to-date)
> running build_ext
> building 'Pycluster.cluster' extension
> cc -DNDEBUG -O -OPT:Olimit=0 -Iranlib/src -I/usr/local/include/python2.2
> -c cluster.c -o build/temp.irix64-6.5-2.2/cluster.o
> 
> ... and so on
> 
> With setenv CC gcc, I get the same result:
> 
> blue{mdehoon}6: setenv CC gcc
> blue{mdehoon}7: python setup.py build
> running build
> running build_py
> not copying Pycluster/__init__.py (output up-to-date)
> running build_ext
> building 'Pycluster.cluster' extension
> cc -DNDEBUG -O -OPT:Olimit=0 -Iranlib/src -I/usr/local/include/python2.2
> -c clus
> ter.c -o build/temp.irix64-6.5-2.2/cluster.o
> ... and so on.
> 
Distuitls use always the compiler used for compilation of Python.
It reads it from the Python Makefile, if I remember right. 
And it get there also the compiler options.
So a possible solution would be create an script called cc, put in your
PATH
and try it this way.
This script has then to call your prefered compiler and possibly also
modify
the compiler options if necessary.


> I have tried export CC=bcc32 before on Cygwin, just to see what would
> happen, but that also got ignored by distutils:
> 
On Windows to use Borland's Compiler try 

python setup.py build --compiler=bcpp


From Jack.Jansen@cwi.nl  Mon Aug 19 06:11:02 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Mon Aug 19 05:11:02 2002
Subject: [Distutils] How to specify the compiler
In-Reply-To: <3D60A775.523E0E06@gmx.de>
Message-ID: <9624E70A-B353-11D6-886C-0030655234CE@cwi.nl>

On Monday, August 19, 2002, at 10:08 , Rene Liebscher wrote:
> Distuitls use always the compiler used for compilation of Python.
> It reads it from the Python Makefile, if I remember right.
> And it get there also the compiler options.
> So a possible solution would be create an script called cc, put in your
> PATH
> and try it this way.

Note that you aree living dangerously if you're pulling trics like this. 
Mixing object files generated by gcc with object files generated with cc 
isn't guaranteed to work, that's one of the reasons distutils picks the 
same compiler as  was used to build Python itself.

If you must absolutely use gcc the best solution is probably to rebuild 
Python with gcc.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From hinsen@cnrs-orleans.fr  Mon Aug 19 06:41:02 2002
From: hinsen@cnrs-orleans.fr (Konrad Hinsen)
Date: Mon Aug 19 05:41:02 2002
Subject: [Distutils] How to specify the compiler
In-Reply-To: <9624E70A-B353-11D6-886C-0030655234CE@cwi.nl>
References: <9624E70A-B353-11D6-886C-0030655234CE@cwi.nl>
Message-ID: <m3fzxb8a37.fsf@chinon.cnrs-orleans.fr>

Jack Jansen <Jack.Jansen@cwi.nl> writes:

> Note that you aree living dangerously if you're pulling trics like
> this. Mixing object files generated by gcc with object files generated
> with cc isn't guaranteed to work, that's one of the reasons distutils

For plain C (not C++) that should work, as gcc uses the calling
conventions of the native C compiler. And under Linux, where gcc is
"native", other compilers proudly announce gcc linking compatibility.

While there remains a small risk of incompatibility, I would like to
see some straightforward way to change compilers as well. For example,
I would like to try Intel's new C compiler for Linux on some modules,
but I haven't done so yet because it's too much work either to
recompile Python (and all add-on packages) or to work around
distutils.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------


From pete@shinners.org  Mon Aug 19 11:48:02 2002
From: pete@shinners.org (Pete Shinners)
Date: Mon Aug 19 10:48:02 2002
Subject: [Distutils] help with gcc-3.1
Message-ID: <3D6104BC.2060501@shinners.org>

apparantly one of my modules in pygame doesn't work correctly with gcc-3.1 
unless it has a special "-lgcc_s" added to the linker. is there any way i 
can detect this through the compiler classes?

i'm guessing the only way is to pipe "gcc --version" and parse the result, 
but i wanted to check in first. any ideas? perhaps i will only do this test 
if $CC is undefined?






From mats@laplaza.org  Mon Aug 19 12:32:05 2002
From: mats@laplaza.org (Mats Wichmann)
Date: Mon Aug 19 11:32:05 2002
Subject: [Distutils] help with gcc-3.1
In-Reply-To: <3D6104BC.2060501@shinners.org>
Message-ID: <5.1.0.14.1.20020819092536.01e8c278@204.151.72.2>

At 07:46 AM 8/19/2002 -0700, Pete Shinners wrote:
 >apparantly one of my modules in pygame doesn't work correctly with gcc-3.1
 >unless it has a special "-lgcc_s" added to the linker. is there any way i
 >can detect this through the compiler classes?


Hmmm.  The use of certain bits of C++ that triggers this need
should be detected by gcc.  I've usually found the problem to
be the inverse one: compiling with gcc 3.x may inntroduce an
unexpected dependency on libgcc_s making the binary somewhat
less portable as it won't run on a system without a libgcc_s.
It's a nasty hack but apparently necessary to get correct behavior...

Although now that I think further about it, it's not clear that
the automatic behavior I mention above would be triggered by
the linking of a shared library, if that's the way the
module is presented.



From thomas.heller@ion-tof.com  Tue Aug 20 11:21:01 2002
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Tue Aug 20 10:21:01 2002
Subject: [Distutils] Installing without administrator privileges
References: <OF7E8D9DF7.046F4F3F-ON85256C0D.0050168E@dspfactory.com>
Message-ID: <04a601c24854$afb96210$e000a8c0@thomasnotebook>

> I encountered the following problem when trying to install a package I had
> generated
> with distutils:
> 
> When the installer was run, it would go through the steps nicely, but
> towards the end, it
> generated two errors:
>         "Could not open key
> Software\Microsoft\Windows\CurrentVersion\Uninstall"
>         "Could not create key  dsp-py2.1"
Phil,

I have no time to look after thiis right now.
But it will definitely by addressed (there are also some
other problems with bdist_wininst and the registry).
I suggest you file a bug report on SF and assign it to me.

Thanks,

Thomas


From seefeld@sympatico.ca  Thu Aug 22 00:07:15 2002
From: seefeld@sympatico.ca (Stefan Seefeld)
Date: Wed Aug 21 23:07:15 2002
Subject: [Distutils] distutils and extension modules
Message-ID: <3D6454B3.7070901@sympatico.ca>

hi there,

I'm pondering to migrate a python based package
from autotools/make to python's distutils. Now
I'm having difficulties setting up the build step
of one C++ based extension module it contains:

The sources for that particular module contain
three directories 'occ/', 'syn/', 'ucpp/', and
with the old build system the temporary object
files are compiled right into them, next to the
respective source files.

With the distutils I can't figure out how to tell
the compiler to put the object files into separate
places.
Unfortunately, some filenames in the above directories
clash (for example 'occ/hash.cc' and 'ucpp/hash.c' both
compile to 'hash.o'), so compiling the objects into a
single place isn't an option.

What can I do ?

Thanks a lot,
         Stefan

PS: and, while we are at it, is there a way to specify
     compiler options (macros, at least) per source file,
     instead of per extension module ?



From gward@python.net  Fri Aug 23 10:24:02 2002
From: gward@python.net (Greg Ward)
Date: Fri Aug 23 09:24:02 2002
Subject: [Distutils] Re: distutils and C++ extensions
In-Reply-To: <3D662809.2070702@sympatico.ca>
References: <3D662809.2070702@sympatico.ca>
Message-ID: <20020823132343.GA3790@cthulhu.gerg.ca>

On 23 August 2002, Stefan Seefeld said:
> I'v mailed to various related newsgroups/mailing lists
> but nobody answered, so please excuse for the intrusion.

Did you try distutils-sig@python.org?  That's where I send people with
distutils questions, but if you already tried there...

> I'v some trouble setting up a setup.py script for an
> extension module which I want to port from a autotools
> based build system to distutils. The module consists of
> various subdirectories, each with a set of files. The
> problem is:
> 
> * some of the names clash (i.e. syn/hash.cc and ucpp/hash.c),
>   i.e. the way distutils works compiles different source files
>   to the same object file. I can't find a way to instruct
>   distutils to change the output file name (or directory) per
>   file

That shouldn't happen.  As I recall, distutils should compile C/C++
source as follows:

  syn/hash.cc     ->    build/temp.$plat/syn/hash.o
  ucpp/hash.c     ->    build/temp.$plat/ucpp/hash.o

(where $plat is eg. "linux-i686-2.1", ie. the OS, hardware, and Python
version).

If that's not happening, it's a bug.

> * the different subdirectories used to have different Makefiles,
>   thus allowing different macro definitions, etc.
> 
> * different subdirectories use different compilers (gcc vs. g++)
>   and different compiler options

Ouch.

> Is there any way to address these issues with distutils without
> a major hack ?

I don't think so.  I never figured out a good way to handle that stuff,
but I haven't been near the distutils since October 2000.  AFAIK no one
has figured out a good way to handle that stuff.  Sorry.

You might try multiple setup scripts, and then a meta-setup script to
tie them all together.  I think Andrew Kuchling experimented with that
sort of setup when he distutil-ized ZODB; as I recall, it sort-of
worked, but wasn't exactly a stunning success.

        Greg
-- 
Greg Ward - just another Python hacker                  gward@python.net
http://starship.python.net/~gward/
Gee, I feel kind of LIGHT in the head now, knowing I can't make my
satellite dish PAYMENTS!


From seefeld@sympatico.ca  Fri Aug 23 10:36:02 2002
From: seefeld@sympatico.ca (Stefan Seefeld)
Date: Fri Aug 23 09:36:02 2002
Subject: [Distutils] Re: distutils and C++ extensions
References: <3D662809.2070702@sympatico.ca> <20020823132343.GA3790@cthulhu.gerg.ca>
Message-ID: <39492090d41550cd48b5d65ea77d0cdb3d663c94@>

Greg Ward wrote:

>>* some of the names clash (i.e. syn/hash.cc and ucpp/hash.c),
>>  i.e. the way distutils works compiles different source files
>>  to the same object file. I can't find a way to instruct
>>  distutils to change the output file name (or directory) per
>>  file
> 
> 
> That shouldn't happen.  As I recall, distutils should compile C/C++
> source as follows:
> 
>   syn/hash.cc     ->    build/temp.$plat/syn/hash.o
>   ucpp/hash.c     ->    build/temp.$plat/ucpp/hash.o
> 
> (where $plat is eg. "linux-i686-2.1", ie. the OS, hardware, and Python
> version).
> 
> If that's not happening, it's a bug.

ok, it's a bug. Should I file it somewhere ? I may even try to fix it...

>>* the different subdirectories used to have different Makefiles,
>>  thus allowing different macro definitions, etc.
>>
>>* different subdirectories use different compilers (gcc vs. g++)
>>  and different compiler options
> 
> 
> Ouch.
> 
> 
>>Is there any way to address these issues with distutils without
>>a major hack ?
> 
> 
> I don't think so.  I never figured out a good way to handle that stuff,
> but I haven't been near the distutils since October 2000.  AFAIK no one
> has figured out a good way to handle that stuff.  Sorry.

well, it doesn't look very difficult to me. All that is necessary is 
some extension substructure. Instead of describing an extension module
by a single 'Extension' tuple of options (i.e. source files + options 
how to compile time), an extension should contain a list of 'extension
components'. Each component then contains what 'Extension' now contains,
and the module is linked by linking all the objects from all these 
components together. It's just one more indirection, doesn't look too
hard to implement. What do you think ?

> You might try multiple setup scripts, and then a meta-setup script to
> tie them all together.  I think Andrew Kuchling experimented with that
> sort of setup when he distutil-ized ZODB; as I recall, it sort-of
> worked, but wasn't exactly a stunning success.

see above, I think my proposition is similar, but addresses the problem
at a better place.

Let me know what you think, and whether there is a way to make that work
(with backward compatibility and all...)

Best regards,
		Stefan



From gward@python.net  Fri Aug 23 10:55:04 2002
From: gward@python.net (Greg Ward)
Date: Fri Aug 23 09:55:04 2002
Subject: [Distutils] Re: distutils and C++ extensions
In-Reply-To: <39492090d41550cd48b5d65ea77d0cdb3d663c95@>
References: <3D662809.2070702@sympatico.ca> <20020823132343.GA3790@cthulhu.gerg.ca> <39492090d41550cd48b5d65ea77d0cdb3d663c95@>
Message-ID: <20020823135458.GA3997@cthulhu.gerg.ca>

On 23 August 2002, Stefan Seefeld said:
> ok, it's a bug. Should I file it somewhere ? I may even try to fix it...

Yeah, just tested it myself, and you're quite right.  I *thought* I
coded it to mirror the source directory structure in the temp directory.
Either I'm misremembering, or I tried to do it that way and screwed up,
or somebody snuck in and changed the code while I wasn't looking.

File the bug on SourceForge:
  https://sourceforge.net/tracker/?func=add&group_id=5470&atid=105470

Make sure you're logged in -- if you don't have an SF account, you'll
need to get one.

Set category to distutils.

Dunno who you should assign the bug to.  I have an appalling track
record with distutils bugs, so probably not me.

> well, it doesn't look very difficult to me. All that is necessary is 
> some extension substructure. Instead of describing an extension module
> by a single 'Extension' tuple of options (i.e. source files + options 
> how to compile time), an extension should contain a list of 'extension
> components'. Each component then contains what 'Extension' now contains,
> and the module is linked by linking all the objects from all these 
> components together. It's just one more indirection, doesn't look too
> hard to implement. What do you think ?

Sounds sensible on the surface.  Backwards compatibility is crucial: 
existing setup scripts must continue to work with no changes.  Apart
from that tiny constraint, go for it!

Patches should be submitted here:

  https://sourceforge.net/tracker/?func=add&group_id=5470&atid=305470

Again, category=distutils and I don't know who to assign it to.

Thanks!

        Greg
-- 
Greg Ward - programmer-at-big                           gward@python.net
http://starship.python.net/~gward/
MTV -- get off the air!
    -- Dead Kennedys


From seefeld@sympatico.ca  Fri Aug 23 11:04:38 2002
From: seefeld@sympatico.ca (Stefan Seefeld)
Date: Fri Aug 23 10:04:38 2002
Subject: [Distutils] Re: distutils and C++ extensions
References: <3D662809.2070702@sympatico.ca> <20020823132343.GA3790@cthulhu.gerg.ca> <39492090d41550cd48b5d65ea77d0cdb3d663c95@> <20020823135458.GA3997@cthulhu.gerg.ca>
Message-ID: <775732a1eaf5e019de174ffcd4c8757d3d664339@>

Greg Ward wrote:

> File the bug on SourceForge:
>   https://sourceforge.net/tracker/?func=add&group_id=5470&atid=105470
> 
> Make sure you're logged in -- if you don't have an SF account, you'll
> need to get one.
> 
> Set category to distutils.
> 
> Dunno who you should assign the bug to.  I have an appalling track
> record with distutils bugs, so probably not me.

ok, it's filed (assigned to 'nobody').

> 
> 
>>well, it doesn't look very difficult to me. All that is necessary is 
>>some extension substructure. Instead of describing an extension module
>>by a single 'Extension' tuple of options (i.e. source files + options 
>>how to compile time), an extension should contain a list of 'extension
>>components'. Each component then contains what 'Extension' now contains,
>>and the module is linked by linking all the objects from all these 
>>components together. It's just one more indirection, doesn't look too
>>hard to implement. What do you think ?
> 
> 
> Sounds sensible on the surface.  Backwards compatibility is crucial: 
> existing setup scripts must continue to work with no changes.  Apart
> from that tiny constraint, go for it!

ok, I'll have a try next week.

Regards,
		Stefan



From Jack.Jansen@oratrix.com  Fri Aug 23 18:02:01 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Fri Aug 23 17:02:01 2002
Subject: [Distutils] Re: distutils and C++ extensions
In-Reply-To: <775732a1eaf5e019de174ffcd4c8757d3d664339@>
Message-ID: <76235B52-B6DB-11D6-B228-003065517236@oratrix.com>

On vrijdag, augustus 23, 2002, at 04:04 , Stefan Seefeld wrote:
>> Dunno who you should assign the bug to.  I have an appalling track
>> record with distutils bugs, so probably not me.
>
> ok, it's filed (assigned to 'nobody').

I think nobody's track record is as bad as Greg's. Pun intended:-)
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- 
Emma Goldman -



From gward@python.net  Wed Aug 28 16:03:01 2002
From: gward@python.net (Greg Ward)
Date: Wed Aug 28 15:03:01 2002
Subject: [Distutils] Re: A possible Python distutils bug
In-Reply-To: <3D6BE452.5060404@llnl.gov>
References: <3D6BE452.5060404@llnl.gov>
Message-ID: <20020828190202.GB16266@cthulhu.gerg.ca>

On 27 August 2002, Tom Epperly said:
> If you have two Python C extension modules with the same shortname 
> (i.e., the name minus all the package directories), Python distutils 
> won't compile them both correctly.  In my example, I've got

Funny -- someone else reported that same bug last week.  It's filed on
SourceForge here:

  https://sourceforge.net/tracker/index.php?func=detail&aid=599248&group_id=5470&atid=105470

> Do you consider this a bug?

Yes.  Not sure how it came about; I *thought* I coded things the right
way originally, but I could be misremembering.

> If yes, how quickly do you think it can be addressed?

Very quickly as soon as someone finds the cycles.  (Don't look at me!)

        Greg
-- 
Greg Ward      *     gward@python.net     *     www.gerg.ca
All things are possible -- except skiing through a revolving door.