Mailman 3 March 2002 - Distutils-SIG

Installing source distributions on windows
by Thomas Heller 19 Mar '02

19 Mar '02

I've posted a script helping install source distributions (.zip or .tar.gz) on windows. http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/117248 Any comments appreciated. Thomas

1 0

Re: [Distutils] New packagers
by Michael Hudson 06 Mar '02

06 Mar '02

"Thomas Heller" <thomas.heller(a)ion-tof.com> writes: > > It would also be nice if we had a distutils compile farm > > somewhere; oh well, this will probably stay a dream. > > > > I've also thought about this: submit packages (per email, maybe) to > a server somewhere, and the server runs 'setup.py bdist > --formats=whatever', and mails the result back. My question is: Can > this really be made safe? Seems very unlikely. Cheers, M. -- This is not to say C++ = bad, Lisp = good. It's to say C++ = bad irrespective of everything else. -- Alain Picard, comp.lang.lisp

2 1

New packagers
by M.-A. Lemburg 05 Mar '02

05 Mar '02

Marc Alexandar has submitted two new packagers for distutils a while ago. I would like to add these to distutils, however, I can't test them. Solaris: https://sourceforge.net/tracker/?func=detail&aid=415227&group_id=5470&atid=… HP-UX: https://sourceforge.net/tracker/?func=detail&aid=415228&group_id=5470&atid=… Could someone give them a go ? Also, docs are still missing for the packagers -- if someone has a few spare cycles, please add these to the patches. Thanks, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

3 3

Re: [Distutils] specifying headers for an extension
by Michael Hudson 05 Mar '02

05 Mar '02

Achim Gaedke <Achim.Gaedke(a)uni-koeln.de> writes: > I need such things too. > In my case there is the module initialisation in the *module.c file > and some 100 of method definitions in another that is included into > the first. > > It would be nice if setup.py can handle this. There's a bug on sf on this, assigned to me. I'm not likely to get to it soon, I'm afraid. Patches welcome :) Cheers, M. -- ... but I guess there are some things that are so gross you just have to forget, or it'll destroy something within you. perl is the first such thing I have known. -- Erik Naggum, comp.lang.lisp

4 5

Re: [Distutils] specifying headers for an extension
by Michael Hudson 05 Mar '02

05 Mar '02

"Thomas Heller" <thomas.heller(a)ion-tof.com> writes: > > > I can supply a patch if needed. > > > > That's the only way this is going to get done... > Ok, will do. Cool. > > I had some crazy ideas to use "gcc -MMD" to create a database of > > dependencies, so this sort of thing could be done automagically, but > > this is work. > > Even more work than it may seem first, because it has to be done for > other compilers as well... Well, perhaps, but I was thinking that you could just send your package to someone who uses gcc who can then email you the pickled dependency info back... Cheers, M. -- Worryingly, DEFUN appears to be a function that removes all the fun from something: after using it all your code is converted to C++. -- Tim Bradshaw, comp.lang.lisp

1 0

Re: [Distutils] specifying headers for an extension
by Michael Hudson 05 Mar '02

05 Mar '02

"Thomas Heller" <thomas.heller(a)ion-tof.com> writes: > From: "Michael Hudson" <mwh(a)python.net> > > Achim Gaedke <Achim.Gaedke(a)uni-koeln.de> writes: > > > > > I need such things too. > > > > > In my case there is the module initialisation in the *module.c file > > > and some 100 of method definitions in another that is included into > > > the first. > > > > > > It would be nice if setup.py can handle this. > > > > There's a bug on sf on this, assigned to me. I'm not likely to get to > > it soon, I'm afraid. Patches welcome :) > > > IMO we should allow sources to be instances of a SourceFile class > in addition to strings. > > Extension(..., > sources = SourceFile("spam.c", depends=["spam.h", "spam2.h"])) You mean sources = [SourceFile("spam.c", depends=["spam.h", "spam2.h"])]) here, right? > I can supply a patch if needed. That's the only way this is going to get done... I had some crazy ideas to use "gcc -MMD" to create a database of dependencies, so this sort of thing could be done automagically, but this is work. Somebody print "keep it simple, stupid" on a ream of paper and drop it on my head, please? Cheers, M. -- I've even been known to get Marmite *near* my mouth -- but never actually in it yet. Vegamite is right out. UnicodeError: ASCII unpalatable error: vegamite found, ham expected -- Tim Peters, comp.lang.python

2 1

Re: [Distutils] Cygwin to build modules for the Win32 Python2.2 distribution ?
by Michael Hudson 05 Mar '02

05 Mar '02

Gregor Hoffleit <gregor(a)hoffleit.de> writes: > Hi, > > I'm trying to build an extension module for the Python22.exe > distribution from www.python.org. I'm using a current Cygwin environment > and a trivial Distutils setup.py script. > > The build fails, appearently during a sanity check for LONG_BIT. AFAICS, > the failure is due to differences between the VC compiler used for > Python22.exe, and the GCC 2.95.4 using in Cygwin: > > madonna:1> python setup.py build --compiler=cygwin Try --compiler=mingw32. What you have there certainly isn't going to work. Cheers, M. -- I have a feeling that any simple problem can be made arbitrarily difficult by imposing a suitably heavy administrative process around the development. -- Joe Armstrong, comp.lang.functional

1 0

Cygwin to build modules for the Win32 Python2.2 distribution ?
by Gregor Hoffleit 04 Mar '02

04 Mar '02

Hi, I'm trying to build an extension module for the Python22.exe distribution from www.python.org. I'm using a current Cygwin environment and a trivial Distutils setup.py script. The build fails, appearently during a sanity check for LONG_BIT. AFAICS, the failure is due to differences between the VC compiler used for Python22.exe, and the GCC 2.95.4 using in Cygwin: madonna:1> python setup.py build --compiler=cygwin running build running build_ext building 'leapi' extension C:\cygwin\bin\gcc.exe -mcygwin -mdll -O -Wall -I/usr/local/stow/leapi/include -IC:\PROGRAMME\PYTHON22\include -c leapi_wrap.c -o build\temp.win32-2.2\Release\leapi_wrap.o In file included from C:/PROGRAMME/PYTHON22/include/Python.h:59, from leapi_wrap.c:35: C:/PROGRAMME/PYTHON22/include/pyport.h:437: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." error: command 'gcc' failed with exit status 1 Is Distutils supposed to support this situation ? (From what I understand from other mailing lists, it is possible to setup the Cygwin GCC in order to build extensions modules compatible with Python22.exe.) Are there any additional switches to tune Distutils for this situation ? Thanks, Gregor

1 0

Compilation of extension modules
by Florent Rougon 04 Mar '02

04 Mar '02

Hello, I am currently packaging an extension module that uses the glib library. The correct way to compile such a program is: gcc `glib-config --cflags` ... -c ... -o ... That is, the output of "glib-config --cflags" must be near the beginning of the compilation command (it usually contains -I options). I tried to use the extra_compile_args argument to Extension's __init__() method but it only adds arguments to the end of the compilation command. I looked into Distutils' sources and found that the extra_preargs argument to UnixCCompiler.compile() would do the trick, but it can't be set from Extension's __init__() method. When the compile() method is called in build_ext.py, no extra_preargs is passed, so it always gets its default value: None. Currently, I adopted the following "solution": strip the leading -I from each argument output by "glib-config --cflags" and give it as include_dirs to Extension.__init__(). This is somewhat ugly since the output of "glib-config --cflags" could contain arguments that are not include directory specifications. My hack would fail in such cases. Is there a better solution I couldn't see? I searched the mailing-list archive and didn't find anything really satisfactory. If not, could we consider adding the possibility of specifying some-arguments-of-any-kind (not only include dirs of macros or whatever) to be put near the beginning of the compilation command from the setup() call? [ BTW, there is a similar issue with linking, but as `glib-config --libs` is OK at the end of the link command line, extra_link_args does the trick. However, it would be nice to be able to customize the beginning if the link command. ] Thank you for your comments. Here is my current setup.py. -- Florent

1 0