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/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).


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

Reply via email to