Add _testclinic_limited project to the Visual Studio solution:
* In "PCbuild/", copy "_asyncio.vcxproj" to "_testclinic_limited.vcxproj",
replace "RootNamespace" with "_testclinic_limited", replace "_asyncio.c"
with "_testclinic_limited.c".
* Open Visual Studio, open "PCbuild\pcbuild.sln", add the existing
"PCbuild\_testclinic_limited.vcxproj" project to the solution.
* Add a dependency from "python" project to the "_testclinic_limited"
project.
* Save and exit Visual Studio.
* Add ";_testclinic_limited" to "<TestModules Include="...">"
in "PCbuild\pcbuild.proj".
This makes it more clear that a given test is definitely testing against a single-phase init (legacy) extension module. The new module is a companion to _testmultiphase.
https://github.com/python/cpython/issues/98627
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.
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
The distutils bdist_wininst command deprecated in Python 3.8 has been
removed. The distutils bidst_wheel command is now recommended to
distribute binary packages on Windows.
* Remove Lib/distutils/command/bdist_wininst.py
* Remove PC/bdist_wininst/ project
* Remove Lib/distutils/command/wininst-*.exe programs
* Remove all references to bdist_wininst
* Add missing header files to pythoncore.
* Add missing file filters ("Resource Files" in particular) to
all projects.
* Add new sub-filters for private headers in pythoncore and
for 3rd party source files.
* Add missing _zoneinfo configurations in pcbuild.sln.
* Update bdist_wininst with the new zlib location.
This is the initial implementation of PEP 615, the zoneinfo module,
ported from the standalone reference implementation (see
https://www.python.org/dev/peps/pep-0615/#reference-implementation for a
link, which has a more detailed commit history).
This includes (hopefully) all functional elements described in the PEP,
but documentation is found in a separate PR. This includes:
1. A pure python implementation of the ZoneInfo class
2. A C accelerated implementation of the ZoneInfo class
3. Tests with 100% branch coverage for the Python code (though C code
coverage is less than 100%).
4. A compile-time configuration option on Linux (though not on Windows)
Differences from the reference implementation:
- The module is arranged slightly differently: the accelerated module is
`_zoneinfo` rather than `zoneinfo._czoneinfo`, which also necessitates
some changes in the test support function. (Suggested by Victor
Stinner and Steve Dower.)
- The tests are arranged slightly differently and do not include the
property tests. The tests live at test/test_zoneinfo/test_zoneinfo.py
rather than test/test_zoneinfo.py or test/test_zoneinfo/__init__.py
because we may do some refactoring in the future that would likely
require this separation anyway; we may:
- include the property tests
- automatically run all the tests against both pure Python and C,
rather than manually constructing C and Python test classes (similar
to the way this works with test_datetime.py, which generates C
and Python test cases from datetimetester.py).
- This includes a compile-time configuration option on Linux (though not
on Windows); added with much help from Thomas Wouters.
- Integration into the CPython build system is obviously different from
building a standalone zoneinfo module wheel.
- This includes configuration to install the tzdata package as part of
CI, though only on the coverage jobs. Introducing a PyPI dependency as
part of the CI build was controversial, and this is seen as less of a
major change, since the coverage jobs already depend on pip and PyPI.
Additional changes that were introduced as part of this PR, most / all of
which were backported to the reference implementation:
- Fixed reference and memory leaks
With much debugging help from Pablo Galindo
- Added smoke tests ensuring that the C and Python modules are built
The import machinery can be somewhat fragile, and the "seamlessly falls
back to pure Python" nature of this module makes it so that a problem
building the C extension or a failure to import the pure Python version
might easily go unnoticed.
- Adjustments to zoneinfo.__dir__
Suggested by Petr Viktorin.
- Slight refactorings as suggested by Steve Dower.
- Removed unnecessary if check on std_abbr
Discovered this because of a missing line in branch coverage.
Add a new _testinternalcapi module to test the internal C API.
Move _Py_GetConfigsAsDict() function to the internal C API:
_testembed now uses _testinternalcapi to access the function.
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.
* Adds lib.pyproj file to solution so that VS with Python support can open all the files in the standard library.
* Remove unexpected solution configuration.
* Remove lib.pyproj from solution to avoid memory issues on VS 2015.
solution.
Currently, Tix is not built in Debug configuration.
This change also:
- simplifies some Tcl/Tk-related msbuild properties for _tkinter
- copies the Tcl and Tk DLLs into the build output directory, meaning
they will always be available after a build without having to copy
them manually or change PATH
- removes PCbuild/build_tkinter.py: the solution does the build without
needing to invoke Python (so Tcl/Tk/Tix can be built in parallel with
the rest of the build using the `/m` msbuild command line switch)
- removes an outdated README concerning building Tcl/Tk on AMD64
- Remove configuration settings from removed _sha3.vcxproj
- Don't try to build configurations of _testembed that don't exist
(namely, PGInstrument and PGUpdate)
As stated in PEP 11, 3.4 removes code on Windows platforms where
COMSPEC points to command.com. The w9xpopen project in Visual Studio
was added to support that case, and there was a special case in subprocess
to cover that situation. This change removes the w9xpopen project from
the Visual Studio solution and removes any references to the w9xpopen
executable.