Hypothetically, if we had to recreate the build process from just the available code today, which qualities and features would we want to see in tomorrow’s new build system?
Let’s do an informal brainstorm: post your wishes about what a perfect (or very good) CPython build system should look like. Post one item per message, if someone has already posted something you want, “vote” for it using the “heart” mechanism.
Notes:
Just for reference, the previous thread on this topic (though more getting into the weeds of specific tools as opposed to first defining the high-level requirements, and thus didn’t end up being too constructive).
Hopefully this is uncontroversial, but I’d personally like to see a single build system for all platforms, rather than having a separate one for Windows.
Some particular issues I have with our current Windows build system: piles and piles of XML that I’m not sure how to edit (short of copy-pasting something similar and tweaking things until they work), and an inability to see or easily modify the final options (read: a command-line that I can copy and paste to/from a shell) that the compiler ends up actually using after all of the XML has been processed.
I would beware of Chesterton’s fence here.
Yes, every time I think of whipping up a demo of a replacement to our build system, it comes down to “what does this really buy the world?” It’d mostly just be a convenience for us and some CI & bot latency/resources saved.
Nice to haves; but also not urgent. What we have does work even if antiquated or annoying.
So unless we reduce the number of separately maintained build systems we have in a meaningful way (ie: delete the visual studio build configs - a mythical new build system would presumably generate those for people who need them based on its single canonical build specification inputs).
From an optimization point of view to save us dev. / PR contributor time and resources, the biggest bang for the buck comes from getting rid of the autoconf configure step. It is a slow 1990s era needless complexity serialized process. Nothing else is likely to save on the CI/buildbot front. There could be savings for incremental builds if we had all that guaranteed correct (our Makefile does not today, despite all efforts). But the savings there isn’t so notable compared to no-autoconf.
Another goal to consider working towards enabling someone to achieve (distros really want this, we should too!):
So for me personally, a better incremental build experience would make the most difference. It would have to be faster and more correct. Even when I add #include lines. And it should support automatically running the needed file generating tools, as needed (those tools can be slow).
Ease of maintenance (not having to rely on an obscure and hostile toolkit / programming language).
Easily reusable and extendable by third-parties who are building from source (e.g. replacing python.c with their own implementation without directly forking our source tree).
Easier way to constrain external inputs/libraries/dependencies (it’s easy enough on Windows, but if I want to make relocatable POSIX builds or use my own copies of various libraries rather than the system ones, it’s a real pain - I figured it out once, but then something else changed and broke it all on me).
Cross-compilation (within reasonable limits for what compiler toolchains are available)
Generic wish: Automatic detection of version requirement failure and immediate notification to user.
Specific example: in late March 2022, the required VisualStudio version to build on Windows was bumped from VS2015 to VS2017 for 3.11 (only). My next 3.11 (but not 3.10) build failed somewhere mysteriously. Multiple responses during April and May to my corementorship post and tracker issue failed to help. In June, I somehow learn that I need to upgrade VS. Desired alternative: PCbuild/build.bat informs me that I need to upgrade instead of even trying to build.
@steve.dower Is this possible? Open an issue?
It’s possible, but technically it’s only tied to the Visual C++ version, which is independent of Visual Studio version (apart from which one gets installed by default). There’s already code in there that warns if you’re not using the same Visual C++ as we release with, so we could use a similar mechanism to detect and fail if we know there’s a minimum requirement (which there hasn’t been until C11+ features get used). So yeah, file a bug.
Build produces an installed-shape layout (rather than scattering files everywhere and then we have to do runtime tricks to detect whether we are in a build tree or not - also means 3rd parties who compile can then just copy the build output around, rather than needing another script to create the actual layout)
Get rid of this situation:
The code generation scripts in Tools sometimes need to duplicate data that is defined in the stdlib, and the two need to be kept in sync. This is because the Tools scripts can be run on a different python version that has an older version of the stdlib.
We have a Makefile but I’m not familiar with the targets.
A make help target would be useful to list them (compare with make -C Doc help), or at least list the more important ones.
The devguide doesn’t seem to mention make targets much, other than the bare make and make patchcheck.
Additionally, the “Quick Reference” configure and build instructions on the front page of https://devguide.python.org are quite different to those on the detail page, for example: Setup and Building, and neither reference make.
I’d like the devguide to reference make commands, so I can do something like make config build test.
These could include also include the config.cache stuff too if possible (compare python/cpython#104800).
I’d like a build system that didn’t rely on make, as that can be tricky to obtain on Windows 
Having said that, I’d agree with “better documented” as a goal. It’s tricky to remember what the various .bat files involved in a PC build (and running the tests) do, and what their parameters are. And what knowledge I do have there isn’t transferrable at all to the Unix build system. So “a single build system for all platforms” is important to me as well.
Also, a Windows-specific one, but the build system should automatically locate an installed compiler. Having to run the build from a “Visual Studio command prompt” would wreak havoc with my workflow (as the VS prompt starts up a whole new terminal window using a different shell).
Pipe dream: accurate tracking of ABI additions and changes. Adding such a thing to the existing tool chain would be mostly manual with limited options for checking the correctness of the manual updates.
Not running .configure seemingly at random. My hardware, O/S and C compiler haven’t changed from 5 minutes ago.
A checked and enforced dependency DAG; no hacks like having to do make regen-all to get a reliable build.
I poked around, but found nothing in the way of documentation of Makefile targets. At least one person thinks this would be helpful. If I tackled this (or at least created relevant structure soewhere with minimal documentation of the key targets), where should that somewhere be? It seems to me this might be a bit too esoteric for anything other than the devguide, but I could well be wrong.