Binary generation with distutils? (Freeze, py2exe, etc.)

[Thomas Heller]

"Martin v. Löwis" <loewis at informatik.hu-berlin.de> wrote:
> "Thomas Heller" <theller at python.net> writes:
>
> > Problems with freeze, IMO, are that it requires a C-compiler,
> > which most people on windows do not have, also the resulting
> > files are much larger than those created by py2exe or installer,
> > because the byte codes are not compressed.
>
> In the context of distutils, absence of a compiler may not be a
> problem: people building packages with distutils will need a compiler,
> atleast if the package contains extension modules.
>
> As for size of the resulting executable: if compressing the byte code
> really provides a significant saving, I think freeze should make use
> of that mechanism, too.

Do you think that PyImport_FrozenModule() should be extended to handle
compressed byte codes? Or should freeze simply append the compressed
byte codes to the executable (as py2exe and installer do it) instead
of compiling them with the C-compiler?

>
> I see the primary advantage of freeze over the other mechanisms in
> that it provides (or can provide) a truly stand-alone binary. The
> Windows-specific packagers always need to put pythonxy.dll into the
> executable, and any required extension modules; this is ugly. If
> libpython is available as a static library, freeze can produce more
> compact binaries, too, since it can omit unused extension modules.

An interesting idea would be to additionally distribute Python and
extension modules (on windows) not only as dlls, but also as static
libraries. In this case only a linker would be needed, and you avoid
the problems compiling all the sources...

Another possibility would be to use a program creating a standalone
exe-file from exe and dlls. I have once tried such a program, it worked
in simple cases, but not for Python. Then I wrote some code (in python)
myself to do this, it is very tricky, but certainly possible.
All in all, currently I don't care too much about single file executables.

Thomas