[Harry Henry Gebel, regarding his patch for doing both optimized and
non-optimized bytecode compilation at install-time]
Hi here are the changes made by the patch:
In install_lib.py:
Puts --optimize option to work (see below)
Adds two negative options --no-compile and --no-optimize which turn off
--compile and --optimize .
No longer attempts to set compile and optimize from --compile-py and
--optimize-py in 'install' (there are no such options).
Runs 'build_clib', eliminating the need for 'install' to run 'build'
[...]
I like the spirit of the patch, but I'm not sure if this is the right
way to do it. I'm inclined more towards this: generate a little script,
and run it twice: "python compile.py" and "python -O compile.py".
I see three options:
1) generate a script that explicitly lists all the .py modules to be
compiled, does the necessary timestamp-checking, and calls
'py_compile.compile()' to do the compilation.
PRO: gives us exact control over what's compiled
CON: largely reimplements the standard compileall module
(the difference is that this one would take a list of
files rather than a directory)
2) run python <pythonlib>/compileall.py -d
PRO: not much code to write
CON: not the right thing to do if installing new modules into
a package (eg. the root package) that already has modules
in it
3) same as #2, but invoke "compileall" as a "-c" script -- eg.
python -c "from compileall import compile_dir ; compile_dir()
...I don't think this is any different from #2
I'm leaning towards #1, but with a new Distutils module to handle most
of the work (ie. the near-reimplementation-of-compileall). Thus, the
generated script would be mainly a list of modules. Perhaps we could
even get away with generating just a data file (list of modules to
compile) and passing it to the new "distutils.bytecompile" (?) module.
Opinions?
I'm really not keen on the Distutils recursively invoking the setup
script just to do bytecode compilation. *Really* not keen. And it seem
more symmetric to not care what the current interpreter's optimization
state is, but just spawn two separate interpreters to take care of the
two optimization case.
Also, as I mentioned in private email to Harry, I don't think it's the
business of the "install" command to know what the subcommands of
"build" are, so I'd prefer if you left out the "don't run 'build', just
run its subcommands" tweak.
Harry, d'you want to rework and resubmit your patch? If not, I'll
tackle this task.
Greg
--
Greg Ward - just another Python hacker gward@python.net
http://starship.python.net/~gward/
A day for firm decisions!!!!! Or is it?
