Mailman 3 November 2000 - Distutils-SIG

bdist_winexe command
by Thomas Heller Nov. 16, 2000

Nov. 16, 2000

I'm currently writing (it is nearly finished) a bdist_wininst command, which is modeled after Gordon's windows installer. This command will create standalone executable exe-files for the win32 platform from the scripts which are specified in the setup script. The exe-file contains all the python modules needed by the script as well as the script itself in a zip-archive appended to a small stub program. The only other file needed is pythonxx.dll in the same directory as the exe-file itself. There is no need that the normal python distribution is installed on the system. Note: In case the script needs extension modules (*.dll or *.pyd files) these are needed as separate files as well, because they cannot be packed into the zip-archive. (Well, they could be packed, but they would have to be extracted before starting the script. This is in fact what Gordon's installer does.) Another note: There will be an option to use another stub, which contains the extensions distributed with python as separate pyd's: _sre, socket, zlib, ... So far, so good. Now for the problems: 1. I intend to distribute this command as a distutils extension. Unfortunately, it's a shame that we cannot use distutils to distribute itself (or additional commands). Distutils would install itself (in windows speak) in c:\Python20\distutils, whereas the stock distutils is located in c:\Python20\lib\distutils. Should there be a special hack in the setup script? 2. Should this command be integrated into distutils? Perhaps it is far too early for this question. 3. I would like to avoid the mistake I made in bdist_wininst, that the stub program's bytes are appended to the text of the bdist_wininst.py file, base64 encoded. So there would be one (or more) binary file winstub.exe somewhere on the file system. Where? distutils\commands\winstub.exe distutils\data\winstub.exe ? Thomas

1 0

distutils 1.0.1 - bdist_rpm- MANIFEST.in recursive-include broken?
by Joe Van Andel Nov. 16, 2000

Nov. 16, 2000

Using distutils 1.0.1 with Python 1.5.2 on Redhat 6.2: I'm trying to build an RPM for my package using distutils. I tried to create 'MANIFEST.in', containing: recursive-include *.py recursive-include *.h recursive-include *.hh recursive-include *.cc recursive-include *.c graft examples prune test global-exclude *~ However, the resulting MANIFEST is missing the include files (*.h), so the necessary files aren't copied to the temporary build directories, and the RPM related compilations fail. I finally built an explicit MANIFEST file that contained all my source code files, and then setup.py bdist_rpm worked. (Of course having to manually build 'MANIFEST' is extra work.) Is there another snapshot in the works, or should I try the CVS version? -- Joe VanAndel National Center for Atmospheric Research http://www.atd.ucar.edu/~vanandel/ Internet: vanandel(a)ucar.edu

4 4

get_platform(), patch for AIX
by Rene Liebscher Nov. 15, 2000

Nov. 15, 2000

The platform string which is build by get_platform() doesnt make much sense. Therefore I provide here a patch which brings up a better string. (eg. for AIX 4.3 -> aix-4.3 not aix-3-XXXXXXXXXXXX , machine seems to be a hardware id ? ) kind regards Rene Liebscher diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/util.py distutils.patchedx/distutils/util.py --- distutils.orig/distutils/util.py Mon Oct 16 11:37:39 2000 +++ distutils.patchedx/distutils/util.py Wed Nov 15 16:21:24 2000 @@ -54,6 +54,8 @@ # fall through to standard osname-release-machine representation elif osname[:4] == "irix": # could be "irix64"! return "%s-%s" % (osname, release) + elif osname[:3] == "aix": + return "%s-%s.%s" % (osname, version, release) return "%s-%s-%s" % (osname, release, machine)

1 0

Distutils filenames
by Jack Jansen Nov. 15, 2000

Nov. 15, 2000

Another problem I ran into with distutils is that while most pathnames follow the local machine convention so do not. More precisely, the source files and such that the package developer put in their setup.py file are passed along unmodified. For now I've put in a heuristic that will convert pathnames from unix-format to mac-format if they contain a / and do not contain a :, but in the long run it's probably better if it's specified in what form pathnames in setup.py should be, and have the core of distutils convert them. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

Re: [Distutils] ccompiler.py for an IDE
by Jack Jansen Nov. 15, 2000

Nov. 15, 2000

> > I'm not sure I understand this. Errors from the compiler will always come up > > in a window, there's no such thing as standard error on the Mac. > > We're having a dimensiinal misunderstanding here: I meant the > wrong place in the time dimension. I wouldn't presume to think > the Mac has something as ordinary as stderr <wink>. No, of course not! Who needs stderr when you can have translucent pulsating buttons, really? :-) But seriously: my intention was to have link() do buth the generation of the project file and the actual build, so the errors would come up at that time (which seems to be the same time as they would come up on other platforms, no?). After the build distutils will take over again to do the install or whatever else it wants to do. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Distutils] ccompiler.py for an IDE
by Jack Jansen Nov. 15, 2000

Nov. 15, 2000

> On Tue, 14 Nov 2000, Jack Jansen wrote: > > > This isn't an option for CodeWarrior (or, at least, it would mean an > > extraordinary amount of work), as the compilers and such are merely > > plugins for the IDE, and everything is driven from the projectfile. > > Couldn't you generate a lot of "small project files" each of which > would compile a single c into a single o, and then one project > file for the link stage? Or is that the extaordinary amount of work? > (On the face of it, it shouldn't be very different then generating > a command line, but then again, I haven't seen a Mac for a few millions > of years). Another option would seem to be to use the Apple version > of COM (sorry, I forgot how they call it) to talk with a persistent > IDE. Wouldn't that work? Or would that be too hard? This is both a lot of work, and possibly hard as well (I don't think there is anything corresponding to the ".obj" file in the normal course of events, so I would have to find some sort of a hack there). > It's probably all right if nothing better comes along, but the problem > is that errors would come up in the wrong place if there are any. I'm not sure I understand this. Errors from the compiler will always come up in a window, there's no such thing as standard error on the Mac. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

ccompiler.py for an IDE
by Jack Jansen Nov. 15, 2000

Nov. 15, 2000

I'm putting together a mwerksccompiler.py module for distutils, for the MetroWerks CodeWarrior compiler on the macintosh. However, I'm running into a bit of a problem: the distutils architecture seems based on calling the compiler and linker and such all by itself, not through an IDE or Makefile or something. Even for MSVC it doesn't generate a project file but calls all the executables by hand. This isn't an option for CodeWarrior (or, at least, it would mean an extraordinary amount of work), as the compilers and such are merely plugins for the IDE, and everything is driven from the projectfile. The solution I'm now thinking of is to let compile() simply stash away the sourcefiles and include dirs and such and do all the work in link(): generate the project file and build it. Is this a feasible idea? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

2 1

Cygwin Python DLL and Shared Extension Patch
by Jason Tishler Nov. 13, 2000

Nov. 13, 2000

Attached is a patch that builds Cygwin Python with its core as a DLL -- similar to the way that one builds Win32 Python. Once Cygwin Python is built as a "shared library" (i.e., DLL), one can build extensions using the same procedure as on other UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. Actually, attached is two versions of the same patch. The first one is the real patch but requires autoconf. The second one was generated after I ran autoconf and hence only requires the more typical build environment. Use the following procedure to patch and build Cygwin Python if you *have* autoconf: $ tar -xvzf Python-2.0.tar.gz $ cd Python-2.0 $ patch -p1 <../CygwinPython-2.0-minimal.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install Use the following procedure to patch and build Cygwin Python if you *do not* have autoconf: $ tar -xvzf Python-2.0.tar.gz $ gunzip CygwinPython-2.0-full.patch.gz $ cd Python-2.0 $ patch -p1 <../CygwinPython-2.0-full.patch $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. My goal is to ultimately submit the patch (redone against Python CVS) to the Python patch collector. I am hoping interested people will help me refine the patch before submittal. The following is an annotated ChangeLog for the patch: Wed Nov 8 23:22:46 2000 Jason Tishler <jt(a)dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? Any feedback is greatly appreciated. Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corporation Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler(a)dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com

2 4

Distutils 1.0.1 releasee
by Greg Ward Nov. 10, 2000

Nov. 10, 2000

Hi all -- I've just released Distutils 1.0.1. This is identical to the code in the last snapshot (20001014). And this is the code that will go out with Python 2.0. Now off to deal with the latest bug reports and feature requests... as if things quiet down just because of a major Python release... oh well... Greg -- Greg Ward gward(a)python.net http://starship.python.net/~gward/

2 4

Re: [Distutils] extra files into the package dir
by Berthold Höllmann Nov. 9, 2000

Nov. 9, 2000

>>>>> "Rene" == Rene Liebscher <R.Liebscher(a)gmx.de> writes: Rene> Pete Shinners wrote: >> i have some extra files i'd like to have copied into the >> destination package directory when installing. >> >> it seems that distutils only installs the .PY(C) files when >> installing a package directory. how can i tell distutils to >> copy my other files too? >> >> does this involve 'extending' the install command? i could >> probably do that if there were docs or an example of something >> like that. >> Rene> I had a similar problem with PyOpenGL. (It needs some data Rene> files for its examples.) May be my solution is what you Rene> need. (At least it could serve as an example.) Rene> Look at the following address: Rene> http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/PyOpenGL/?cvsroot=PyOpenGL Rene> "my_install_data.py" extends distutils' install_data Rene> command. "setup.py" uses then this alternative command. (The Rene> important parts are at the end of this file. One is the Rene> specification of this alternative install command = Rene> "cmdclass" parameter of the setup function. The other is the Rene> "data_files" parameter to the setup function.) There is support for installing data files, but they get to data directories. When writing setup.py for biggles, I had the problem, that a config file had to go to the package directory. All I did was adding class my_install_data (install_data): def finalize_options (self): self.set_undefined_options('install', ('install_lib', 'install_dir'), ('root', 'root'), ('force', 'force'), ) and cmdclass = {'install_data': my_install_data}, data_files = [('biggles', ["src/config.ini"])] to the setup command line. This got everything to the right place. Hope this helps. Greetings Berthold -- bhoel(a)starship.python.net / http://starship.python.net/crew/bhoel/ It is unlawful to use this email address for unsolicited ads (USC Title 47 Sec.227). I will assess a US$500 charge for reviewing and deleting each unsolicited ad.

3 4