[Distutils] Re: Add multiple frozen modules

[James C. Ahlstrom]

Gordon McMillan wrote:

> OK - os.path.dirname(sys.argv[0]).

Oh, I see.  Your main program is given as a complete path
in the icon target.  So "python D:/my/path/myprog.py".
I start my main as the frozen module named "__main__", so
sys.argv[0] is useless.

> In my case it doesn't matter. I have just concatenated my archive (of
> python15.dll, any .pyzs, exceptions.py, site.py etc.) onto the end of
> the executable. When run, it opens itself as a file and unpacks the
> archive into the current directory. Then it does a
> _putenv("PYTHONPATH=.") and dynamically loads python15.dll.  If
> you're using Run.exe, it even cleans up whatever it unpacked at end
> of run.

Cool.  I didn't realize you could append to an .exe and still
have it run.  How do you know where your appended data starts?

> More advanced would be to make the archive a legit resource section
> of the exe, but I can't see that as worth the effort (esp. since I
> don't expect my users to have compilers, and I've already gone to the
> work of finding the import sections in dll headers so I can find
> binary dependencies...)

I think this may be a good idea.  We could use a Windows user-defined
resource named with a magic name such as "PythonPyc", and all resource
modules could be loaded in Py_Initialize().  The .rc resource file 
names the .pyc file so there is no need to convert the bytes to C
and compile.  The .rc file syntax is the line:
               string PythonPyc C:/lib/string.pyc
You use FindResource(), SizeofResource(), LoadResource() and
LockResource() to access these resources.

It is possible to replace resources in an exe or dll using
BeginUpdateResource(), UpdateResource() and EndUpdateResource().  If
we wrote a Python interface into a .pyd, then users don't even need
a compiler nor resource compiler.  Note that there is Mac code in the
distribution which accesses Mac resources.  The only reason I have
not written all this is it is not usable on Unix.

Jim Ahlstrom