We have _freeze_module, which is just enough interpreter to do what Programs/_freeze_module.c implements (which can obviously be extended if necessary), but because we can't reuse object files it's a serious slowdown to rebuild the entire interpreter.
If there's really no way to do it without a full interpreter, we'll want to split most of the runtime into a static library. That should let us compile almost everything, then build an exe to do what you need, then build the real one, and reuse most of the object files via the static lib. (I say "we" because, even though it'll probably be me, I don't want to block someone else from doing it.)
Can you maybe parse the opcode value out of one of the other files for this? Or teach _freeze_module how to print out the value for you?
Do cross-builds on UNIX require the external Python to be built from the exact same commit? If not, it's probably the same as the Windows rule (which just requires an external version, not necessarily an older version).
The reason to use _bootstrap_python is that otherwise users would have to install Python 3.10 in order to build 3.11. (See #90108 (comment) where this is said.)
Activity
gvanrossum commented on Jun 13, 2022
We may need help from @zooba to fix the build files. (Do we even have a bootstrap interpreter on Windows?)
zooba commented on Jun 13, 2022
We have _freeze_module, which is just enough interpreter to do what Programs/_freeze_module.c implements (which can obviously be extended if necessary), but because we can't reuse object files it's a serious slowdown to rebuild the entire interpreter.
If there's really no way to do it without a full interpreter, we'll want to split most of the runtime into a static library. That should let us compile almost everything, then build an exe to do what you need, then build the real one, and reuse most of the object files via the static lib. (I say "we" because, even though it'll probably be me, I don't want to block someone else from doing it.)
Can you maybe parse the opcode value out of one of the other files for this? Or teach _freeze_module how to print out the value for you?
gvanrossum commented on Jun 13, 2022
Mark solved it by hardcoding RESUME.
markshannon commented on Jun 14, 2022
Would it make sense to just fix the comment? Something like "This script should be executable by any reasonably recent Python".
zooba commented on Jun 14, 2022
I think it's minimum 3.10 now because of a match statement, so we can be more concrete than "reasonably recent".
kumaraditya303 commented on Jun 15, 2022
Guido replaced the match statement with an if-else chain so that deepfreeze can run with older versions of Python in #29717
gvanrossum commented on Jun 15, 2022
The rules appear to be even more complicated.
zooba commented on Jun 15, 2022
Do cross-builds on UNIX require the external Python to be built from the exact same commit? If not, it's probably the same as the Windows rule (which just requires an external version, not necessarily an older version).
gvanrossum commented on Jun 15, 2022
I dunno without investigating the code in much detail. The reasoning around using bootstrap python has gone back and forth too many times. :-(
gvanrossum commented on Jun 23, 2022
@kumaraditya303 Do you recall why it has to be run with _bootstrap_python at all on UNIX?
kumaraditya303 commented on Jun 23, 2022
_bootstrap_python is used mainly because of cross compilation and was (re)introduced in #29859. You can read #90108 issue for rationale.
gh-93771: Clarify how deepfreeze.py is run (#94150)
pythongh-93771: Clarify how deepfreeze.py is run (pythonGH-94150)
gh-93771: Clarify how deepfreeze.py is run (GH-94150)
gvanrossum commented on Jun 23, 2022
Fixed by #94150 and #94179 (3.11 backport).
The reason to use _bootstrap_python is that otherwise users would have to install Python 3.10 in order to build 3.11. (See #90108 (comment) where this is said.)
Revert 30935 defer bpo45162 to 312 (#94285)