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

493 lines
25 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>
gh-111650: Ensure pyconfig.h includes Py_GIL_DISABLED on Windows (GH-112778)
2023-12-13 11:38:45 -04:00
<AdditionalIncludeDirectories>$(IntDir);%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
bpo-46123: Disable optimizations for _freeze_module.exe on MSVC for faster building (GH-30181)
2021-12-19 10:55:13 -04:00
<Optimization>Disabled</Optimization>
<WholeProgramOptimization>false</WholeProgramOptimization>
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>
bpo-46123: Disable optimizations for _freeze_module.exe on MSVC for faster building (GH-30181)
2021-12-19 10:55:13 -04:00
<LinkTimeCodeGeneration>Default</LinkTimeCodeGeneration>
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" />
gh-81057: Move time Globals to _PyRuntimeState (gh-100122) https://github.com/python/cpython/issues/81057
2022-12-08 19:46:09 -04:00
<ClCompile Include="..\Modules\timemodule.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\_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\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\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" />
gh-103763: Implement PEP 695 (#103764) This implements PEP 695, Type Parameter Syntax. It adds support for: - Generic functions (def func[T](): ...) - Generic classes (class X[T](): ...) - Type aliases (type X = ...) - New scoping when the new syntax is used within a class body - Compiler and interpreter changes to support the new syntax and scoping rules Co-authored-by: Marc Mueller <30130371+cdce8p@users.noreply.github.com> Co-authored-by: Eric Traut <eric@traut.com> Co-authored-by: Larry Hastings <larry@hastings.org> Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
2023-05-16 00:36:23 -03:00
<ClCompile Include="..\Objects\typevarobject.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="..\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" />
gh-104169: Refactor tokenizer into lexer and wrappers (#110684) * The lexer, which include the actual lexeme producing logic, goes into the `lexer` directory. * The wrappers, one wrapper per input mode (file, string, utf-8, and readline), go into the `tokenizer` directory and include logic for creating a lexer instance and managing the buffer for different modes. --------- Co-authored-by: Pablo Galindo <pablogsal@gmail.com> Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com>
2023-10-11 12:14:44 -03:00
<ClCompile Include="..\Parser\lexer\buffer.c" />
<ClCompile Include="..\Parser\lexer\state.c" />
<ClCompile Include="..\Parser\lexer\lexer.c" />
<ClCompile Include="..\Parser\tokenizer\string_tokenizer.c" />
<ClCompile Include="..\Parser\tokenizer\file_tokenizer.c" />
<ClCompile Include="..\Parser\tokenizer\utf8_tokenizer.c" />
<ClCompile Include="..\Parser\tokenizer\readline_tokenizer.c" />
<ClCompile Include="..\Parser\tokenizer\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="..\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" />
gh-87092: move assembler related code from compile.c to assemble.c (#103277)
2023-04-11 07:15:09 -03:00
<ClCompile Include="..\Python\assemble.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="..\Python\ast.c" />
<ClCompile Include="..\Python\ast_opt.c" />
<ClCompile Include="..\Python\ast_unparse.c" />
<ClCompile Include="..\Python\bltinmodule.c" />
gh-110481: Implement inter-thread queue for biased reference counting (#114824) Biased reference counting maintains two refcount fields in each object: `ob_ref_local` and `ob_ref_shared`. The true refcount is the sum of these two fields. In some cases, when refcounting operations are split across threads, the ob_ref_shared field can be negative (although the total refcount must be at least zero). In this case, the thread that decremented the refcount requests that the owning thread give up ownership and merge the refcount fields.
2024-02-09 18:08:32 -04:00
<ClCompile Include="..\Python\brc.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="..\Python\bootstrap_hash.c" />
<ClCompile Include="..\Python\ceval.c" />
<ClCompile Include="..\Python\codecs.c" />
gh-121404: split compile.c into compile.c and codegen.c (#123651)
2024-09-09 14:21:51 -03:00
<ClCompile Include="..\Python\codegen.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="..\Python\compile.c" />
<ClCompile Include="..\Python\context.c" />
gh-111569: Implement Python critical section API (gh-111571) Critical sections are helpers to replace the global interpreter lock with finer grained locking. They provide similar guarantees to the GIL and avoid the deadlock risk that plain locking involves. Critical sections are implicitly ended whenever the GIL would be released. They are resumed when the GIL would be acquired. Nested critical sections behave as if the sections were interleaved.
2023-11-08 18:39:29 -04:00
<ClCompile Include="..\Python\critical_section.c" />
gh-76785: Move the Cross-Interpreter Code to Its Own File (gh-111502) This is partly to clear this stuff out of pystate.c, but also in preparation for moving some code out of _xxsubinterpretersmodule.c. This change also moves this stuff to the internal API (new: Include/internal/pycore_crossinterp.h). @vstinner did this previously and I undid it. Now I'm re-doing it. :/
2023-10-30 19:53:10 -03:00
<ClCompile Include="..\Python\crossinterp.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="..\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" />
gh-87092: move assembler related code from compile.c to assemble.c (#103277)
2023-04-11 07:15:09 -03:00
<ClCompile Include="..\Python\flowgraph.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="..\Python\formatter_unicode.c" />
<ClCompile Include="..\Python\frame.c" />
<ClCompile Include="..\Python\future.c" />
gh-113688: Split up gcmodule.c (gh-113715) This splits part of Modules/gcmodule.c of into Python/gc.c, which now contains the core garbage collection implementation. The Python module remain in the Modules/gcmodule.c file.
2024-01-05 16:17:16 -04:00
<ClCompile Include="..\Python\gc.c" />
gh-111968: Introduce _PyFreeListState and _PyFreeListState_GET API (gh-113584)
2024-01-09 19:04:41 -04:00
<ClCompile Include="..\Python\gc_gil.c" />
<ClCompile Include="..\Python\gc_free_threading.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="..\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" />
GH-96177: Move GIL and eval breaker code out of ceval.c into ceval_gil.c. (GH-96204)
2022-08-24 10:21:01 -03:00
<ClCompile Include="..\Python\ceval_gil.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="..\Python\hamt.c" />
<ClCompile Include="..\Python\hashtable.c" />
<ClCompile Include="..\Python\import.c" />
<ClCompile Include="..\Python\importdl.c" />
<ClCompile Include="..\Python\initconfig.c" />
gh-117494: extract the Instruction Sequence data structure into a separate file (#117496)
2024-04-04 12:47:26 -03:00
<ClCompile Include="..\Python\instruction_sequence.c" />
gh-76785: Add PyInterpreterConfig Helpers (gh-117170) These helpers make it easier to customize and inspect the config used to initialize interpreters. This is especially valuable in our tests. I found inspiration from the PyConfig API for the PyInterpreterConfig dict conversion stuff. As part of this PR I've also added a bunch of tests.
2024-04-02 17:35:52 -03:00
<ClCompile Include="..\Python\interpconfig.c" />
GH-99005: Add `CALL_INTRINSIC_1` instruction (GH-100771) * Remove PRINT_EXPR instruction * Remove STOPITERATION_ERROR instruction * Remove IMPORT_STAR instruction
2023-01-05 12:05:51 -04:00
<ClCompile Include="..\Python\intrinsics.c" />
GH-103082: Implementation of PEP 669: Low Impact Monitoring for CPython (GH-103083) * The majority of the monitoring code is in instrumentation.c * The new instrumentation bytecodes are in bytecodes.c * legacy_tracing.c adapts the new API to the old sys.setrace and sys.setprofile APIs
2023-04-12 08:04:55 -03:00
<ClCompile Include="..\Python\instrumentation.c" />
GH-113464: Add a JIT backend for tier 2 (GH-113465) Add an option (--enable-experimental-jit for configure-based builds or --experimental-jit for PCbuild-based ones) to build an *experimental* just-in-time compiler, based on copy-and-patch (https://fredrikbk.com/publications/copy-and-patch.pdf). See Tools/jit/README.md for more information on how to install the required build-time tooling.
2024-01-28 22:48:48 -04:00
<ClCompile Include="..\Python\jit.c" />
GH-103082: Implementation of PEP 669: Low Impact Monitoring for CPython (GH-103083) * The majority of the monitoring code is in instrumentation.c * The new instrumentation bytecodes are in bytecodes.c * legacy_tracing.c adapts the new API to the old sys.setrace and sys.setprofile APIs
2023-04-12 08:04:55 -03:00
<ClCompile Include="..\Python\legacy_tracing.c" />
gh-111569: Implement Python critical section API (gh-111571) Critical sections are helpers to replace the global interpreter lock with finer grained locking. They provide similar guarantees to the GIL and avoid the deadlock risk that plain locking involves. Critical sections are implicitly ended whenever the GIL would be released. They are resumed when the GIL would be acquired. Nested critical sections behave as if the sections were interleaved.
2023-11-08 18:39:29 -04:00
<ClCompile Include="..\Python\lock.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="..\Python\marshal.c" />
<ClCompile Include="..\Python\modsupport.c" />
<ClCompile Include="..\Python\mysnprintf.c" />
<ClCompile Include="..\Python\mystrtoul.c" />
gh-112529: Implement GC for free-threaded builds (#114262) * gh-112529: Implement GC for free-threaded builds This implements a mark and sweep GC for the free-threaded builds of CPython. The implementation relies on mimalloc to find GC tracked objects (i.e., "containers").
2024-01-25 14:27:36 -04:00
<ClCompile Include="..\Python\object_stack.c" />
GH-104584: Plugin optimizer API (GH-105100)
2023-06-02 07:46:18 -03:00
<ClCompile Include="..\Python\optimizer.c" />
gh-107557: Setup abstract interpretation (#107847) Co-authored-by: Guido van Rossum <gvanrossum@users.noreply.github.com> Co-authored-by: Jules <57632293+juliapoo@users.noreply.github.com>
2023-08-15 15:04:17 -03:00
<ClCompile Include="..\Python\optimizer_analysis.c" />
GH-115816: Make tier2 optimizer symbols testable, and add a few tests. (GH-115953)
2024-02-27 06:51:26 -04:00
<ClCompile Include="..\Python\optimizer_symbols.c" />
gh-111569: Implement Python critical section API (gh-111571) Critical sections are helpers to replace the global interpreter lock with finer grained locking. They provide similar guarantees to the GIL and avoid the deadlock risk that plain locking involves. Critical sections are implicitly ended whenever the GIL would be released. They are resumed when the GIL would be acquired. Nested critical sections behave as if the sections were interleaved.
2023-11-08 18:39:29 -04:00
<ClCompile Include="..\Python\parking_lot.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="..\Python\pathconfig.c" />
gh-96143: Move the perf trampoline files to the Python directory (#98675)
2022-10-25 19:34:22 -03:00
<ClCompile Include="..\Python\perf_trampoline.c" />
gh-118518: Allow perf to work without frame pointers (#112254)
2024-05-04 22:07:29 -03:00
<ClCompile Include="..\Python\perf_jit_trampoline.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="..\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" />
gh-115103: Implement delayed memory reclamation (QSBR) (#115180) This adds a safe memory reclamation scheme based on FreeBSD's "GUS" and quiescent state based reclamation (QSBR). The API provides a mechanism for callers to detect when it is safe to free memory that may be concurrently accessed by readers.
2024-02-16 16:25:19 -04:00
<ClCompile Include="..\Python\qsbr.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="..\Python\specialize.c" />
<ClCompile Include="..\Python\structmember.c" />
<ClCompile Include="..\Python\suggestions.c" />
<ClCompile Include="..\Python\symtable.c" />
bpo-45582: Fix test_embed failure during a PGO build on Windows (GH-30014) This defines VPATH differently in PGO instrumentation builds, to account for a different default output directory. It also adds sys._vpath on Windows to make the value available to sysconfig so that it can be used in tests.
2021-12-10 13:13:55 -04:00
<ClCompile Include="..\Python\sysmodule.c">
<PreprocessorDefinitions>VPATH="$(PyVPath)";%(PreprocessorDefinitions)</PreprocessorDefinitions>
</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
<ClCompile Include="..\Python\thread.c" />
<ClCompile Include="..\Python\traceback.c" />
GH-101520: Move tracemalloc functionality into core, leaving interface in Modules. (#104508)
2023-05-17 10:17:16 -03:00
<ClCompile Include="..\Python\tracemalloc.c" />
gh-122417: Implement per-thread heap type refcounts (#122418) The free-threaded build partially stores heap type reference counts in distributed manner in per-thread arrays. This avoids reference count contention when creating or destroying instances. Co-authored-by: Ken Jin <kenjin@python.org>
2024-08-06 15:36:57 -03:00
<ClCompile Include="..\Python\typeid.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>
gh-111650: Ensure pyconfig.h includes Py_GIL_DISABLED on Windows (GH-112778)
2023-12-13 11:38:45 -04:00
<ItemGroup>
<ClInclude Include="..\PC\pyconfig.h.in" />
</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
<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>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\importlib._bootstrap.h</OutFile>
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>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\importlib._bootstrap_external.h</OutFile>
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>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\zipimport.h</OutFile>
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>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\abc.h</OutFile>
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>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\codecs.h</OutFile>
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>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\io.h</OutFile>
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>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\_collections_abc.h</OutFile>
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>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\_sitebuiltins.h</OutFile>
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>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\genericpath.h</OutFile>
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>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\ntpath.h</OutFile>
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>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\posixpath.h</OutFile>
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>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\os.h</OutFile>
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>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\site.h</OutFile>
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>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\stat.h</OutFile>
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-45654: Freeze the runpy module and stuff it imports (GH-29903)
2021-12-09 12:51:09 -04:00
<None Include="..\Lib\importlib\util.py">
<ModName>importlib.util</ModName>
<IntFile>$(IntDir)importlib.util.g.h</IntFile>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\importlib.util.h</OutFile>
bpo-45654: Freeze the runpy module and stuff it imports (GH-29903)
2021-12-09 12:51:09 -04:00
</None>
<None Include="..\Lib\importlib\machinery.py">
<ModName>importlib.machinery</ModName>
<IntFile>$(IntDir)importlib.machinery.g.h</IntFile>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\importlib.machinery.h</OutFile>
bpo-45654: Freeze the runpy module and stuff it imports (GH-29903)
2021-12-09 12:51:09 -04:00
</None>
<None Include="..\Lib\runpy.py">
<ModName>runpy</ModName>
<IntFile>$(IntDir)runpy.g.h</IntFile>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\runpy.h</OutFile>
bpo-45654: Freeze the runpy module and stuff it imports (GH-29903)
2021-12-09 12:51:09 -04: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>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\__hello__.h</OutFile>
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>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\__phello__.h</OutFile>
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>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\__phello__.ham.h</OutFile>
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>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\__phello__.ham.eggs.h</OutFile>
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>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\__phello__.spam.h</OutFile>
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>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\frozen_only.h</OutFile>
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>
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<OutFile>$(GeneratedFrozenModulesDir)Python\frozen_modules\getpath.h</OutFile>
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
</GetPath>
</ItemGroup>
gh-109515: When generating deep frozen modules on Windows, use a list file instead of arguments (GH-109516)
2023-10-30 13:14:26 -03:00
<ItemGroup>
<!-- BEGIN freeze mappings -->
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\importlib._bootstrap.h" FrozenId="importlib._bootstrap" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\importlib._bootstrap_external.h" FrozenId="importlib._bootstrap_external" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\zipimport.h" FrozenId="zipimport" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\abc.h" FrozenId="abc" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\codecs.h" FrozenId="codecs" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\io.h" FrozenId="io" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\_collections_abc.h" FrozenId="_collections_abc" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\_sitebuiltins.h" FrozenId="_sitebuiltins" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\genericpath.h" FrozenId="genericpath" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\ntpath.h" FrozenId="ntpath" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\posixpath.h" FrozenId="posixpath" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\os.h" FrozenId="os" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\site.h" FrozenId="site" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\stat.h" FrozenId="stat" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\importlib.util.h" FrozenId="importlib.util" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\importlib.machinery.h" FrozenId="importlib.machinery" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\runpy.h" FrozenId="runpy" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\__hello__.h" FrozenId="__hello__" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\__phello__.h" FrozenId="__phello__" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\__phello__.ham.h" FrozenId="__phello__.ham" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\__phello__.ham.eggs.h" FrozenId="__phello__.ham.eggs" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\__phello__.spam.h" FrozenId="__phello__.spam" />
<FrozenModule Include="$(GeneratedFrozenModulesDir)Python\frozen_modules\frozen_only.h" FrozenId="frozen_only" />
gh-109515: When generating deep frozen modules on Windows, use a list file instead of arguments (GH-109516)
2023-10-30 13:14:26 -03:00
<!-- END freeze mappings -->
</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>
gh-111650: Ensure pyconfig.h includes Py_GIL_DISABLED on Windows (GH-112778)
2023-12-13 11:38:45 -04:00
<!-- Direct copy from pythoncore.vcxproj, but this one is only used for our
own build. All other extension modules will use the copy that pythoncore
generates. -->
<Target Name="_UpdatePyconfig" BeforeTargets="PrepareForBuild">
<MakeDir Directories="$(IntDir)" Condition="!Exists($(IntDir))" />
<ItemGroup>
<PyConfigH Remove="@(PyConfigH)" />
<PyConfigH Include="@(ClInclude)" Condition="'%(Filename)%(Extension)' == 'pyconfig.h.in'" />
</ItemGroup>
<Error Text="Did not find pyconfig.h" Condition="@(ClInclude) == ''" />
<PropertyGroup>
<PyConfigH>@(PyConfigH->'%(FullPath)', ';')</PyConfigH>
<PyConfigHText>$([System.IO.File]::ReadAllText($(PyConfigH)))</PyConfigHText>
<OldPyConfigH Condition="Exists('$(IntDir)pyconfig.h')">$([System.IO.File]::ReadAllText('$(IntDir)pyconfig.h'))</OldPyConfigH>
</PropertyGroup>
<PropertyGroup Condition="$(DisableGil) == 'true'">
<PyConfigHText>$(PyConfigHText.Replace('#undef Py_GIL_DISABLED', '#define Py_GIL_DISABLED 1'))</PyConfigHText>
</PropertyGroup>
<Message Text="Updating pyconfig.h" Condition="$(PyConfigHText.TrimEnd()) != $(OldPyConfigH.TrimEnd())" />
<WriteLinesToFile File="$(IntDir)pyconfig.h"
Lines="$(PyConfigHText)"
Overwrite="true"
Condition="$(PyConfigHText.TrimEnd()) != $(OldPyConfigH.TrimEnd())" />
</Target>
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-46429: Merge all deepfrozen files into one (GH-30572)
2022-01-20 12:38:39 -04:00
<Exec Command='"$(TargetPath)" "%(None.ModName)" "%(None.FullPath)" "%(None.IntFile)"' />
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-46429: Merge all deepfrozen files into one (GH-30572)
2022-01-20 12:38:39 -04:00
<Copy SourceFiles="%(None.IntFile)"
Issue #28896: Disable WindowsRegistryFinder by default.
2016-12-12 15:17:59 -04:00
DestinationFiles="%(None.OutFile)"
bpo-46429: Merge all deepfrozen files into one (GH-30572)
2022-01-20 12:38:39 -04:00
Condition="!Exists(%(None.OutFile)) or (Exists(%(None.IntFile)) and '$([System.IO.File]::ReadAllText(%(None.OutFile)).Replace(`&#x0D;&#x0A;`, `&#x0A;`))' != '$([System.IO.File]::ReadAllText(%(None.IntFile)).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-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)" />
gh-94781: Fix Windows projects not cleaning intermediate and output files for frozen modules (GH-96423)
2022-09-07 17:26:53 -03:00
<Clean Include="%(None.OutFile)" />
<Clean Include="%(GetPath.IntFile)" />
<Clean Include="%(GetPath.OutFile)" />
gh-113258: Write frozen modules to the build tree on Windows (GH-113303) This ensures the source directory is not modified at build time, and different builds (e.g. different versions or GIL vs no-GIL) do not have conflicts.
2024-01-03 13:30:20 -04:00
<Clean Include="$(GeneratedFrozenModulesDir)deepfreeze.c" />
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>