Hi,
I noticed the thread on CMake evaluation, and as a CMake developer I am
interested in helping you evaluate CMake.
I guess four issues were raised:
>A. It has no equivalent of autoheader, so we'd have to maintain
pyconfig.h.in by hand.
This is currently true, but if this were a deal breaker, I am sure
something could be added to CMake to accommodate the need. It might even
be possible to create a CMake function that does something like this
without having to modify CMake itself.
>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/95.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).
CMake now has a cmake-gui (qt based application) for configuring a
project.
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.
We have talked about adding this to CMake several times, and it is a
good idea. However, it has not been a huge issue for many projects.
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)
However, the above CMake script will work on any platform with CMake
installed, and does not use tr. Also, the CMake code for the above
should actually run faster as it is not running two processes with pipe
communication.
I would not think that this list of issues would be a deal breaker. The
benefits of CMake are a single build system that works cross platform.
Developers can use the native tools that they are used to using (VS IDE,
Xcode IDE, Eclipse IDE, nmake command line, gmake command line, etc.).
The original Python CMake work done by Alex, was done to support the
building of ParaView (www.paraview.org) on a Cray Xt5 computer using
CMake's cross-compilation support. This worked very well. The choice
is obviously yours to make, but if you have any specific questions about
CMake, I will lurk on this mailing list and try to answer them. I think
it would be a good fit for CMake to build Python, and make things easier
for some of our customers building ParaView which depends on Python on
machines like the Cray Xt5.
Thanks.
-Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
