aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/Tools/scripts/freeze_modules.py
Commit message (Collapse)AuthorAge
* gh-97669: Create Tools/build/ directory (#97963)Victor Stinner2022-10-17
| | | | | | | | | | | | | | | | | | | | | | | Create Tools/build/ directory. Move the following scripts from Tools/scripts/ to Tools/build/: * check_extension_modules.py * deepfreeze.py * freeze_modules.py * generate_global_objects.py * generate_levenshtein_examples.py * generate_opcode_h.py * generate_re_casefix.py * generate_sre_constants.py * generate_stdlib_module_names.py * generate_token.py * parse_html5_entities.py * smelly.py * stable_abi.py * umarshal.py * update_file.py * verify_ensurepip_wheels.py Update references to these scripts.
* gh-84623: Remove unused imports (#94132)Victor Stinner2022-06-22
|
* bpo-47146: Stop Depending On regen-deepfreeze For regen-global-objects ↵Eric Snow2022-03-31
| | | | | | | | | (gh-32218) This effectively reverts the Makefile change in gh-31637. I've added some notes so it is more clear what is going on. We also update the "Check if generated files are up to date" job to run "make regen-deepfreeze" to ensure "make regen-global-objects" catches deepfreeze.c. https://bugs.python.org/issue47146
* Remove trailing spaces (GH-31695)Serhiy Storchaka2022-03-05
|
* bpo-46608: Fix argument parsing in freeze_modules.py (GH-31131)Kumar Aditya2022-02-05
|
* bpo-46608: exclude marshalled-frozen data if deep-freezing to save 300 KB ↵Kumar Aditya2022-02-04
| | | | | | | | | | | | | space (GH-31074) This reduces the size of the data segment by **300 KB** of the executable because if the modules are deep-frozen then the marshalled frozen data just wastes space. This was inspired by comment by @gvanrossum in https://github.com/python/cpython/pull/29118#issuecomment-958521863. Note: There is a new option `--deepfreeze-only` in `freeze_modules.py` to change this behavior, it is on be default to save disk space. ```console # du -s ./python before 27892 ./python # du -s ./python after 27524 ./python ``` Automerge-Triggered-By: GH:ericsnowcurrently
* bpo-46429: Merge all deepfrozen files into one (GH-30572)Kumar Aditya2022-01-20
|
* bpo-45949: Pure Python freeze module for cross builds (GH-29899)Christian Heimes2021-12-13
|
* bpo-45654: No need to freeze types (GH-30028)Christian Heimes2021-12-10
|
* bpo-45654: Freeze the runpy module and stuff it imports (GH-29903)Kumar Aditya2021-12-09
|
* bpo-45950: Introduce Bootstrap Python again (#29859)Christian Heimes2021-12-03
| | | | | | | | | The build system now uses a :program:`_bootstrap_python` interpreter for freezing and deepfreezing again. To speed up build process the build tools :program:`_bootstrap_python` and :program:`_freeze_module` are no longer build with LTO. Cross building depends on a build Python interpreter, which must have same version and bytecode as target host Python.
* bpo-45019: Cleanup module freezing and deepfreeze (#29772)Kumar Aditya2021-11-26
|
* Fix typo in freeze_modules (#29744)Kumar Aditya2021-11-24
|
* bpo-45886: Allow overriding freeze command for cross compiling (GH-29735)Christian Heimes2021-11-24
|
* bpo-45873: Get rid of bootstrap_python (#29717)Guido van Rossum2021-11-23
| | | | | | | | | | | | | Instead we use $(PYTHON_FOR_REGEN) .../deepfreeze.py with the frozen .h file as input, as we did for Windows in bpo-45850. We also get rid of the code that generates the .h files when make regen-frozen is run (i.e., .../make_frozen.py), and the MANIFEST file. Restore Python 3.8 and 3.9 as Windows host Python again Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
* bpo-45850: Implement deep-freeze on Windows (#29648)Guido van Rossum2021-11-22
| | | | | | Implement changes to build with deep-frozen modules on Windows. Note that we now require Python 3.10 as the "bootstrap" or "host" Python. This causes a modest startup speed (around 7%) on Windows.
* bpo-45696: Deep-freeze selected modules (GH-29118)Guido van Rossum2021-11-10
| | | | | | | This gains 10% or more in startup time for `python -c pass` on UNIX-ish systems. The Makefile.pre.in generating code builds on Eric's work for bpo-45020, but the .c file generator is new. Windows version TBD.
* bpo-45395: Make custom frozen modules additions instead of replacements. ↵Eric Snow2021-10-28
| | | | | | | | | (gh-28778) Currently custom modules (the array set on PyImport_FrozenModules) replace all the frozen stdlib modules. That can be problematic and is unlikely to be what the user wants. This change treats the custom frozen modules as additions instead. They take precedence over all other frozen modules except for those needed to bootstrap the import system. If the "code" field of an entry in the custom array is NULL then that frozen module is treated as disabled, which allows a custom entry to disable a frozen stdlib module. This change allows us to get rid of is_essential_frozen_module() and simplifies the logic for which frozen modules should be ignored. https://bugs.python.org/issue45395
* bpo-45402: Fix test_tools.test_sundry() (GH-28786)Victor Stinner2021-10-07
| | | | Fix test_tools.test_sundry() when Python is built out of tree: fix how the freeze_modules.py tool locates the _freeze_module program.
* bpo-45020: Identify which frozen modules are actually aliases. (gh-28655)Eric Snow2021-10-05
| | | | | | | In the list of generated frozen modules at the top of Tools/scripts/freeze_modules.py, you will find that some of the modules have a different name than the module (or .py file) that is actually frozen. Let's call each case an "alias". Aliases do not come into play until we get to the (generated) list of modules in Python/frozen.c. (The tool for freezing modules, Programs/_freeze_module, is only concerned with the source file, not the module it will be used for.) Knowledge of which frozen modules are aliases (and the identity of the original module) normally isn't important. However, this information is valuable when we go to set __file__ on frozen stdlib modules. This change updates Tools/scripts/freeze_modules.py to map aliases to the original module name (or None if not a stdlib module) in Python/frozen.c. We also add a helper function in Python/import.c to look up a frozen module's alias and add the result of that function to the frozen info returned from find_frozen(). https://bugs.python.org/issue45020
* bpo-45020: Add more test cases for frozen modules. (gh-28664)Eric Snow2021-09-30
| | | | | I've added a number of test-only modules. Some of those cases are covered by the recently frozen stdlib modules (and some will be once we add encodings back in). However, I figured we'd play it safe by having a set of modules guaranteed to be there during tests. https://bugs.python.org/issue45020
* Fix EncodingWarning in freeze_modules. (GH-28591)Inada Naoki2021-09-30
|
* bpo-45020: Do not freeze <pkg>/__init__.py twice. (gh-28635)Eric Snow2021-09-29
| | | | | Currently we're freezing the __init__.py twice, duplicating the built data unnecessarily With this change we do it once. There is no change in runtime behavior. https://bugs.python.org/issue45020
* Select correct tool platform when building on Windows ARM64 natively (GH-28491)Niyas Sait2021-09-27
|
* bpo-45020: Fix some corner cases for frozen module generation. (gh-28538)Eric Snow2021-09-24
| | | | | This also includes some cleanup in preparation for a PR to make the "make all" output less noisy. https://bugs.python.org/issue45020
* bpo-45020: Freeze os, site, and codecs. (gh-28398)Eric Snow2021-09-17
| | | https://bugs.python.org/issue45020
* bpo-45020: Fix build out of source tree (GH-28410)Victor Stinner2021-09-17
| | | | | | * Makefile.pre.in: Add $(srcdir) when needed, remove it when it was used by mistake. * freeze_modules.py tool uses ./Programs/_freeze_module if the executable doesn't exist in the source tree.
* bpo-45020: Drop the frozen .h files from the repo. (gh-28392)Eric Snow2021-09-16
| | | | | The main advantage is that the files will no longer show up in diffs and PRs. That means, for a PR, the number of files / lines changed will more clearly reflect the actual change. (This is essentially an un-revert of gh-28375.) https://bugs.python.org/issue45020
* bpo-45020: Revert "Drop the frozen .h files from the repo." (gh-28380)Eric Snow2021-09-15
| | | | | gh-28375 broke one of the buildbots. Until I figure out why, I'm rolling the change back. https://bugs.python.org/issue45020
* bpo-45020: Drop the frozen .h files from the repo. (gh-28375)Eric Snow2021-09-15
| | | | | The main advantage is that the files will no longer show up in diffs and PRs. That means, for a PR, the number of files / lines changed will more clearly reflect the actual change. https://bugs.python.org/issue45020
* bpo-45019: Clean up the frozen __hello__ module. (gh-28374)Eric Snow2021-09-15
| | | | | Here's one more small cleanup that should have been in PR gh-28319. We eliminate stdout side-effects from importing the frozen __hello__ module, and update tests accordingly. We also move the module's source file into Lib/ from Toos/freeze/flag.py. https://bugs.python.org/issue45019
* bpo-45188: Windows now regenerates frozen modules at the start of build ↵Steve Dower2021-09-15
| | | | | | | instead of late (GH-28322) This will enable us to drop the frozen module header files from the repository. It does currently cause many source files to be built twice, which just takes more time. For whoever comes to fix this in the future, the files shared between freeze_module and pythoncore should be put into a static library that is consumed by both.
* bpo-45020: Freeze some of the modules imported during startup. (gh-28335)Eric Snow2021-09-15
| | | | | | | Doing this provides significant performance gains for runtime startup (~15% with all the imported modules frozen). We don't yet freeze all the imported modules because there are a few hiccups in the build systems we need to sort out first. (See bpo-45186 and bpo-45188.) Note that in PR GH-28320 we added a command-line flag (-X frozen_modules=[on|off]) that allows users to opt out of (or into) using frozen modules. The default is still "off" but we will change it to "on" as soon as we can do it in a way that does not cause contributors pain. https://bugs.python.org/issue45020
* bpo-45019: Do some cleanup related to frozen modules. (gh-28319)Eric Snow2021-09-13
| | | | | There are a few things I missed in gh-27980. This is a follow-up that will make subsequent PRs cleaner. It includes fixes to tests and tools that reference the frozen modules. https://bugs.python.org/issue45019
* bpo-45019: Add a tool to generate list of modules to include for frozen ↵Eric Snow2021-08-30
modules (gh-27980) Frozen modules must be added to several files in order to work properly. Before this change this had to be done manually. Here we add a tool to generate the relevant lines in those files instead. This helps us avoid mistakes and omissions. https://bugs.python.org/issue45019
generated by cgit v1.2.3 (git 2.39.1) at 2025-06-07 19:05:38 +0000