All commit authors signed the Contributor License Agreement.

Based on information not provided on the issue, I believe this issue and PR are premature. #105790 (comment)

Ready for initial review, I don't expect it to pass but feedback on what change to do (and help regenerating configure, since my system generates broken files) are welcome. Still broken in terms of being able to fully build python, but almost there.

The massive test failures are due to me ditching the regenerated configure, since it was heavily modified with unwanted changes by my system. The code changes do not actually break builds on other platforms

The massive test failures are due to me ditching the regenerated configure, since it was heavily modified with unwanted changes by my system. The code changes do not actually break builds on other platforms

See the devguide on how to regenerate configure: https://devguide.python.org/getting-started/setup-building/#regenerate-configure

I've tried to follow the guide before, however docker and podman refuse to work properly on my system, so I've unfortunately no way to regenerate a correct configure :(

I've tried to follow the guide before, however docker and podman refuse to work properly on my system, so I've unfortunately no way to regenerate a correct configure :(

That's unfortunate :( We've discussed having the CI automatically regenerate configure. Perhaps it is time to do something with that issue. I can regenerate it for you for now.

Hold on, I'd like to not regenerate it for the time being

I'm still making changes to the configure.ac script, so I'd like to save the regenerate when this is finalized

I'm still making changes to the configure.ac script, so I'd like to save the regenerate when this is finalized

Ok, I'll mark this as draft for now. Ping me when you're ready.

Weird, I seem to be getting the following now

Traceback (most recent call last):
  File "D:\eclipse-php-2022-06-R-win32-x86_64\cpython\Tools\build\check_extension_modules.py", line
483, in <module>
    main()
  File "D:\eclipse-php-2022-06-R-win32-x86_64\cpython\Tools\build\check_extension_modules.py", line
465, in main
    checker = ModuleChecker(
              ^^^^^^^^^^^^^^
  File "D:\eclipse-php-2022-06-R-win32-x86_64\cpython\Tools\build\check_extension_modules.py", line
145, in __init__
    self.modules = self.get_modules()
                   ^^^^^^^^^^^^^^^^^^
  File "D:\eclipse-php-2022-06-R-win32-x86_64\cpython\Tools\build\check_extension_modules.py", line
290, in get_modules
    for modinfo in self.get_sysconfig_modules():
  File "D:\eclipse-php-2022-06-R-win32-x86_64\cpython\Tools\build\check_extension_modules.py", line
312, in get_sysconfig_modules
    moddisabled = set(sysconfig.get_config_var("MODDISABLED_NAMES").split())
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'split'
make: *** [Makefile:1136: checksharedmods] Error 1

Sigh...

@erlend-aasland I think this is ready for the first rounds of reviews, though I think I'll save the regenerating of configure for when it gets the green light. Thanks for the offer though :)

The only work left is to figure out what to pass for the -D flags for some files, and getting the _ssl module to build, plus how to make the built in modules static libraries built into the interpreter. All in all, fairly doable

@erlend-aasland Small little bump :P

@TheShermanTanker: is it possible to break the non-build changes out and apply those separately?

Sure!

Sorry for the long period of absence, I've been away working on the JDK for quite a while. I will break out the code fixes I deem appropriate into another change. But I wanted to discuss the fact that this change feels very hacky, mainly due to how the build system is set up, and I'm not particularly happy with it. Maybe I could fold this into a build system improvement change instead?

Maybe I could fold this into a build system improvement change instead?

That's also a possibility. Could you outline the improvement you have in mind in a separate issue? (Or use the existing issue if that makes more sense.)

Maybe I could fold this into a build system improvement change instead?

That's also a possibility. Could you outline the improvement you have in mind in a separate issue? (Or use the existing issue if that makes more sense.)

I've been thinking a little bit, and I wonder if the make system at least could benefit from the structuring that that JDK uses in its make system. Essentially, the JDK's make is structured into each module having its own Makefile that calls a make function called SetupNativeCompilation, which uses directory structure to automatically compute which files to compile and what flags to pass for each compilation. SetupNativeCompilation does this in a general sense instead of specifying rules for every single file to compile and their individual flags, but also has overrides to enable passing flags to specific files as well. Not sure if cpython could benefit from this style of Makefile structuring. Of course, this would not help improve the Windows specific Visual Studio project that is used for building on Windows and MSVC, but it'd be a start

I've been thinking a little bit, and I wonder if the make system at least could benefit from the structuring that that JDK uses in its make system. Essentially, the JDK's make is structured into each module having its own Makefile [...]

We recently briefly discussed such a restructuring in the core dev Discord chat. IMO, such a refactoring could be helpful when we eventually migrate to a new build system, hopefully not too far in the future.

this would not help improve the Windows specific Visual Studio project that is used for building on Windows and MSVC, but it'd be a start

It doesn't need to help that - we've already structured the Windows build files that way. But I agree, it would be nice to have it be consistent for all platforms. Luckily most of our modules are only a few files each - some projects I've worked with have had hundreds of source files each across hundreds of projects!