Mirror
/
cpython
mirror of https://github.com/python/cpython
4
1
Fork 0
Code Issues Releases Wiki Activity
cpython/PCbuild/_freeze_module.vcxproj

430 lines
21 KiB
XML
Raw Normal View History

Issue #15431: Add _freeze_importlib project to regenerate importlib.h on Windows. Patch by Kristján Valur Jónsson.
2012-07-28 15:46:52 -03:00
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup Label="ProjectConfigurations">
bpo-35976: Enable Windows projects to build with platform ARM32 (GH-11825) This change adds the necessary items to the build projects to avoid erroring out right at the start. It does not add _support_ for targeting Windows on ARM32, but is a necessary prerequisite for adding it.
2019-02-14 12:31:30 -04:00
<ProjectConfiguration Include="Debug|ARM">
<Configuration>Debug</Configuration>
<Platform>ARM</Platform>
</ProjectConfiguration>
bpo-36941: Windows build changes for Windows ARM64 (GH-13365)
2019-05-17 14:07:24 -03:00
<ProjectConfiguration Include="Debug|ARM64">
<Configuration>Debug</Configuration>
<Platform>ARM64</Platform>
</ProjectConfiguration>
Issue #15431: Add _freeze_importlib project to regenerate importlib.h on Windows. Patch by Kristján Valur Jónsson.
2012-07-28 15:46:52 -03:00
<ProjectConfiguration Include="Debug|Win32">
<Configuration>Debug</Configuration>
<Platform>Win32</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="Debug|x64">
<Configuration>Debug</Configuration>
<Platform>x64</Platform>
</ProjectConfiguration>
bpo-35976: Enable Windows projects to build with platform ARM32 (GH-11825) This change adds the necessary items to the build projects to avoid erroring out right at the start. It does not add _support_ for targeting Windows on ARM32, but is a necessary prerequisite for adding it.
2019-02-14 12:31:30 -04:00
<ProjectConfiguration Include="PGInstrument|ARM">
<Configuration>PGInstrument</Configuration>
<Platform>ARM</Platform>
</ProjectConfiguration>
bpo-36941: Windows build changes for Windows ARM64 (GH-13365)
2019-05-17 14:07:24 -03:00
<ProjectConfiguration Include="PGInstrument|ARM64">
<Configuration>PGInstrument</Configuration>
<Platform>ARM64</Platform>
</ProjectConfiguration>
Issue #22919: Windows build updated to support VC 14.0 (Visual Studio 2015), which will be used for the official 3.5 release.
2014-11-22 16:54:57 -04:00
<ProjectConfiguration Include="PGInstrument|Win32">
<Configuration>PGInstrument</Configuration>
<Platform>Win32</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="PGInstrument|x64">
<Configuration>PGInstrument</Configuration>
<Platform>x64</Platform>
</ProjectConfiguration>
bpo-35976: Enable Windows projects to build with platform ARM32 (GH-11825) This change adds the necessary items to the build projects to avoid erroring out right at the start. It does not add _support_ for targeting Windows on ARM32, but is a necessary prerequisite for adding it.
2019-02-14 12:31:30 -04:00
<ProjectConfiguration Include="PGUpdate|ARM">
<Configuration>PGUpdate</Configuration>
<Platform>ARM</Platform>
</ProjectConfiguration>
bpo-36941: Windows build changes for Windows ARM64 (GH-13365)
2019-05-17 14:07:24 -03:00
<ProjectConfiguration Include="PGUpdate|ARM64">
<Configuration>PGUpdate</Configuration>
<Platform>ARM64</Platform>
</ProjectConfiguration>
Issue #22919: Windows build updated to support VC 14.0 (Visual Studio 2015), which will be used for the official 3.5 release.
2014-11-22 16:54:57 -04:00
<ProjectConfiguration Include="PGUpdate|Win32">
<Configuration>PGUpdate</Configuration>
<Platform>Win32</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="PGUpdate|x64">
<Configuration>PGUpdate</Configuration>
<Platform>x64</Platform>
</ProjectConfiguration>
bpo-35976: Enable Windows projects to build with platform ARM32 (GH-11825) This change adds the necessary items to the build projects to avoid erroring out right at the start. It does not add _support_ for targeting Windows on ARM32, but is a necessary prerequisite for adding it.
2019-02-14 12:31:30 -04:00
<ProjectConfiguration Include="Release|ARM">
<Configuration>Release</Configuration>
<Platform>ARM</Platform>
</ProjectConfiguration>
bpo-36941: Windows build changes for Windows ARM64 (GH-13365)
2019-05-17 14:07:24 -03:00
<ProjectConfiguration Include="Release|ARM64">
<Configuration>Release</Configuration>
<Platform>ARM64</Platform>
</ProjectConfiguration>
Issue #15431: Add _freeze_importlib project to regenerate importlib.h on Windows. Patch by Kristján Valur Jónsson.
2012-07-28 15:46:52 -03:00
<ProjectConfiguration Include="Release|Win32">
<Configuration>Release</Configuration>
<Platform>Win32</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="Release|x64">
<Configuration>Release</Configuration>
<Platform>x64</Platform>
</ProjectConfiguration>
</ItemGroup>
<PropertyGroup Label="Globals">
<ProjectGuid>{19C0C13F-47CA-4432-AFF3-799A296A4DDC}</ProjectGuid>
<Keyword>Win32Proj</Keyword>
bpo-45019: Add a tool to generate list of modules to include for frozen 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
2021-08-30 20:25:11 -03:00
<RootNamespace>_freeze_module</RootNamespace>
Issue #22919: Windows build updated to support VC 14.0 (Visual Studio 2015), which will be used for the official 3.5 release.
2014-11-22 16:54:57 -04:00
<SupportPGO>false</SupportPGO>
Issue #15431: Add _freeze_importlib project to regenerate importlib.h on Windows. Patch by Kristján Valur Jónsson.
2012-07-28 15:46:52 -03:00
</PropertyGroup>
Issue #22919: Windows build updated to support VC 14.0 (Visual Studio 2015), which will be used for the official 3.5 release.
2014-11-22 16:54:57 -04:00
<Import Project="python.props" />
Issue #15431: Add _freeze_importlib project to regenerate importlib.h on Windows. Patch by Kristján Valur Jónsson.
2012-07-28 15:46:52 -03:00
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
Issue #22919: Windows build updated to support VC 14.0 (Visual Studio 2015), which will be used for the official 3.5 release.
2014-11-22 16:54:57 -04:00
<PropertyGroup Label="Configuration">
Issue #15431: Add _freeze_importlib project to regenerate importlib.h on Windows. Patch by Kristján Valur Jónsson.
2012-07-28 15:46:52 -03:00
<ConfigurationType>Application</ConfigurationType>
<CharacterSet>Unicode</CharacterSet>
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
<ImportGroup Label="ExtensionSettings">
</ImportGroup>
Issue #22919: Windows build updated to support VC 14.0 (Visual Studio 2015), which will be used for the official 3.5 release.
2014-11-22 16:54:57 -04:00
<ImportGroup Label="PropertySheets">
Issue #15431: Add _freeze_importlib project to regenerate importlib.h on Windows. Patch by Kristján Valur Jónsson.
2012-07-28 15:46:52 -03:00
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
<Import Project="pyproject.props" />
</ImportGroup>
<PropertyGroup Label="UserMacros" />
Issue #22919: Windows build updated to support VC 14.0 (Visual Studio 2015), which will be used for the official 3.5 release.
2014-11-22 16:54:57 -04:00
<ItemDefinitionGroup>
Issue #15431: Add _freeze_importlib project to regenerate importlib.h on Windows. Patch by Kristján Valur Jónsson.
2012-07-28 15:46:52 -03:00
<ClCompile>
bpo-45188: Windows now regenerates frozen modules at the start of build 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.
2021-09-15 14:11:12 -03:00
<PreprocessorDefinitions>Py_NO_ENABLE_SHARED;Py_BUILD_CORE;_CONSOLE;%(PreprocessorDefinitions)</PreprocessorDefinitions>
Issue #15431: Add _freeze_importlib project to regenerate importlib.h on Windows. Patch by Kristján Valur Jónsson.
2012-07-28 15:46:52 -03:00
</ClCompile>
<Link>
<SubSystem>Console</SubSystem>
bpo-45720: Drop references to shlwapi.dll on Windows (GH-29417)
2021-11-05 20:06:45 -03:00
<AdditionalDependencies>version.lib;ws2_32.lib;pathcch.lib;bcrypt.lib;%(AdditionalDependencies)</AdditionalDependencies>
Issue #15431: Add _freeze_importlib project to regenerate importlib.h on Windows. Patch by Kristján Valur Jónsson.
2012-07-28 15:46:52 -03:00
</Link>
</ItemDefinitionGroup>
<ItemGroup>
bpo-45019: Add a tool to generate list of modules to include for frozen 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
2021-08-30 20:25:11 -03:00
<ClCompile Include="..\Programs\_freeze_module.c" />
bpo-45188: Windows now regenerates frozen modules at the start of build 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.
2021-09-15 14:11:12 -03:00
<ClCompile Include="..\PC\config_minimal.c" />
Issue #15431: Add _freeze_importlib project to regenerate importlib.h on Windows. Patch by Kristján Valur Jónsson.
2012-07-28 15:46:52 -03:00
</ItemGroup>
<ItemGroup>
bpo-45188: Windows now regenerates frozen modules at the start of build 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.
2021-09-15 14:11:12 -03:00
<ClCompile Include="..\Modules\atexitmodule.c" />
<ClCompile Include="..\Modules\faulthandler.c" />
<ClCompile Include="..\Modules\gcmodule.c" />
<ClCompile Include="..\Modules\getbuildinfo.c" />
bpo-45582: Port getpath[p].c to Python (GH-29041) The getpath.py file is frozen at build time and executed as code over a namespace. It is never imported, nor is it meant to be importable or reusable. However, it should be easier to read, modify, and patch than the previous code. This commit attempts to preserve every previously tested quirk, but these may be changed in the future to better align platforms.
2021-12-02 20:08:42 -04:00
<ClCompile Include="..\Modules\getpath_noop.c" />
bpo-45188: Windows now regenerates frozen modules at the start of build 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.
2021-09-15 14:11:12 -03:00
<ClCompile Include="..\Modules\posixmodule.c" />
<ClCompile Include="..\Modules\signalmodule.c" />
<ClCompile Include="..\Modules\_tracemalloc.c" />
<ClCompile Include="..\Modules\_io\_iomodule.c" />
<ClCompile Include="..\Modules\_io\bufferedio.c" />
<ClCompile Include="..\Modules\_io\bytesio.c" />
<ClCompile Include="..\Modules\_io\fileio.c" />
<ClCompile Include="..\Modules\_io\iobase.c" />
<ClCompile Include="..\Modules\_io\stringio.c" />
<ClCompile Include="..\Modules\_io\textio.c" />
<ClCompile Include="..\Modules\_io\winconsoleio.c" />
<ClCompile Include="..\Objects\abstract.c" />
<ClCompile Include="..\Objects\accu.c" />
<ClCompile Include="..\Objects\boolobject.c" />
<ClCompile Include="..\Objects\bytearrayobject.c" />
<ClCompile Include="..\Objects\bytes_methods.c" />
<ClCompile Include="..\Objects\bytesobject.c" />
<ClCompile Include="..\Objects\call.c" />
<ClCompile Include="..\Objects\capsule.c" />
<ClCompile Include="..\Objects\cellobject.c" />
<ClCompile Include="..\Objects\classobject.c" />
<ClCompile Include="..\Objects\codeobject.c" />
<ClCompile Include="..\Objects\complexobject.c" />
<ClCompile Include="..\Objects\descrobject.c" />
<ClCompile Include="..\Objects\dictobject.c" />
<ClCompile Include="..\Objects\enumobject.c" />
<ClCompile Include="..\Objects\exceptions.c" />
<ClCompile Include="..\Objects\fileobject.c" />
<ClCompile Include="..\Objects\floatobject.c" />
<ClCompile Include="..\Objects\frameobject.c" />
<ClCompile Include="..\Objects\funcobject.c" />
<ClCompile Include="..\Objects\genericaliasobject.c" />
<ClCompile Include="..\Objects\genobject.c" />
<ClCompile Include="..\Objects\interpreteridobject.c" />
<ClCompile Include="..\Objects\iterobject.c" />
<ClCompile Include="..\Objects\listobject.c" />
<ClCompile Include="..\Objects\longobject.c" />
<ClCompile Include="..\Objects\memoryobject.c" />
<ClCompile Include="..\Objects\methodobject.c" />
<ClCompile Include="..\Objects\moduleobject.c" />
<ClCompile Include="..\Objects\namespaceobject.c" />
<ClCompile Include="..\Objects\object.c" />
<ClCompile Include="..\Objects\obmalloc.c" />
<ClCompile Include="..\Objects\odictobject.c" />
<ClCompile Include="..\Objects\picklebufobject.c" />
<ClCompile Include="..\Objects\rangeobject.c" />
<ClCompile Include="..\Objects\setobject.c" />
<ClCompile Include="..\Objects\sliceobject.c" />
<ClCompile Include="..\Objects\structseq.c" />
<ClCompile Include="..\Objects\tupleobject.c" />
<ClCompile Include="..\Objects\typeobject.c" />
<ClCompile Include="..\Objects\unicodectype.c" />
<ClCompile Include="..\Objects\unicodeobject.c" />
<ClCompile Include="..\Objects\unionobject.c" />
<ClCompile Include="..\Objects\weakrefobject.c" />
<ClCompile Include="..\Parser\myreadline.c" />
<ClCompile Include="..\Parser\parser.c" />
<ClCompile Include="..\Parser\peg_api.c" />
<ClCompile Include="..\Parser\pegen.c" />
Refactor parser compilation units into specific components (GH-29676)
2021-11-20 21:08:50 -04:00
<ClCompile Include="..\Parser\pegen_errors.c" />
<ClCompile Include="..\Parser\action_helpers.c" />
bpo-45188: Windows now regenerates frozen modules at the start of build 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.
2021-09-15 14:11:12 -03:00
<ClCompile Include="..\Parser\string_parser.c" />
<ClCompile Include="..\Parser\token.c" />
<ClCompile Include="..\Parser\tokenizer.c" />
<ClCompile Include="..\PC\invalid_parameter_handler.c" />
<ClCompile Include="..\PC\msvcrtmodule.c" />
<ClCompile Include="..\PC\winreg.c" />
<ClCompile Include="..\Python\_warnings.c" />
<ClCompile Include="..\Python\asdl.c" />
<ClCompile Include="..\Python\ast.c" />
<ClCompile Include="..\Python\ast_opt.c" />
<ClCompile Include="..\Python\ast_unparse.c" />
<ClCompile Include="..\Python\bltinmodule.c" />
<ClCompile Include="..\Python\bootstrap_hash.c" />
<ClCompile Include="..\Python\ceval.c" />
<ClCompile Include="..\Python\codecs.c" />
<ClCompile Include="..\Python\compile.c" />
<ClCompile Include="..\Python\context.c" />
<ClCompile Include="..\Python\dtoa.c" />
<ClCompile Include="..\Python\dynamic_annotations.c" />
<ClCompile Include="..\Python\dynload_win.c" />
<ClCompile Include="..\Python\errors.c" />
<ClCompile Include="..\Python\fileutils.c" />
<ClCompile Include="..\Python\formatter_unicode.c" />
<ClCompile Include="..\Python\frame.c" />
<ClCompile Include="..\Python\future.c" />
<ClCompile Include="..\Python\getargs.c" />
<ClCompile Include="..\Python\getcompiler.c" />
<ClCompile Include="..\Python\getcopyright.c" />
<ClCompile Include="..\Python\getopt.c" />
<ClCompile Include="..\Python\getplatform.c" />
<ClCompile Include="..\Python\getversion.c" />
<ClCompile Include="..\Python\hamt.c" />
<ClCompile Include="..\Python\hashtable.c" />
<ClCompile Include="..\Python\import.c" />
<ClCompile Include="..\Python\importdl.c" />
<ClCompile Include="..\Python\initconfig.c" />
<ClCompile Include="..\Python\marshal.c" />
<ClCompile Include="..\Python\modsupport.c" />
<ClCompile Include="..\Python\mysnprintf.c" />
<ClCompile Include="..\Python\mystrtoul.c" />
<ClCompile Include="..\Python\pathconfig.c" />
<ClCompile Include="..\Python\preconfig.c" />
<ClCompile Include="..\Python\pyarena.c" />
<ClCompile Include="..\Python\pyctype.c" />
<ClCompile Include="..\Python\pyfpe.c" />
<ClCompile Include="..\Python\pyhash.c" />
<ClCompile Include="..\Python\pylifecycle.c" />
<ClCompile Include="..\Python\pymath.c" />
<ClCompile Include="..\Python\pystate.c" />
<ClCompile Include="..\Python\pystrcmp.c" />
<ClCompile Include="..\Python\pystrhex.c" />
<ClCompile Include="..\Python\pystrtod.c" />
<ClCompile Include="..\Python\Python-ast.c" />
<ClCompile Include="..\Python\pythonrun.c" />
<ClCompile Include="..\Python\Python-tokenize.c" />
<ClCompile Include="..\Python\pytime.c" />
<ClCompile Include="..\Python\specialize.c" />
<ClCompile Include="..\Python\structmember.c" />
<ClCompile Include="..\Python\suggestions.c" />
<ClCompile Include="..\Python\symtable.c" />
<ClCompile Include="..\Python\sysmodule.c" />
<ClCompile Include="..\Python\thread.c" />
<ClCompile Include="..\Python\traceback.c" />
Issue #15431: Add _freeze_importlib project to regenerate importlib.h on Windows. Patch by Kristján Valur Jónsson.
2012-07-28 15:46:52 -03:00
</ItemGroup>
<ItemGroup>
bpo-45019: Add a tool to generate list of modules to include for frozen 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
2021-08-30 20:25:11 -03:00
<!-- BEGIN frozen modules -->
Issue #28896: Disable WindowsRegistryFinder by default.
2016-12-12 15:17:59 -04:00
<None Include="..\Lib\importlib\_bootstrap.py">
bpo-25711: Rewrite zipimport in pure Python. (GH-6809)
2018-09-18 16:22:29 -03:00
<ModName>importlib._bootstrap</ModName>
bpo-45020: Fix some corner cases for frozen module generation. (gh-28538) This also includes some cleanup in preparation for a PR to make the "make all" output less noisy. https://bugs.python.org/issue45020
2021-09-24 17:35:47 -03:00
<IntFile>$(IntDir)importlib._bootstrap.g.h</IntFile>
<OutFile>$(PySourcePath)Python\frozen_modules\importlib._bootstrap.h</OutFile>
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<DeepIntFile>$(IntDir)importlib._bootstrap.g.c</DeepIntFile>
<DeepOutFile>$(PySourcePath)Python\deepfreeze\df.importlib._bootstrap.c</DeepOutFile>
Issue #28896: Disable WindowsRegistryFinder by default.
2016-12-12 15:17:59 -04:00
</None>
<None Include="..\Lib\importlib\_bootstrap_external.py">
bpo-25711: Rewrite zipimport in pure Python. (GH-6809)
2018-09-18 16:22:29 -03:00
<ModName>importlib._bootstrap_external</ModName>
bpo-45020: Fix some corner cases for frozen module generation. (gh-28538) This also includes some cleanup in preparation for a PR to make the "make all" output less noisy. https://bugs.python.org/issue45020
2021-09-24 17:35:47 -03:00
<IntFile>$(IntDir)importlib._bootstrap_external.g.h</IntFile>
<OutFile>$(PySourcePath)Python\frozen_modules\importlib._bootstrap_external.h</OutFile>
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<DeepIntFile>$(IntDir)importlib._bootstrap_external.g.c</DeepIntFile>
<DeepOutFile>$(PySourcePath)Python\deepfreeze\df.importlib._bootstrap_external.c</DeepOutFile>
Issue #28896: Disable WindowsRegistryFinder by default.
2016-12-12 15:17:59 -04:00
</None>
bpo-25711: Rewrite zipimport in pure Python. (GH-6809)
2018-09-18 16:22:29 -03:00
<None Include="..\Lib\zipimport.py">
<ModName>zipimport</ModName>
bpo-45019: Add a tool to generate list of modules to include for frozen 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
2021-08-30 20:25:11 -03:00
<IntFile>$(IntDir)zipimport.g.h</IntFile>
<OutFile>$(PySourcePath)Python\frozen_modules\zipimport.h</OutFile>
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<DeepIntFile>$(IntDir)zipimport.g.c</DeepIntFile>
<DeepOutFile>$(PySourcePath)Python\deepfreeze\df.zipimport.c</DeepOutFile>
bpo-25711: Rewrite zipimport in pure Python. (GH-6809)
2018-09-18 16:22:29 -03:00
</None>
bpo-45020: Drop the frozen .h files from the repo. (gh-28392) 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
2021-09-16 17:20:52 -03:00
<None Include="..\Lib\abc.py">
<ModName>abc</ModName>
<IntFile>$(IntDir)abc.g.h</IntFile>
<OutFile>$(PySourcePath)Python\frozen_modules\abc.h</OutFile>
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<DeepIntFile>$(IntDir)abc.g.c</DeepIntFile>
<DeepOutFile>$(PySourcePath)Python\deepfreeze\df.abc.c</DeepOutFile>
bpo-45020: Drop the frozen .h files from the repo. (gh-28392) 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
2021-09-16 17:20:52 -03:00
</None>
bpo-45020: Freeze os, site, and codecs. (gh-28398) https://bugs.python.org/issue45020
2021-09-17 19:31:31 -03:00
<None Include="..\Lib\codecs.py">
<ModName>codecs</ModName>
<IntFile>$(IntDir)codecs.g.h</IntFile>
<OutFile>$(PySourcePath)Python\frozen_modules\codecs.h</OutFile>
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<DeepIntFile>$(IntDir)codecs.g.c</DeepIntFile>
<DeepOutFile>$(PySourcePath)Python\deepfreeze\df.codecs.c</DeepOutFile>
bpo-45020: Freeze os, site, and codecs. (gh-28398) https://bugs.python.org/issue45020
2021-09-17 19:31:31 -03:00
</None>
bpo-45020: Drop the frozen .h files from the repo. (gh-28392) 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
2021-09-16 17:20:52 -03:00
<None Include="..\Lib\io.py">
<ModName>io</ModName>
<IntFile>$(IntDir)io.g.h</IntFile>
<OutFile>$(PySourcePath)Python\frozen_modules\io.h</OutFile>
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<DeepIntFile>$(IntDir)io.g.c</DeepIntFile>
<DeepOutFile>$(PySourcePath)Python\deepfreeze\df.io.c</DeepOutFile>
bpo-45020: Drop the frozen .h files from the repo. (gh-28392) 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
2021-09-16 17:20:52 -03:00
</None>
<None Include="..\Lib\_collections_abc.py">
<ModName>_collections_abc</ModName>
<IntFile>$(IntDir)_collections_abc.g.h</IntFile>
<OutFile>$(PySourcePath)Python\frozen_modules\_collections_abc.h</OutFile>
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<DeepIntFile>$(IntDir)_collections_abc.g.c</DeepIntFile>
<DeepOutFile>$(PySourcePath)Python\deepfreeze\df._collections_abc.c</DeepOutFile>
bpo-45020: Drop the frozen .h files from the repo. (gh-28392) 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
2021-09-16 17:20:52 -03:00
</None>
<None Include="..\Lib\_sitebuiltins.py">
<ModName>_sitebuiltins</ModName>
<IntFile>$(IntDir)_sitebuiltins.g.h</IntFile>
<OutFile>$(PySourcePath)Python\frozen_modules\_sitebuiltins.h</OutFile>
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<DeepIntFile>$(IntDir)_sitebuiltins.g.c</DeepIntFile>
<DeepOutFile>$(PySourcePath)Python\deepfreeze\df._sitebuiltins.c</DeepOutFile>
bpo-45020: Drop the frozen .h files from the repo. (gh-28392) 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
2021-09-16 17:20:52 -03:00
</None>
<None Include="..\Lib\genericpath.py">
<ModName>genericpath</ModName>
<IntFile>$(IntDir)genericpath.g.h</IntFile>
<OutFile>$(PySourcePath)Python\frozen_modules\genericpath.h</OutFile>
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<DeepIntFile>$(IntDir)genericpath.g.c</DeepIntFile>
<DeepOutFile>$(PySourcePath)Python\deepfreeze\df.genericpath.c</DeepOutFile>
bpo-45020: Drop the frozen .h files from the repo. (gh-28392) 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
2021-09-16 17:20:52 -03:00
</None>
<None Include="..\Lib\ntpath.py">
<ModName>ntpath</ModName>
<IntFile>$(IntDir)ntpath.g.h</IntFile>
<OutFile>$(PySourcePath)Python\frozen_modules\ntpath.h</OutFile>
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<DeepIntFile>$(IntDir)ntpath.g.c</DeepIntFile>
<DeepOutFile>$(PySourcePath)Python\deepfreeze\df.ntpath.c</DeepOutFile>
bpo-45020: Drop the frozen .h files from the repo. (gh-28392) 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
2021-09-16 17:20:52 -03:00
</None>
<None Include="..\Lib\posixpath.py">
<ModName>posixpath</ModName>
<IntFile>$(IntDir)posixpath.g.h</IntFile>
<OutFile>$(PySourcePath)Python\frozen_modules\posixpath.h</OutFile>
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<DeepIntFile>$(IntDir)posixpath.g.c</DeepIntFile>
<DeepOutFile>$(PySourcePath)Python\deepfreeze\df.posixpath.c</DeepOutFile>
bpo-45020: Drop the frozen .h files from the repo. (gh-28392) 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
2021-09-16 17:20:52 -03:00
</None>
bpo-45020: Freeze os, site, and codecs. (gh-28398) https://bugs.python.org/issue45020
2021-09-17 19:31:31 -03:00
<None Include="..\Lib\os.py">
<ModName>os</ModName>
<IntFile>$(IntDir)os.g.h</IntFile>
<OutFile>$(PySourcePath)Python\frozen_modules\os.h</OutFile>
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<DeepIntFile>$(IntDir)os.g.c</DeepIntFile>
<DeepOutFile>$(PySourcePath)Python\deepfreeze\df.os.c</DeepOutFile>
bpo-45020: Freeze os, site, and codecs. (gh-28398) https://bugs.python.org/issue45020
2021-09-17 19:31:31 -03:00
</None>
<None Include="..\Lib\site.py">
<ModName>site</ModName>
<IntFile>$(IntDir)site.g.h</IntFile>
<OutFile>$(PySourcePath)Python\frozen_modules\site.h</OutFile>
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<DeepIntFile>$(IntDir)site.g.c</DeepIntFile>
<DeepOutFile>$(PySourcePath)Python\deepfreeze\df.site.c</DeepOutFile>
bpo-45020: Freeze os, site, and codecs. (gh-28398) https://bugs.python.org/issue45020
2021-09-17 19:31:31 -03:00
</None>
bpo-45020: Drop the frozen .h files from the repo. (gh-28392) 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
2021-09-16 17:20:52 -03:00
<None Include="..\Lib\stat.py">
<ModName>stat</ModName>
<IntFile>$(IntDir)stat.g.h</IntFile>
<OutFile>$(PySourcePath)Python\frozen_modules\stat.h</OutFile>
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<DeepIntFile>$(IntDir)stat.g.c</DeepIntFile>
<DeepOutFile>$(PySourcePath)Python\deepfreeze\df.stat.c</DeepOutFile>
bpo-45020: Drop the frozen .h files from the repo. (gh-28392) 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
2021-09-16 17:20:52 -03:00
</None>
bpo-45019: Clean up the frozen __hello__ module. (gh-28374) 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
2021-09-15 17:15:32 -03:00
<None Include="..\Lib\__hello__.py">
<ModName>__hello__</ModName>
<IntFile>$(IntDir)__hello__.g.h</IntFile>
<OutFile>$(PySourcePath)Python\frozen_modules\__hello__.h</OutFile>
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<DeepIntFile>$(IntDir)__hello__.g.c</DeepIntFile>
<DeepOutFile>$(PySourcePath)Python\deepfreeze\df.__hello__.c</DeepOutFile>
bpo-44479: Regenerate test_frozenmain.h and frozen_hello.h during build on Windows (GH-26984)
2021-07-05 12:18:14 -03:00
</None>
bpo-45020: Add more test cases for frozen modules. (gh-28664) 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
2021-09-30 21:38:52 -03:00
<None Include="..\Lib\__phello__\__init__.py">
<ModName>__phello__</ModName>
<IntFile>$(IntDir)__phello__.g.h</IntFile>
<OutFile>$(PySourcePath)Python\frozen_modules\__phello__.h</OutFile>
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<DeepIntFile>$(IntDir)__phello__.g.c</DeepIntFile>
<DeepOutFile>$(PySourcePath)Python\deepfreeze\df.__phello__.c</DeepOutFile>
bpo-45020: Add more test cases for frozen modules. (gh-28664) 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
2021-09-30 21:38:52 -03:00
</None>
<None Include="..\Lib\__phello__\ham\__init__.py">
<ModName>__phello__.ham</ModName>
<IntFile>$(IntDir)__phello__.ham.g.h</IntFile>
<OutFile>$(PySourcePath)Python\frozen_modules\__phello__.ham.h</OutFile>
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<DeepIntFile>$(IntDir)__phello__.ham.g.c</DeepIntFile>
<DeepOutFile>$(PySourcePath)Python\deepfreeze\df.__phello__.ham.c</DeepOutFile>
bpo-45020: Add more test cases for frozen modules. (gh-28664) 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
2021-09-30 21:38:52 -03:00
</None>
<None Include="..\Lib\__phello__\ham\eggs.py">
<ModName>__phello__.ham.eggs</ModName>
<IntFile>$(IntDir)__phello__.ham.eggs.g.h</IntFile>
<OutFile>$(PySourcePath)Python\frozen_modules\__phello__.ham.eggs.h</OutFile>
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<DeepIntFile>$(IntDir)__phello__.ham.eggs.g.c</DeepIntFile>
<DeepOutFile>$(PySourcePath)Python\deepfreeze\df.__phello__.ham.eggs.c</DeepOutFile>
bpo-45020: Add more test cases for frozen modules. (gh-28664) 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
2021-09-30 21:38:52 -03:00
</None>
<None Include="..\Lib\__phello__\spam.py">
<ModName>__phello__.spam</ModName>
<IntFile>$(IntDir)__phello__.spam.g.h</IntFile>
<OutFile>$(PySourcePath)Python\frozen_modules\__phello__.spam.h</OutFile>
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<DeepIntFile>$(IntDir)__phello__.spam.g.c</DeepIntFile>
<DeepOutFile>$(PySourcePath)Python\deepfreeze\df.__phello__.spam.c</DeepOutFile>
bpo-45020: Add more test cases for frozen modules. (gh-28664) 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
2021-09-30 21:38:52 -03:00
</None>
<None Include="..\Tools\freeze\flag.py">
<ModName>frozen_only</ModName>
<IntFile>$(IntDir)frozen_only.g.h</IntFile>
<OutFile>$(PySourcePath)Python\frozen_modules\frozen_only.h</OutFile>
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<DeepIntFile>$(IntDir)frozen_only.g.c</DeepIntFile>
<DeepOutFile>$(PySourcePath)Python\deepfreeze\df.frozen_only.c</DeepOutFile>
bpo-45020: Add more test cases for frozen modules. (gh-28664) 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
2021-09-30 21:38:52 -03:00
</None>
bpo-45019: Add a tool to generate list of modules to include for frozen 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
2021-08-30 20:25:11 -03:00
<!-- END frozen modules -->
Issue #15431: Add _freeze_importlib project to regenerate importlib.h on Windows. Patch by Kristján Valur Jónsson.
2012-07-28 15:46:52 -03:00
</ItemGroup>
bpo-45582: Port getpath[p].c to Python (GH-29041) The getpath.py file is frozen at build time and executed as code over a namespace. It is never imported, nor is it meant to be importable or reusable. However, it should be easier to read, modify, and patch than the previous code. This commit attempts to preserve every previously tested quirk, but these may be changed in the future to better align platforms.
2021-12-02 20:08:42 -04:00
<ItemGroup>
<!-- We manually freeze getpath.py rather than through freeze_modules -->
<GetPath Include="..\Modules\getpath.py">
<ModName>getpath</ModName>
<IntFile>$(IntDir)getpath.g.h</IntFile>
<OutFile>$(PySourcePath)Modules\getpath.h</OutFile>
</GetPath>
</ItemGroup>
Issue #15431: Add _freeze_importlib project to regenerate importlib.h on Windows. Patch by Kristján Valur Jónsson.
2012-07-28 15:46:52 -03:00
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
<ImportGroup Label="ExtensionTargets">
</ImportGroup>
bpo-45582: Port getpath[p].c to Python (GH-29041) The getpath.py file is frozen at build time and executed as code over a namespace. It is never imported, nor is it meant to be importable or reusable. However, it should be easier to read, modify, and patch than the previous code. This commit attempts to preserve every previously tested quirk, but these may be changed in the future to better align platforms.
2021-12-02 20:08:42 -04:00
<Target Name="_RebuildGetPath" AfterTargets="_RebuildFrozen" Condition="$(Configuration) != 'PGUpdate'">
<Exec Command='"$(TargetPath)" "%(GetPath.ModName)" "%(GetPath.FullPath)" "%(GetPath.IntFile)"' />
<Copy SourceFiles="%(GetPath.IntFile)"
DestinationFiles="%(GetPath.OutFile)"
Condition="!Exists(%(GetPath.OutFile)) or (Exists(%(GetPath.IntFile)) and '$([System.IO.File]::ReadAllText(%(GetPath.OutFile)).Replace(`&#x0D;&#x0A;`, `&#x0A;`))' != '$([System.IO.File]::ReadAllText(%(GetPath.IntFile)).Replace(`&#x0D;&#x0A;`, `&#x0A;`))')">
<Output TaskParameter="CopiedFiles" ItemName="_UpdatedGetPath" />
</Copy>
<Message Text="Updated files: @(_UpdatedGetPath->'%(Filename)%(Extension)',', ')"
Condition="'@(_UpdatedGetPath)' != ''" Importance="high" />
</Target>
bpo-45188: Windows now regenerates frozen modules at the start of build 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.
2021-09-15 14:11:12 -03:00
<Target Name="_RebuildFrozen" AfterTargets="AfterBuild" Condition="$(Configuration) != 'PGUpdate'">
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<Exec Command='"$(TargetPath)" "%(None.ModName)" "%(None.FullPath)" "%(None.DeepIntFile)"' />
bpo-45188: Windows now regenerates frozen modules at the start of build 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.
2021-09-15 14:11:12 -03:00
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<Copy SourceFiles="%(None.DeepIntFile)"
Issue #28896: Disable WindowsRegistryFinder by default.
2016-12-12 15:17:59 -04:00
DestinationFiles="%(None.OutFile)"
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
Condition="!Exists(%(None.OutFile)) or (Exists(%(None.DeepIntFile)) and '$([System.IO.File]::ReadAllText(%(None.OutFile)).Replace(`&#x0D;&#x0A;`, `&#x0A;`))' != '$([System.IO.File]::ReadAllText(%(None.DeepIntFile)).Replace(`&#x0D;&#x0A;`, `&#x0A;`))')">
Issue #28896: Disable WindowsRegistryFinder by default.
2016-12-12 15:17:59 -04:00
<Output TaskParameter="CopiedFiles" ItemName="_Updated" />
</Copy>
bpo-43567: Improved generated code refresh on Windows (GH-25120) Generated files are now refreshed automatically on regular build, or may be forcibly regenerated by calling `build.bat --regen`.
2021-04-06 19:54:43 -03:00
<Message Text="Updated files: @(_Updated->'%(Filename)%(Extension)',', ')"
Condition="'@(_Updated)' != ''" Importance="high" />
Issue #22919: Windows build updated to support VC 14.0 (Visual Studio 2015), which will be used for the official 3.5 release.
2014-11-22 16:54:57 -04:00
</Target>
bpo-45850: Implement deep-freeze on Windows (#29648) 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.
2021-11-22 14:09:48 -04:00
<Target Name="_RebuildDeepFrozen" AfterTargets="_RebuildFrozen" Condition="$(Configuration) != 'PGUpdate'">
<Exec Command='$(PythonForBuild) "$(PySourcePath)Tools\scripts\deepfreeze.py" "%(None.OutFile)" "-m" "%(None.ModName)" -o "%(None.IntFile)"' />
<Copy SourceFiles="%(None.IntFile)"
DestinationFiles="%(None.DeepOutFile)"
Condition="!Exists(%(None.DeepOutFile)) or (Exists(%(None.IntFile)) and '$([System.IO.File]::ReadAllText(%(None.DeepOutFile)).Replace(`&#x0D;&#x0A;`, `&#x0A;`))' != '$([System.IO.File]::ReadAllText(%(None.IntFile)).Replace(`&#x0D;&#x0A;`, `&#x0A;`))')">
<Output TaskParameter="CopiedFiles" ItemName="_DeepUpdated" />
</Copy>
<Message Text="Updated files: @(_DeepUpdated->'%(Filename)%(Extension)',', ')"
Condition="'@(_DeepUpdated)' != ''" Importance="high" />
</Target>
bpo-45188: Windows now regenerates frozen modules at the start of build 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.
2021-09-15 14:11:12 -03:00
<Target Name="_CleanFrozen" BeforeTargets="CoreClean" Condition="$(Configuration) != 'PGUpdate'">
Issue #22919: Windows build updated to support VC 14.0 (Visual Studio 2015), which will be used for the official 3.5 release.
2014-11-22 16:54:57 -04:00
<ItemGroup>
bpo-44479: Regenerate test_frozenmain.h and frozen_hello.h during build on Windows (GH-26984)
2021-07-05 12:18:14 -03:00
<Clean Include="%(None.IntFile)" />
Issue #22919: Windows build updated to support VC 14.0 (Visual Studio 2015), which will be used for the official 3.5 release.
2014-11-22 16:54:57 -04:00
</ItemGroup>
</Target>
Issue #18093: Factor out the programs that embed the runtime
2014-07-25 08:52:14 -03:00
</Project>