O
Oren Tirosh
.
I wasn't suggesting scanning the executable at runtime. When py2exe
reads the python executablein order to create a copy with an appended
zip archive it might as well scan for a signature and modify the
customization area that follows it. When this customized interpreter
loads the customization values will already be in memory in the form of
an initialized variable.
If the interpreter detects that the customization area has been modified
it will interpret it as command-line arguments instead of argv. This
enables complete control of things like compiler flags, optimization
flag, ignoring environment, etc. A short "-c" string can be used for
bootstrapping the appended zip. The call to PySys_SetArgv would use the
real argv, if course.
Oren
Sounds much like the way py2exe already works now. It locates the
appended zip-file by searching the exefile from the end, then finds the
beginning of the zipfile, and looks for a magic number there, which is
used to verify that the next n bytes before this position is a C
structure containing the required flags.
I don't like the idea to scan the executable for a magic signature
without further hints where this should be.
I wasn't suggesting scanning the executable at runtime. When py2exe
reads the python executablein order to create a copy with an appended
zip archive it might as well scan for a signature and modify the
customization area that follows it. When this customized interpreter
loads the customization values will already be in memory in the form of
an initialized variable.
If the interpreter detects that the customization area has been modified
it will interpret it as command-line arguments instead of argv. This
enables complete control of things like compiler flags, optimization
flag, ignoring environment, etc. A short "-c" string can be used for
bootstrapping the appended zip. The call to PySys_SetArgv would use the
real argv, if course.
Oren