I've heard some good things about cmake — LLVM, googletest, and Boost are all looking at switching to it — so I wanted to see if we could simplify our autoconf+makefile system by using it. The biggest wins I see from going to cmake are: 1. It can autogenerate the Visual Studio project files instead of needing them to be maintained separately 2. It lets you write functions and modules without understanding autoconf's mix of shell and M4. 3. Its generated Makefiles track header dependencies accurately so we might be able to add private headers efficiently. However, after trying it out during PyCon and looking over the previous attempt at http://mail.python.org/pipermail/python-dev/2007-July/073912.html, I can't recommend switching to it. A. It has no equivalent of autoheader, so we'd have to maintain pyconfig.h.in by hand. B. It does not allow the CMakeLists.txt file control the --help output. This appears to be an intentional decision (http://www.cmake.org/pipermail/cmake-promote/2006-May/000095.html). To replace it, they have an interactive mode (which asks you about each possible option) and a -LH flag (which runs the whole configure process and then tells you about the flags you could have set if you knew about them). C. It does not allow the CMakeLists.txt file to see the command line, so we can't stay backward compatible with the configure script, and we'd have to replace flags like --with-pydebug with -Dpydebug:bool=true. We could write a separate configure script to mitigate this and the previous problem, but we'd have to keep that in sync with CMakeLists.txt manually. D. It doesn't have an expression language, so to replace ac_md_system=`echo $ac_sys_system | tr -d '[/ ]' | tr '[[A-Z]]' '[[a-z]]'` you have to write: string(REGEX REPLACE "[/ ]" "" ac_md_system ${ac_sys_system}) string(TOLOWER ${ac_md_system} ac_md_system) So, at the very least, it doesn't look like a big enough win to justify switching, and may not be a win at all. The other popular configure+make replacement is scons. The biggest objection to scons before even looking at it is that it requires a working Python interpreter in order to build Python, causing a bootstrap problem. However, Brett Cannon and I talked, and we think this is surmountable. First, nearly every desktop system comes with a Python interpreter, which would avoid the bootstrap for ordinary development. Second, we need a cross compilation story anyway for embedded systems, and the same mechanism could be used to get Python onto a new desktop platform. Third, Jython and IronPython are pretty mature and either can run scons now or should be able to run it after some relatively easy tweaks. They could be used to build CPython on a new platform. I don't intend to look into scons myself any time soon, but I'd be interested in anyone's experiences who does try it. Jeffrey