[Python-Dev] Evaluated cmake as an autoconf replacement

[Jeffrey Yasskin]

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