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
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.
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
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
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.
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
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
----- 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
>
