[Distutils] Re: Add multiple frozen modules

[M.-A. Lemburg]

James C. Ahlstrom wrote:
> 
> "M.-A. Lemburg" wrote:
> >
> > Ehh... I thought this was only a problem on Windows where the
> > default is to build a Python DLL instead of an EXE. On Unix,
> > freezing multiple modules into one binary is not much of a problem
> > (except the shared lib thing below): this is how all the cgipython
> > binaries for the mxCGIPython project where created.
> 
> I think you are right that this topic is mostly of interest to
> Windows people.  On Unix you usually use freeze to include everything
> in the binary as you say.
> 
> On Windows the interpreter is in python15.dll, a shared library.
> The advantage is that you can add other DLL's without
> recompiling anything.  So "built-in" modules become dynamic.  There
> is no reason Unix could not do this too if shared modules are available.
> 
> For those of us distributing applications, the executable programs could
> be
>   1) main1.exe, main2.exe, etc. with a frozen "__main__" module
> included;
>   2) or a single executable "python.exe" but with a specified program
>      on the command line "python.exe C:/path/myprog.py" as specified
>      in a Windows icon (shortcut).  This exposes the myprog source.
> 
> What I am trying to do is put the Python library into python15.dll
> but still allow other *.pyc files to be in main1.exe.  Thus the
> subject line, add multiple frozen modules.  Putting the library into
> python15.dll guarantees version match, and means you can upgrade Python
> versions just by replacing python15.dll.  You upgrade your application
> by replacing main1.exe.  Simple.

Just a note here: the new DLL should *not* be named python15.dll,
since this is likely to cause incompatible setups -- why not call
it pylib15.dll or something similar. This DLL would then only
include the frozen modules and live happily alongside of the
standard python15.dll. Only the EXE would know about the frozen
modules in pylib15.dll (with the extra magic to include them
as frozen modules in sys).

The same could be done to your Python files.

As a result you'd have these files:

main.exe     -- special main for frozen app which links to the DLLs
myapp.dll    -- frozen application modules
python15.dll -- the standard python15.dll
pylib15.dll  -- the standard lib in form of frozen modules

This setup should work on all platforms providing shared
libs since the hard part of linking in the different DLLs
is handled by the linker (*). main.exe would only need to know
the names of all the frozen modules.

(*) Using the lib in this form is also likely to reduce startup
times once the DLL is loaded.

> > > > The problem with this binary is that it fails to load shared
> > > > libs (DLLs on WinNT). This fails for both Unix and Windows
> > >
> > > I would guess the problem on Windows is that the shared libs
> > > have been compiled to need Python, and so the only way they
> > > can get Python is in a DLL.  If the main.exe and a shared lib
> > > both need Python (the usual case) then Python MUST be in a
> > > shared lib too.  Making an exe will not work.  On Windows, the
> > > solution is to put the frozen Python libs into python15.dll.
> > > Then everything will work.
> >
> > Hmm, but that wouldn't be all that elegant :-) since the code
> > is included twice. Even worse, I think this will mess up
> > the memory allocation, if I remember old mails on c.l.p regarding
> > malloc and DLLs on Windows correctly.
> 
> I do not understand.  Nothing is included twice.  The only Python
> interpreter is in python15.dll, and all clients such as main1.exe,
> cool_stuff.pyd, etc. use it.

Sorry, I misread you reply and was still thinking of how the cgipython
EXE works (it includes the lib as frozen modules). Adding the python15.dll
to cgipython would probably lead to the malloc problems.
If the lib were included in python15.dll that would be different,
I suppose.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                   169 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/