Distutils-SIG September 2003

distutils-sig@python.org

23 participants
28 discussions

by Jesse Hammons

I am looking for advice on how to trip down the size of a monothic application I am building with python/wxPython. This project involves the python code from python, wxPython significant amounts of C and C++ code from wxPython, PyOpenGL and the underlying application functionality, which is largely a set of unix commands implemented in C. My question is: what strategies are there for doing a more traditional linking stage for the final application bundle? As it stands, I packaged up python, wxPython and PyOpenGL with my app and it came to a 100Meg binary. I use only a small portion of the funcionality of those packages (e.g. site-packages from python) but the wxPython and OpenGL extensions are done as shared libraries which means the whole thing goes out. I have tried freeze.py and similar, but that just seems to make things bigger. Are there tools that do a static analysis of python code to list which packages are actually used? What about a dynamic analysis (I run my app, then dump the list of loaded modules and just ship those). For the C/C++ code, I am thinking of just statically linking the extensions into a python exectable and letting the linker strip dead code. Advice or pointers to other groups appreciated. Thanks, -Jesse __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

16 years, 10 months

RE: [Distutils] more clashes between 'build' and 'bdist_wininst'

by Moore, Paul

From: Stefan Seefeld [mailto:seefeld@sympatico.ca] > I would thus expect the installer to do the same trick again, > i.e. modifying the first line of my scripts to point to > the right interpreter, not the one used during the build. > Am I missing something ? Is this a bug ? The #! line is not relevant on Windows, and so its contents don't really matter. Paul.

16 years, 10 months

more clashes between 'build' and 'bdist_wininst'

by Stefan Seefeld

hi there, I'v run into a new problem using the 'bdist_wininst' command: the 'build_scripts' command inspects the first line of my scripts, and, if it finds 'python' there, replaces it with the python command used during the build. If for example my script's first line reads '#! /usr/bin/env python', and if I use '/usr/local/bin/python' during compilation, the first line of my script will be replaced yielding '#! /usr/local/bin/python'. That works find as long as the final interpreter coincides with the one used for building. When using 'bdist_wininst' however, the 'real' interpreter is determined during the execution of the windows installer only. I would thus expect the installer to do the same trick again, i.e. modifying the first line of my scripts to point to the right interpreter, not the one used during the build. Am I missing something ? Is this a bug ? Regards, Stefan

16 years, 10 months

Automated, or non-gui installer?

by Ivan R. Judson

If I wanted to install a bunch of python modules as part of a bigger package, could I build python modules installers with distutils that would not need user input or create windows? --Ivan

16 years, 10 months

Hack for runtime_library_dir_option

by Berthold Höllmann

Hello, Using scipy distutils under Solaris I stumbled over a problem in distutils unixccompiler. In runtime_library_dir_option the C compiler name is used to determine whether to a use "-Wl,-R" or "-R". I use the Sun Fortran compiler together with gcc. Now when linking an extension module that uses "runtime_library_dirs" and the fortran compiler for linking I get an error message because of the usage of "-Wl.-R" instead of "-R". I rewrote the routine a little bit: def runtime_library_dir_option(self, dir): # XXX Hackish, at the very least. See Python bug #445902: # http://sourceforge.net/tracker/index.php # ?func=detail&aid=445902&group_id=5470&atid=105470 # Linkers on different platforms need different options to # specify that directories need to be added to the list of # directories searched for dependencies when a dynamic library # is sought. GCC has to be told to pass the -R option through # to the linker, whereas other compilers just know this. # Other compilers may need something slightly different. At # this time, there's no way to determine this information from # the configuration data stored in the Python installation, so # we use this hack. linker = self.linker_so if sys.platform[:6] == "darwin": # MacOSX's linker doesn't understand the -R flag at all return "-L" + dir elif sys.platform[:5] == "hp-ux": return "+s -L" + dir elif linker[:3] == "gcc" or linker[:3] == "g++" or linker[:3] == "g77": return "-Wl,-R" + dir else: return "-R" + dir and now it works for me. Shall I issue a but report on this or is my usage to exotic? Kind regards Berthold Höllmann -- Germanischer Lloyd AG CAE Development Vorsetzen 35 20459 Hamburg Phone: +49(0)40 36149-7374 Fax: +49(0)40 36149-7320 e-mail: hoel(a)gl-group.com Internet: http://www.gl-group.com **************************************************** Please notice: We would like to inform you that the e-mail address of Germanischer Lloyd as well as our internet address had been changed to gl-group.com with effect from 1st March 2003. This means that the previous address shortmark(a)germanlloyd.org will be replaced by shortmark(a)gl-group.com. From now on the GL homepage can be accessed at the address 'http://www.gl-group.com'. The old addresses remain valid for a transitional period. **************************************************** This e-mail contains confidential information for the exclusive attention of the intended addressee. Any access of third parties to this e-mail is unauthorised. Any use of this e-mail by unintended recipients such as copying, distribution, disclosure etc. is prohibited and may be unlawful. When addressed to our clients the content of this e-mail is subject to the General Terms and Conditions of GL's Group of Companies applicable at the date of this e-mail. GL's Group of Companies does not warrant and/or guarantee that this message at the moment of receipt is authentic, correct and its communication free of errors, interruption etc.

16 years, 11 months

installation paths when using 'bdist_wininst'

by Stefan Seefeld

hi there, I'm trying to package a tool that uses some data files. As the 'install_data' command is used to install these files. As the exact location of these data files is only known at installation time, I extended that command to generate a 'config.py' module containing the correct path which the other modules then can use to find the data. This approach is quite common with build systems based on make/autoconf, so I'm adopting it to a python project, too. That seems to work fine when I run 'python setup.py install'. However, I just tried the 'bdist_wininst' command and it stops working: it appears the 'bdist_wininst' calls the 'install' command with the 'install_data' argument set to a temporary path, i.e. one that is only used during the packaging, but which is not the ultimate location of the data files after installation via the windows installer. This brings up a couple of questions: * how does the windows installer determine where to install the package's files ? * how can I generate my 'config.py' file such that it correctly points to that location ? * are there other ways to find out this location ? Thanks for any help, Stefan

16 years, 11 months

Compiling C++ extensions with python2.3 distutils/mingw32 fails

by Hogendoorn, Rene

The distutils, distributed with python 2.3, try to recognize the language (c or c++) and set the linker executable as appropriate. With cygwin and mingw32, the resulting linker is 'cc.exe', because the CygwinCompiler class fails to provide a definition for compiler_cxx. A solution is to patch the call to self.set_executables: # Hard-code GCC because that's what this is all about. # XXX optimization, warnings etc. should be customizable. self.set_executables(compiler='gcc -mcygwin -O -Wall', compiler_so='gcc -mcygwin -mdll -O -Wall', compiler_cxx='g++ -mcygwin -O -Wall', <========== linker_exe='gcc -mcygwin', linker_so=('%s -mcygwin %s' % (self.linker_dll, shared_option))) Regards, René Hogendoorn -- HITT Traffic Oude Apeldoornseweg 41-45 P.O. Box 717 NL-7300 AS, APELDOORN The Netherlands Telephone +31-55-543 2559 Mobile +31-610 925 412 Fax +31-55-543 2553 E-mail r.hogendoorn(a)hitt.nl

16 years, 11 months

you r sending this on purpose or your pc got virus? please scan your pc

by PAUL YOUNG

----- Original Message ----- From: <distutils-sig(a)python.org> To: <cwteoh(a)tm.net.my> Sent: Monday, September 01, 2003 11:09 PM Subject: Re: Re: My details > See the attached file for details >

16 years, 11 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG September 2003